Building apps with FunctionalTableData (Part 1)

Modernizing UITableViewCell and UICollectionViewCell.

Almost every time you want to create a new app screen, you start with either a table view or a collection view. After this, you conform to the delegate and data source and off it goes into the world. The default implementation for UITableView and UICollectionView is very powerful, but also requires a lot of IndexPath book keeping. Let’s use this screen as an example.

(Figure 1) Preview of the app we will end up building in this series of articles, while evolving into more complex ones.

The previous screen is pretty simple, broken down it’s only 3 cells, 1 of them an UILabel and the rest UIButton. Creating this with conventional methods is trivial but very inflexible, we will end up with classes like LabelTableViewCell and ButtonTableViewCell. Which will be completely tied up to UITableView, but most importantly to UITableViewDataSource resulting in something like this:

(Figure 2) Quick example of conditionally dequeuing and sorting cells

FunctionalTableData a library built by Shopify, takes another approach to solve the previous problem. By creating a reusable, encapsulated CellConfigType protocol that all our elements must conform to. We can display these items in UITableView and UICollectionView alike, without changing a single line of code in them.

Using CellConfigType

A ready to use implementation of CellConfigType is provided with the library called HostCell, and we will use it in these posts to lower the learning curve. Instantiating implementations of CellConfigType is your only concern when using FunctionalTableData, the rest of the magic will be done for you. You are welcome to dig into the codebase if you are feeling curious and want to peek under the hood.

A HostCell consists of a UIView, a State, and a Layout of the given view. If we use the app preview (Figure 1) as example, a HostCell implementation of a LabelCell would look something like this.

It may seem like a lot, but it’s very simple once we start going through the code. We define a State as the information that represents a view, in this example a UILabel can have text, font, and if it’s multiline or not as its State. The top cell from Figure 1 can easily be represented by this State. We can take advantage of the default values in the LabelState initializer and create a LabelCell like this:

(Figure 3) Label cell implementation

Creating more cells

Now that we know how to create a cell that presents the label in Figure 1, let’s do the same for the buttons.

Using them is as easy as:

(Figure 4) Button cell implementation

Bringing it it all together

Now we need a way to tell the tableview to update itself with the views and states we created previously. In order to do that, we need to create an array of TableSection that also holds an array of rows (the cells we just created). The code looks something like this.

(Figure 5) Updating the table with our data

Remember that IndexPath book keeping in Figure 2 to sort the cells? Let’s compare that to Figure 5, they are a simple array. If we want to change the order we simply move them around.

Conclusion

So far we only migrated a typical UITableViewController to FunctionalTableData. In upcoming posts we will dig deeper into the power of this library and how it can be used to build complex layouts, and much more.

How battle tested is FunctionalTableData you say? Shopify’s iOS application is built entirely using this method. If you want to learn more about this functional approach to building iOS applications, drop by the following repository and say hi 👋

Continue to part 2 >

Shopify/FunctionalTableData