Monday Feb 13, 2023
We are very excited to officially share a preview of what 1.0 will bring to the Composable Architecture. We want to be clear upfront that there are no episode or library spoilers in this post, and we are not yet announcing a beta for the navigation tools even though we have started that series. That beta will come in a few weeks.
The 1.0 of the library is something we outlined 4 months ago, and we are now officially starting the process. In a nutshell, 1.0 does not add any actual new features to the library but instead finally cleans up cruft that has accumulated over the years, such as removing most of the 1,100 lines of deprecations and finally renaming
We want to reiterate: 1.0 of the Composable Architecture is not a grand rethinking of the library or a feature-rich release. It is merely a breaking change to get rid of tools that have been long deprecated (some of them have been deprecated for years) and to give other tools their proper names.
So then, what is the 1.0 “preview”? It is a branch that you can target today if you want to get a head start on preparing for 1.0.
The branch we are releasing is
prerelease/1.0. It is a mostly backwards-compatible version of the library that we will keep up-to-date with the latest release from
main, but it makes a few important breaking changes:
Reducernow refers to the reducer protocol, not the struct that is generic over state, action and environment.
ReducerProtocol = Reducerhas been added.
So, this change is only a breaking change if you are still using the old
Reducer type alias that refers to the
AnyReducer struct. If you are on the
ReducerProtocol, which has been out for 4 months, then you should be good to go. Or, if you have updated your uses of
AnyReducer, you should only have deprecation warnings.
Effecttype now has one single generic for
Failuregeneric has been removed.
EffectTask = Effecthas been added.
So, this change is only a breaking change if you still refer to the old
Effect type alias. If you are using the
EffectTask type, which has been suggested for over 4 months, then you should be good to go.
Even though there are some breaking changes, the fixes are usually quite simple. For example:
If you are still using the old
Reducer struct type alias, you can simply rename it to
-Reducer<MyState, MyAction, MyEnvironment> +AnyReducer<MyState, MyAction, MyEnvironment>
If you are using the
Effect type with two generics, you can simply rename them to
EffectPublisher. Or, better yet, if the
Effect type with two generics has a failure type of
Never, you can simply rename it to
EffectTask and remove the failure generic entirely. E.g.:
// For effects that can fail: -Effect<MyAction, Error> +EffectPublisher<MyAction, Error> // For effects that cannot fail: -Effect<MyAction, Never> +EffectTask<MyAction>
If your project has already prepared for the two breaking changes mentioned above, you may benefit from targeting the
prerelease/1.0 branch. That is:
Reducertype, and have either migrated all of your project’s reducers to take advantage of the
ReducerProtocol, or you have at the very least renamed all instances of
Effecttype, and have renamed all instances to
EffectTaskwhen the failure type is
prerelease/1.0 you will get a hard-deprecated view of all APIs that have been soft-deprecated over the past months. If you have no deprecations, you are in good shape for 1.0. If you have deprecations, this means you can begin to incrementally chip away at them to prepare for 1.0’s release in the coming months.
Unless you are fully committed to living on the edge and working with beta software, we do not recommend fully adopting the
prerelease/1.0 branch, nor do we recommend adopting the
Effect renames that come along with it. If you are committed, though, we value your feedback! Please discuss any issues that crop up in these forums, and we’ll do our best to make the experience and smooth as possible for a beta.
For those that do adopt the
prerelease/1.0 branch, we also do not recommend literally tracking
prerelease/1.0, as that will continually track every single change to the branch. Instead, we recommend pinning to an exact Git SHA, and updating this SHA when you are prepared for the changes that come along with it.
In the near future, as we get closer to the official 1.0 release, we may introduce additional branches that you can target to help you update your codebase to be 1.0 compliant. For example, we will have a branch to track all forthcoming “0.x” releases, which will include all of the new navigation tools, but will also be 100% backwards-compatible with the library today.
The navigation tools that we have just begun covering are coming soon, but not right now. We will be opening a public beta in the coming weeks just as we did with async/await effects and the
Reducer protocol. This will give you a chance to play around with the tools before their final release and provide feedback.
Our plan is for the navigation beta to work both with
main, which means it will be 100% backwards compatible with your project today, and also work with
prerelease/1.0. There will be more information on that soon!
Please give the
prerelease/1.0 branch a spin and let us know what your feedback is. Consider the branch a “beta”: it may have mistakes, deprecations may behave in strange ways, etc. If you encounter any issues, let us know!
We are excited to finally bring the Composable Architecture to 1.0, though, and we have more big announcements coming soon.
👋 Hey there! If you got this far, then you must have enjoyed this post. You may want to also check out Point-Free, a video series covering advanced programming topics in Swift. Consider subscribing today!