Composable Stacks: State Ergonomics

We’ve now cleaned up the reducer and the view and things are looking quite succinct.

However, we can take things much, much further. Let’s finally look at all this identifiable madness that we have let infect our code. We have needed to conform each of our features’ states to the Identifiable protocol, which typically does not make sense. We just kind of shoehorned it in by adding a randomly generated UUID. That was easy to do, but what wasn’t easy was to then further conform our Path.State enum to be identifiable, which forced us to define a conformance by switching over the enum and calling out to the id of each of our features. That code is a pain to maintain, and will need to be updated every time a new feature is added to the stack. And all of that was annoying enough without even talking about tests, which would be really annoying given all the uncontrolled UUIDs we just sprinkled throughout our code.

Stephen: Further, putting our features into a navigation stack also suddenly forced us to make our features’ state Hashable. That was easy enough to do as ideally all state structs are simple data types that can be automatically made Hashable, but also features can hold lots of state. We may have a really large feature with lots of child features, and hashing all of that data may be quite slow. We could provide a custom hash implementation that just hashes the ID that we’ve been forced to provide, but that is just more manual work to be done and it’s probably not correct to do. What if we did really want a proper Hashable implementation for the state that did hash all the data? We would be out of luck because we’ve trampled on that possibility due to all the strange choices we’ve been forced into.

So, let’s finally untangle ourselves from hashability and identifiability. We will create a new data type that behaves a lot like IdentifiedArray, but that is tuned specifically for navigation stacks.

Let’s try it out.