First, we did a refactor we've been wanting to do for a long time. isowords' domain has held onto non-optional Settings.State and has shared this state through various computed properties. This meant introducing a bunch of awkward domains and transformation to make settings available to various features. This pattern is an extension of the "shared state" case study we originally shipped alongside the Composable Architecture. While the pattern is interesting, it introduces a bunch of boilerplate that is difficult to maintain over time and as a project grows.
Since first exploring this pattern of shared/computed state we have come to the conclusion that shared state should come from a dependency instead, and then features that need access to this state can simply ask the dependency for it. And in this case it means pushing UserSettings into a UserSettingsClient that can be queried, updated, and subscribed to. Moving this state into a dependency means all settings screens can be simple, optional presentations rather than contortions of sharing the same non-optional state.
Navigation Finesse
With settings as a dependency, we were able to remove some extra domains in the app, most notably the GameFeature, which was simply a computed part of state that made settings available to the game feature. The game can now present settings directly, home can present the game directly, and features can more reliably request dismissal rather than rely on delegates to do the job manually.
This PR builds off #185. It's a big one!
Settings Dependency
First, we did a refactor we've been wanting to do for a long time. isowords' domain has held onto non-optional
Settings.Stateand has shared this state through various computed properties. This meant introducing a bunch of awkward domains and transformation to make settings available to various features. This pattern is an extension of the "shared state" case study we originally shipped alongside the Composable Architecture. While the pattern is interesting, it introduces a bunch of boilerplate that is difficult to maintain over time and as a project grows.Since first exploring this pattern of shared/computed state we have come to the conclusion that shared state should come from a dependency instead, and then features that need access to this state can simply ask the dependency for it. And in this case it means pushing
UserSettingsinto aUserSettingsClientthat can be queried, updated, and subscribed to. Moving this state into a dependency means all settings screens can be simple, optional presentations rather than contortions of sharing the same non-optional state.Navigation Finesse
With settings as a dependency, we were able to remove some extra domains in the app, most notably the
GameFeature, which was simply a computed part of state that made settings available to the game feature. The game can now present settings directly, home can present the game directly, and features can more reliably request dismissal rather than rely on delegates to do the job manually.