| preface

Last year, I made a small component. Some time ago, considering the possibility of large-scale implementation in the project, I opened a new REPO: YBHandyList after improvement and simplification.

Some friends have thrown out nimbus, IGListKit and other widely used libraries in the industry. Some time ago, netease engineers also launched M80TableViewComponent. In theory, these components work much the same way, and while they have their own advantages, they don’t quite meet my requirements for architectural clarity.

This paper analyzes the application value of YBHandyList, hoping to solve the doubts of some friends.

| business pain points

UITableView/UICollectionView are very popular in iOS interface development, both of which use the proxy method to configure the data source. While this design concept is consistent with the principle of single responsibility, the proxy method becomes inadequate when the list becomes complex:

  • The same Cell/Header/Footer processing logic is scattered among proxy methods, making it difficult to manage.
  • When the list data changes dynamically, the judgment logic in each proxy method becomes complex, and it is likely to be interrelated.

Obviously, such a scenario would be a maintenance disaster, especially if you take someone else’s code and find that there are dozens of if-else methods in each UITableView proxy method, and there are so many of them that you don’t want to touch any of them.

Therefore, in order to achieve high maintenance, it is necessary to unlock the logical coupling between each Cell, namely, modularization in the common sense, so as to realize dynamic more easily. The solution is as simple as centralizing the scattered configuration with a single intermediate class (take the corresponding value of this intermediate class in the proxy method) :

@interface Config : NSObject
@property (nonatomic, assign) CGFloat height;
@property (nonatomic, strong) Class cls;
@property (nonatomic, strong) id model;
@end

Copy the code

However, each time a business engineer writes such code, there is a time cost, so it is necessary to create a basic component that meets the following characteristics:

  • Modular configuration of Cell, Header, and Footer.
  • It is easier to make lists dynamic.
  • Can extend all scenarios of native energy implementation.

For this reason, YBHandyList was born, and it was simple enough that it took almost a day to go from design to code.

| YBHandyList advantage

Principle:

| code simple and lightweight

YBHandyList retains minimal functionality and very little code. The core idea is to convert the data source of a UITableView/UICollectionView from a proxy method configuration to an array configuration.

The logic of high caching, access iterators, etc. can be seen in other libraries. I believe that such infrastructure should not intrude too much into the business. They should be the logic of business concern, and such syntax sugar can only be used to write less code in simple scenarios.

The syntax sugar of YBHandyList is very convergent, a simple extension, you can even choose not to use syntax sugar and use proxy implementation classes directly.

As a result, novice engineers can have confidence in implementing code.

Invasive | business is low

YBHandyList uses an IOP design to minimize business intrusion by implementing only a few proxy methods in the Cell/Header/Footer.

The base removal design makes the data flow process more pure, regardless of what the parent class does or does not do. There might be something like BaseTableViewCell in the old business, and YBHandyList could be elegantly accessed, where the inherited design paradigm would be inadequate.

The cost of adding such an architectural specification class component is important, but the cost of discarding it is also important. Due to the natural advantages of IOP, discarding the YBHandyList structure code will be easy and easy.

| intuitive dynamic control

To build the interface, we only need to pay attention to the order of all ids

in the data source array, which is put together like building blocks. The order in the array is the display order of the corresponding Cell in the interface. Thus, dynamic control can be easily realized by changing the order of the data source array.

| in MVVM framework to implement

YBHandyList is designed in such a way that it can be implemented in a variety of architectures without any problems. The following uses MVVM as an example (only to illustrate the implementation of UITableViewCell, see DEMO for details) :

As you can see, the Cell is not directly coupled to the UITableView, so the best way to pass the Cell’s events is through the Cell’s ViewModel, which acts as a bridge between the Cell and the outside world.

The ViewModel of the Cell can also be built in the main ViewModel so that the Controller doesn’t have to import these classes, but when the ViewModel of the Cell needs to pass events to the Controller, You’ll need some glue code to pass indirectly through the main ViewModel.

Data binding is not mandatory, you can use RAC, or another option: EasyReact

The reuse of | safer and elegant

Most of the time, we will put the processing logic of specific business in the Cell or its ViewModel, so it is difficult to reuse, because reuse is built on the premise of no intrusion of specific business.

In fact, you only need to extract the processing logic of a specific business and put it in the ViewModel after processing. The Cell takes it to the ViewModel and then refreshes the interface unrelated to the specific business. Thus, the ViewModel can be reused anywhere.

After YBHandyList is used, the ViewModel uncoupling the Cell from the external business and writes only the things that need to be exposed in viewModel.h. The external business can reuse the Cell directly through the ViewModel without importing the Cell, which is more secure.

| can expand native support scenarios

One of the worst things about an infrastructure is that it can’t accommodate all scenarios and then it closes the door to expansion. YBHandyList extends the implementation of other UITableView/UICollectionView proxy methods by inheriting the default proxy implementation class.

This may seem cumbersome, and using the multi-agent technique avoids creating additional proxy implementation classes, but it can lead to code that is less simple and transparent. On the other hand, the proxy implementation class only calls back a simple method to the external business after processing a lot of complex logic, so as to achieve the purpose of sliming down the external module.

After | language

The author has always preferred simple code design to minimize the implementation of core functions, and must have native expansion capability when it cannot cover all scenarios. The main purpose of syntactic sugar is to reduce the user’s thinking cost, not just to save two lines of code. It should not invade the core code of functional convergence. To do all these, we must see through the phenomenon of the essence of the problem.

Original author: Cabbage

The original link: www.jianshu.com/p/f0a74d574…