Road to 1.0 #1477
Replies: 12 comments 63 replies
-
|
We have another change we'd like to make, but it requires more input from the community. We currently support iOS back to 13 as well as Swift 5.5+5.6. That comes with a decent amount of code complexity (we have lots of So, we'd like to drop support for iOS 13 and Swift 5.6 in the 1.0 release of TCA. Two things to keep in mind if you need to support iOS 13 or Swift 5.6:
So, is this going to be problematic for a large number of people? |
Beta Was this translation helpful? Give feedback.
-
|
I will have a look soon at your experiment, this came to my mind when reading your comment. Basically we could have |
Beta Was this translation helpful? Give feedback.
-
|
The idea originally came from RxSwift code base IIRC with |
Beta Was this translation helpful? Give feedback.
-
|
The problem with this is that you would need to make |
Beta Was this translation helpful? Give feedback.
-
|
@mbrandonw you said:
Would the minimum deployment target be iOS 14 and Swift 5.7, or are you thinking of being even more aggressive there? |
Beta Was this translation helpful? Give feedback.
-
|
We're thinking we should be able to maintain iOS 13 compatibility, but would like to require Swift 5.7 if possible. |
Beta Was this translation helpful? Give feedback.
-
|
Is there hope for native CasePaths to make it into the library in 1.0? |
Beta Was this translation helpful? Give feedback.
-
|
Do you mean into the language? We'd love for Swift to ship with case paths, but we don't think it will before our library is 1.0, unfortunately! |
Beta Was this translation helpful? Give feedback.
-
|
@stephencelis that's a bummer 😞 As I understand swiftlang/swift#58940 is the latest in terms of implementation, but we're missing a pitch to kickstart the discussion within the community. Is this initial pitch something you may have enough bandwidth to put out before the end of the year, or is it off the cards completely? Update: "ask and you shall receive" I guess 😄 https://forums.swift.org/t/enum-case-keypaths/60899 |
Beta Was this translation helpful? Give feedback.
-
|
For those watching, we merged #1478 yesterday, which will hard-deprecate any instances of @tgrapperon has also done some corresponding work for the |
Beta Was this translation helpful? Give feedback.
-
|
Sorry but what's the difference between a "hard-deprecate" and just a normal or "soft (?) deprecate"? |
Beta Was this translation helpful? Give feedback.
-
|
@tylerjames AFAIK:
|
Beta Was this translation helpful? Give feedback.
-
|
Soft deprecated also shows up in docs. It's just a small step we can take to guide people to the correct, future API before we are ready to fully deprecate. |
Beta Was this translation helpful? Give feedback.
-
|
We just posted a side discussion about another change we'd like to make for 1.0: Deprecating Let us know what you think! |
Beta Was this translation helpful? Give feedback.
-
|
Another update! We just released 0.43.0 as the first step mentioned in this post. |
Beta Was this translation helpful? Give feedback.
-
|
Hot take: It seems we have a unique and time-limited opportunity to be a little bolder with new APIs and experiment with a few things that were kept apart to avoid increasing the surface too much. I was for example thinking about generalized Furthermore, an hypothetical |
Beta Was this translation helpful? Give feedback.
-
|
Yes please ! There was a lot of nice ideas during the last two years that stayed in forks or even branches here but it's hard to keep up. Having a central place for experiments would greatly simplify tracking those and I think could boost contributions / early reviews. This also would provide more context to ppl with new idea of what was already tried and or rejected. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @tgrapperon, I think we can definitely start shipping more experimental APIs, and Stephen and I have discussed a few we'd like to try out. I'm imagining we would just ship the experiments directly in the library hidden behind But I'm not sure that is related to the 1.0 release. In fact, it might be better to kick off the first experiments after 1.0 to minimize churn. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback @mbrandonw. I think there were two subjects in my comment, so I'll elaborate more distinctly Pre 1.0By semver, the version 1.0 is potentially a breaking change version. We've already planned a few with the 1.0 and afterI'm assuming that the Of course, one can do without |
Beta Was this translation helpful? Give feedback.
-
|
How long will it roughly take to get the beta up for navigation? There some old UIKit views I currently have that I'm looking to refactor to SwiftUI but lack of navigation support is making me second guess using TCA for now (well just for that feature, still using TCA in other parts of the app) |
Beta Was this translation helpful? Give feedback.
-
|
Phew 😮💨. I thought it was psychological trick to mentally prepare everyone 😂. Patiently waiting for it. I've stopped refactor work for a feature from UIKit to SwiftUI in anticipation of this. That particular feature is all about navigation and I really really want to use TCA with it. Btw no pressure |
Beta Was this translation helpful? Give feedback.
-
|
@atimca Yeah that's the dream everyone updates straightaway. I think I read somewhere iOS 15 was more popular currently than iOS 16. Because Apple found some vulnerabilities in iOS 15. Resulting lots of companies "recommending" there employees to upgrade to latest iOS 15 version (before iOS 16 came out of course). So even users reluctant to upgrade there OS had to and now they're not. |
Beta Was this translation helpful? Give feedback.
-
|
Good to hear that UIKit and iOS <16 are still in scope. Unless I start some side projects of my own I probably won't be able to use iOS 16 until 2025. I do wish Apple release some official backports |
Beta Was this translation helpful? Give feedback.
-
|
Yep. Not sure what the reasoning for only supporting certain features in latest iOS. They even back ported swift concurrency from iOS 15 to iOS 13. Maybe more stuff can be back ported as well. Well maybe they can but hopefully they will. |
Beta Was this translation helpful? Give feedback.
-
|
I think that comes down to a difference between Swift, the language, and Apple frameworks that use Swift. |
Beta Was this translation helpful? Give feedback.
-
|
Will the new navigation features be applicable to UIKit apps? |
Beta Was this translation helpful? Give feedback.
-
|
The navigation features at the reducer-level should be universally usable in SwiftUI, UIKit, and more. We only plan on shipping view helpers for SwiftUI, but the existing |
Beta Was this translation helpful? Give feedback.
-
|
Has there been any consideration given to this shape of reducer as part of 1.0? func reduce(state: inout State, action: Action) async -> Action?Why not just return optional actions asynchronously rather than returning a task? Then instead of returning case .someAction:
return .task {
let result = await dependency.asyncWork()
return .otherAction(result)
}case .someAction:
let result = await dependency.asyncWork()
return .otherAction(result)I suspect it has something to do with cancellation? |
Beta Was this translation helpful? Give feedback.
-
|
AFAIK it's because of Custom Executors not being quite there yet in terms of implementation. Cancellation should be possible to do via proper custom executor support. I believe the other half of the picture was to make |
Beta Was this translation helpful? Give feedback.
-
|
So this is more like a 2.0 change then? |
Beta Was this translation helpful? Give feedback.
-
|
I don't think this signature is possible for a couple reasons, but if you explore and find something promising, please do share! First, I think exposing Second, returning We're definitely open to interesting explorations of TCA "from scratch" with all of Swift's modern tools, though. |
Beta Was this translation helpful? Give feedback.
-
|
Once 1.0 version is released. Are you guys planning on doing a video on how to use composable architecture again? I found the original video very helpful. I believe it was the 100th. Very in-depth. I think people will find this extremely useful @stephencelis @mbrandonw |
Beta Was this translation helpful? Give feedback.
-
|
Yup! That's definitely something we'd like to cover from scratch now that the library has evolved pretty far from its origins. |
Beta Was this translation helpful? Give feedback.
-
|
anyone else spamming refresh seeing if there's going to be a new pinned discussion this weekend? 🤞🤠!! |
Beta Was this translation helpful? Give feedback.
-
|
To be honest, I've been looking through all of PointFree's GitHub repos and seeing what branches have been recently updated (cough cough navigation cough cough). Unfortunately for us, Brandon and Stephen are covering their tracks pretty well and I have no idea what is coming our way :( |
Beta Was this translation helpful? Give feedback.
-
|
I think next week will most likely be off whilst they refine navi-cough-cough. I'm personally not holding my breath until next weekend. We could be pleasantly surprised though 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
Oh that's a good point. I'll just have to catch up on some of their other videos until then 😃 |
Beta Was this translation helpful? Give feedback.
-
|
lets gooooooo team TCA (rooting for you guys, however long it takes) |
Beta Was this translation helpful? Give feedback.
-
|
I took my time to read all the threads and the ideas from the community and it's really amazing to see all the attention to TCA evolution. Great job to all the people making this possible! 😃 @stephencelis @mbrandonw I have a question, Do you have any plans to make TCA library platform agnostic for 1.0 or X.0 ? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @pitt500, we aren't going to get platform independence for the library in 1.0, but it could possibly be a goal for 2.0. With the new macro features, |
Beta Was this translation helpful? Give feedback.
-
|
That sounds cool. I'm not familiar with Swift Macros yet, Do you have a link that I can take a look? Thanks in advance. EDIT: I found this btw https://github.com/DougGregor/swift-macro-examples |
Beta Was this translation helpful? Give feedback.
-
|
And here's a dashboard of current state of the various proposals: https://gist.github.com/DougGregor/de840fcf6d6f307792121eee11c0da85 |
Beta Was this translation helpful? Give feedback.
and others
-
It’s been almost 2 and a half years since we first released the Composable Architecture, so we’ve been getting more and more questions about its 0.x.x prerelease versioning, what’s holding up a 1.0, and (mostly jokingly) whether it’s “ready for production” yet 😆
We thought it’d be a good opportunity to lay out our roadmap, and detail our plans for rolling out some of the first breaking changes we’d like to introduce in preparation of the release.
What’s missing?
We’ve held off on 1.0 for this long not because we believe the library is in beta/unstable territory, but because there were a few key problem areas of library use that came up again and again, and we wanted to provide the nicest built-in solutions to them before considering the Composable Library a “complete” package.
We’ve slowly chipped away at these problem areas, which led to two significant public betas this year:
Concurrency: We wanted to make working with effects in the Composable Architecture much more approachable. Rather than require library-level use of Combine, which is powerful but comes with a significant learning curve, we introduced a friendlier set of async-await APIs.
Protocol: We finally merged this feature on Monday, and it introduces a friendlier, more modern interface for building features in the Composable Architecture.
So...what's left!?
Navigation
We think the final “missing” feature is a holistic story for navigation. Navigation is a significant part of any application, and while the Composable Architecture has shipped with demonstrations of navigation from its first release, we’ve been far from happy with them.
So we’ve been experimenting with better navigation tools from day one, and over time have made significant strides. SwiftUI 3 completely revamped its stack navigation, so we’ve done our best to digest these changes and intend to ship tools that fully embrace all of SwiftUI’s navigation idioms, and even improve upon them.
So Navigation is our next and final focus before shipping a 1.0. We still have some experimentation and polish to do, but when we’re ready we’ll have another beta period waiting for you!
Other in-flight work
We have many ongoing experiments in the Composable Architecture that we do not consider blockers for 1.0. Some of these features will make their way in before 1.0 is released. This includes work on a "non-exhaustive" version of the test store first demonstrated by @krzysztofzablocki.
Breaking changes
Throughout the 0.x.x period, we’ve done our best to maintain source compatibility across releases, and we’ve managed a large catalog of deprecations over many many releases. This means that all changes have been additive, even changes that have been complete reimaginings of existing features, like the
ReducerProtocol. 1.0 gives us the opportunity to shed off some of these deprecated features, and tidy up the new features in the process.There are two major changes we’d like to make that will require a few releases and some churn for our users, but we hope that you all find it worth it!
Removing the old
ReducerstructThe
ReducerProtocolis now the de facto way of building reducers in the Composable Architecture. Alongside its release, we renamed the existingReducerstruct toAnyReducer, but provided a soft-deprecated type alias for compatibility.ReducerProtocolis a mouthful, though, so we’d like to take steps over a few releases to fully deprecate the oldReducerstruct and finally renameReducerProtocoltoReducer. We will accomplish this in the following releases:Very soon we plan on shipping 0.43.0 and hard-deprecating the
Reducertype alias. This will introduce a number of warnings to projects that have not yet migrated to theReducerProtocol. To fix these warnings, you can simply rename all instances ofReducertoAnyReducer, and Xcode should be able to help a lot with that.After 0.43.0, we will introduce a release candidate branch for 1.0 that will directly track the most recent release in the library with some additional, bigger breaking changes. Targeting this branch in your project will allow you to get a head start on being fully 1.0-compatible.
The changes include:
typealias Reducer = AnyReducerReducerProtocoltoReducertypealias ReducerProtocol = ReducerIf you have already updated your code base to 0.43.0, then none of these changes are breaking. You will just have to rename occurrences of
ReducerProtocoltoReducer, which Xcode should be able to help with.Closer to 1.0’s release, we will take steps to fully deprecate
AnyReducerand its APIs.Our aim is to minimize friction, despite the above changes. So with 1.0 we do not plan on leaving folks that rely on
AnyReducerbehind. Instead, we plan on allowing folks to continue to useAnyReducer, but we will hide this deprecated type and its APIs from view, either as a companion module that you will need to import, or by utilizing@_spiimports to hide them from view and use unless specifically imported via@_spi(AnyReducer) import ComposableArchitecture.Removing many Combine-specific features of
EffectWith the Concurrency release, we vastly simplified the
Effecttype, with a focus on 3 entry points for creating effects using Swift Concurrency (.run,.task, and.fireAndForget). In the process, we soft-deprecated much of the type’s existing Combine integration, and before 1.0, we’d like to remove as much of this legacy integration as possible. Folks that like using Combine can continue to do so by iterating over Combine’sAsyncPublisherasync sequence in anEffect.run.Effectwas initially designed to be used as a Combine publisher, so it picked up some quirks from Combine that feel no longer necessary. For example, it picked up aFailuregeneric from thePublisherprotocol, but thisFailureis always locked toNeverwhen used from within a reducer.With the new entry points designed for Swift Concurrency, the
Failuregeneric no longer makes sense, so we’d like to simplifyEffect<Action, Failure>toEffect<Action>. We intend to do so over a number of releases, in a fashion similar to our planned rename of theReducerProtocol:With 0.43.0, we will rename
EffecttoEffectPublisherand provide a soft-deprecated typealias forEffect = EffectPublisherso that existing code still compiles. We will also introduce a typealiasEffectTask<Action> = Effect<Action, Never>, which will be the new type you should start using in your reducers. We will also update the reducer signature to useEffectTaskfor simplicity.Shortly after (in 0.44.0?), we will hard-deprecate the
Effecttype alias, which means those usingEffect<Action, Never>can just rename toEffectTask<Action>, and those that useEffectwith a non-Neverfailure can either take the opportunity to convert that code to async/await, or they can rename toEffectPublisher.And then, we will make the following changes to the prerelease 1.0 branch so that you can get a head start on updating your codebase to be 1.0-compliant:
Effecttype aliasEffectTasktoEffecttypealias EffectTask = Effectso that all existing uses ofEffectTaskcontinue to work, and Xcode should be able to help make these changes for you.Closer to 1.0’s release, we will take steps to fully deprecate
EffectPublisherand its APIs. And similar to how we handled the removal ofAnyReducerby using@_spi, we will hideEffectPublisherbehind@_spiso that it is still accessible, but just with extra work of needing to specify@_spiwhen importing the Composable Architecture.We want your input!
These changes are not insignificant, but we believe they pave the way to a simpler 1.0 that will be easier to introduce to your team mates and colleagues 🙂
It’s worth mentioning that the beta period for our navigation tools will probably be comparable to what it was for the reducer protocol, and so that means the 1.0 prerelease branch will be around for quite awhile so that people should have plenty of time to update their codebases.
Please let us know if you see any issues with our strategies, or if you have any suggestions.
Beta Was this translation helpful? Give feedback.
All reactions