TCA and modularity

[bioche]

Hi all,

I just finished watching the last PointFree episode about modularity (https://www.pointfree.co/episodes/ep172-modularization-part-2) where @mbrandonw & @stephencelis modularize the sandbox app they have been using to demonstrate Navigation helpers.

The discussion at the end of that video about vertical & horizontal dependencies caught my attention as I think I will begin facing some difficulty in modularizing my current project.

Here is the module map of that sandbox app:

/*------|    
|   I   |
|   t   |
|   e   |
|   m   |
|-------|
|   I   |
|   t   |
|   e   |
|   m   |
|   R   |
|   o   |       |-------|
|   w   |       |   U   |
|-------|       |   s   |
|   I   |       |   e   |-------|
|   n   |       |   r   |   S   |
|   v   |-------|   P   |   e   |
|   e   |   S   |   r   |   t   |
|   n   |   e   |   o   |   t   |
|   t   |   a   |   f   |   i   |    ...
|   o   |   r   |   i   |   n   |
|   r   |   c   |   l   |   g   |
|   y   |   h   |   e   |   s   |
|-------|-------|-------|-------|

Each box represents a distinct module & each column the dependencies between them. We can also see each column as a tab in the app : in the first tab, Inventory presents a list of ItemRow, & each ItemRow leads to an Item screen. So Inventory depends on ItemRow which depends on Item.

Using TCA I can see how it would be possible to modularize an app this way. However the problems start when Item screen should contain a link to Inventory screen maybe because we want a list of relatable items there ;) In this scenario Item would need to depend on Inventory which leads to interdependency loop 🥶

Interestingly enough Brandon & Stephen mention another way of modularizing without creating dependencies between modules :

                                 /*------|
                                 |   U   |
                 |-------|       |   s   |
                 |   I   |       |   e   |-------|
         |-------|   n   |       |   r   |   S   |
         |   I   |   v   |-------|   P   |   e   |
         |   t   |   e   |   S   |   r   |   t   |
 |-------|   e   |   n   |   e   |   o   |   t   |
 |   I   |   m   |   t   |   a   |   f   |   i   |    ...
 |   t   |   R   |   o   |   r   |   i   |   n   |
 |   e   |   o   |   r   |   c   |   l   |   g   |
 |   m   |   w   |   y   |   h   |   e   |   s   |
 |-------|-------|-------|-------|-------|------*/

This would allow us to display Inventory screen from Item screen without even have a dependency between the two modules. However the video doesn't go further than mentionning it's a complex topic. I guess it would require heavy use of protocols to hide the actual types inside the modules and I struggle to see how it can be performed using TCA.

If someone (especially Brandon or Stephen ;) ) has a strategy in mind, or has already tackled the problem, that would maybe give some clues on how I can solve this on my own project.

PS : I hope it's OK to post this here as I think it's an issue many people using TCA with modules will encounter at one point or another :)

[andreyz]

I'm probably wrong, my guess it's possible to do as demonstrated in TCA case study example ReusableFavoriting.

In other words, Inventory really only needs to know that items it's managing can be stored in an IdentifiedArray. While ItemRow, probably will need to be aware of the Item's shape just enough for its display, which is probably defined by a protocol.

[bioche]

Thanks for your reply ! I'm not sure high order reducer are necessary here but making ItemRow generic over Item (like ID is a generic for favorites) & defining its shape in a protocol may be a good solution. I was reluctant to use generics at first because it tends to spread quickly but I'll give it a try :)

[andreyz]

You're right, there isn't a need for higher order reducer here, it was a convenient example of deliberate use of generics in TCA.

There's nothing wrong with using generics in this case, since generic reducers won't be subclassed and hopefully will get specialized at the point of use.

[alexito4]

That episode ending was a big cliffhanger :D I personally don't like at all the vertical modules and we're not using that in our project. Our approach is more horizontal, but that requires often making a "third module" that wraps other two, it's what I call "The third package rule" 😂 I wrote about our approach here iOS App Architecture in 2022.

I'm sure they will present us something interesting in some upcoming video ^^

[pro100filipp]

I think the correct answer is provided in the TCA's documentation regarding navigation.

This is by far the simplest way to navigate to a screen, but it also has its drawbacks. In particular, it makes modularity difficult since the view that holds onto the NavigationLink must have access to the Path.State type, which means it needs to build all of the Path reducer, including every feature that can be navigated to.
This hurts modularity because it is no longer possible to build each feature that can be presented in the stack individually, in full isolation. You must build them all together. Technically you can move all features’ State types (and only the State types) to a separate module, and then features can depend on only that module without needing to build every feature’s reducer.
Another alternative is to forgo NavigationLink entirely and just use Button that sends an action in the child feature’s domain:

Form {
  Button("Detail") {
    store.send(.detailButtonTapped)
  }
}

Then the root feature can listen for that action and append to the path with new state in order to drive navigation:

case .path(.element(id: _, action: .list(.detailButtonTapped))):
  state.path.append(.detail(DetailFeature.State()))
  return .none

[JanC]

This delegate navigation pattern is what I used in my question/answer #3265 (comment)