Replies: 30 comments 133 replies
-
|
Wow, this looks amazing! I've been a bit on the fence of whether I want to completely dive in and fully use TCA, but all this almost completely negates all my reservations I've had with it. Mainly the file scoped reducers straining the compiler so much. Can't wait to give this a try. |
Beta Was this translation helpful? Give feedback.
-
Have you considered Defaulting preview dependencies to live sounds rather crash-prone, given how many live APIs are incompatible with Xcode Previews still. |
Beta Was this translation helpful? Give feedback.
-
|
I'm personally dynamically switching for previews when it matters: public let isPreview: Bool =
ProcessInfo.processInfo.environment["XCODE_RUNNING_FOR_PREVIEWS"] == "1"
private enum APIClientKey: LiveDependencyKey {
static var liveValue: APIClient {
#if DEBUG
if isPreview {
return .preview
}
#endif
return .live
}
}Maybe this could indeed be implemented at a deeper level into the library. |
Beta Was this translation helpful? Give feedback.
-
|
@davdroman This is a great suggestion, and something we passingly discussed but never actually tried it out. We just opened PR #1284 to try it out and it works out great. Thanks for bringing this up! |
Beta Was this translation helpful? Give feedback.
-
|
If you happen to be using |
Beta Was this translation helpful? Give feedback.
-
|
OK, wow. This is excellent and the timing couldn't be better. I was just discussing the issue of dependency injection with a colleague on a sort of green field experimental project we're working on. We'll be switching onto this Beta branch for this. (Obvs aware that it may not be stable). But so far everything is switched over including my custom "higher order reducer" which now has even fewer constraints due to the fact that it can bring in the dependency itself rather than relying on the Environment of the Reducer it is wrapping. Amazing 😄 |
Beta Was this translation helpful? Give feedback.
-
|
I love this, thank you! I just watched today's episode and then found this discussion. Minor question... did you consider |
Beta Was this translation helpful? Give feedback.
-
|
+1 for BobsNewProtocol I think that conveys the intent in the clearest way possible. |
Beta Was this translation helpful? Give feedback.
-
|
The argument of “whatever name works and it doesn’t matter once explained” is not really helpful. While this is implicitly understood in every case, it should not be used as an excuse to not put the effort into choosing a clear and intuitive name. I get your name argument though. |
Beta Was this translation helpful? Give feedback.
-
|
True... and in the last sentence of my comment I was being slightly tongue in cheek. However, when talking about what is implicitly understood I'm not sure anyone could come up with something better than |
Beta Was this translation helpful? Give feedback.
-
We put a lot of thought and care into landing at "reducer," so I hope previous comments and discussion reflect that. We also understand that we can't please everyone, we just think a term of art is preferable to inventing something new, regardless of any baggage that comes along with it. As for tacking "-able", "-ible", etc., to the end, Oliver rightfully points out that these suffixes imply that the conformance itself has the quality. A I don't think you can describe a "reduce" function as being "reducible," though. What can you reduce about it? A reduce function can be described as a "reducer," though, which naming-wise follows in the footsteps of standard library protocols like |
Beta Was this translation helpful? Give feedback.
-
Oh, that definitely wasn’t for you. I’m an old fan and I have more than enough proofs for how much effort you both are willing to put. Anyway, I think the argument against my suggestion does make total sense. That’s why I stopped defending it. 😁 |
Beta Was this translation helpful? Give feedback.
-
|
I like Scope a lot. It makes it very clean to create container reducer. But noticed that if we have mixed reducer then need to use .ifCaseLet even if we don't have optional state, this means marking state optional. Unless I'm missing something, Scope can't be used with mixed reducer. |
Beta Was this translation helpful? Give feedback.
-
|
@DanKorkelia Just so I understand, do you mean you want That actually does exist: Scope(state: /State.newGame, action: /Action.newGame) {
NewGame()
}However, you should only use this style if there is no parent reducer that can set state to a different case. I think your example is taken from Tic-Tac-Toe's app-level reducer, which can change |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense! Thank you very much, just remembered you mentioned this pitfall in 201 episode! Thank you so much. |
Beta Was this translation helpful? Give feedback.
-
|
Love the Super happy about The design of the
public protocol DependencyKey {
/// The associated type representing the type of the dependency key's
/// value.
associatedtype Value
/// The default value for the dependency key.
static var defaultValue: Value { get }
}
Using the getter of the public struct DependencyValues {
// ... omitted for brevity
public subscript<K>(key: K.Type) -> K.Value where K: DependencyKey {
get {
let key = ObjectIdentifier(key)
// If we have stored value for the given key, return and exit.
if let value = storage[key] as? K.Value {
return value
}
#DEBUG
// If app is running in testing mode fail the test.
if ProcessInfo.Arguments.isTesting {
// We are here... it means that dependency value was not explicitly set.
// We should fail the test case and ask the user to explicitly provide the dependency.
let dependencyName = "\"\(K.Value.self)\""
let example = #"DependencyValues[\.pasteboard] = .stub"#
XCTFail("You are trying to access \(dependencyName) dependency in this test case without assigning it. You can set this dependency as: \(example)")
return K.defaultValue
}
#endif
// If app is running in normal mode, return the `default` value.
return K.defaultValue
}
set {
storage[ObjectIdentifier(key)] = newValue
}
}
}Few benefits of this approach:
Custom Rule test_case_superclass:
included: ".*.swift"
name: "Invalid XCTestCase use"
regex: "XCTestCase"
message: "Please \"import XCTestSupport\" and change the superclass to \": TestCase\" to ensure all of the dependencies are correctly set to failing before each test case."
severity: error// swiftlint:disable:next test_case_superclass
open class TestCase: XCTestCase {
open override func setUp() {
super.setUp()
DependencyValues.resetAll()
}
}Here is the current implementation of dependency and friends in its entiretyDependencyKey// MARK: - DependencyKey
/// A key for accessing values in the ``DependencyValues`` container.
///
/// You can create custom dependency values by extending the
/// ``DependencyValues`` structure with new properties. First declare a new
/// dependency key type and specify a value for the required ``defaultValue``
/// property:
///
/// ```swift
/// private struct MyDependencyKey: DependencyKey {
/// static let defaultValue: String = "Default value"
/// }
/// ```
///
/// The Swift compiler automatically infers the associated ``Value`` type as the
/// type you specify for the default value. Then use the key to define a new
/// dependency value property:
///
/// ```swift
/// extension DependencyValues {
/// var myCustomValue: String {
/// get { self[MyDependencyKey.self] }
/// set { self[MyDependencyKey.self] = newValue }
/// }
/// }
///
/// class MyTests: TestCase {
/// // Reset all of the `DependencyValues` storage.
/// func setUp() async throws {
/// DependencyValues.resetAll()
/// }
///
/// func testPasteboard() throws {
/// struct ViewModel {
/// @Dependency(\.myCustomValue) var myCustomValue
/// }
///
/// let viewModel = ViewModel()
/// XCTAssertEqual(viewModel.myCustomValue, "Failing value")
///
/// DependencyValues[\.myCustomValue] = "hello"
/// XCTAssertEqual(viewModel.myCustomValue, "hello")
/// }
/// }
/// ```
public protocol DependencyKey {
/// The associated type representing the type of the dependency key's
/// value.
associatedtype Value
/// The default value for the dependency key.
static var defaultValue: Value { get }
}Dependency// MARK: - Dependency
/// A property wrapper that reads a value from ``DependencyValues`` container.
///
/// Use the `Dependency` property wrapper to read the current value stored in
/// ``DependencyValues`` container. For example, you can create a property that
/// reads the pasteboard using the key path of the
/// ``DependencyValues/myCustomValue`` property:
///
/// ```swift
/// @Dependency(\.myCustomValue) var myCustomValue
/// ```
@propertyWrapper
public struct Dependency<Value> {
private let keyPath: KeyPath<DependencyValues, Value>
/// Creates an dependency property to read the specified key path.
///
/// Don’t call this initializer directly. Instead, declare a property
/// with the ``Dependency`` property wrapper, and provide the key path of
/// the dependency value that the property should reflect:
///
/// ```swift
/// struct MyViewModel {
/// @Dependency(\.myCustomValue) var myCustomValue
///
/// // ...
/// }
/// ```
///
/// - Parameter keyPath: A key path to a specific resulting value.
public init(_ keyPath: KeyPath<DependencyValues, Value>) {
self.keyPath = keyPath
}
/// The current value of the dependency property.
///
/// The wrapped value property provides primary access to the value's data.
/// However, you don't access `wrappedValue` directly. Instead, you read the
/// property variable created with the ``Dependency`` property wrapper:
///
/// ```swift
/// @Dependency(\.myCustomValue) var myCustomValue
///
/// func copy() {
/// print(myCustomValue) // prints "Default value"
/// }
/// ```
public var wrappedValue: Value {
DependencyValues[keyPath]
}
}DependencyValues// MARK: - DependencyValues
/// A collection of dependency values propagated using ``dependency`` property
/// wrapper.
///
/// A collection of values are exposed to your app's in an ``DependencyValues``
/// structure. To read a value from the structure, declare a property using the
/// ``Dependency`` property wrapper and specify the value's key path. For
/// example, you can read the current myCustomValue:
///
/// ```swift
/// @Dependency(\.myCustomValue) var myCustomValue
/// ```
public struct DependencyValues {
static var shared = Self()
var storage: [ObjectIdentifier: Any] = [:]
// Subscripts setter on key-path calls getter of the destination property.
// https://bugs.swift.org/browse/SR-10203
private var isSetterOnKeyPathCalled = false
/// Accesses the dependency value associated with a custom key.
///
/// Create custom dependency values by defining a key that conforms to the
/// ``DependencyKey`` protocol, and then using that key with the subscript
/// operator of the ``DependencyValues`` structure to get and set a value for
/// that key:
///
/// ```swift
/// extension DependencyValues {
/// private struct MyDependencyKey: DependencyKey {
/// static let defaultValue: String = "Default value"
/// }
///
/// var myCustomValue: String {
/// get { self[MyDependencyKey.self] }
/// set { self[MyDependencyKey.self] = newValue }
/// }
/// }
/// ```
public subscript<K>(key: K.Type) -> K.Value where K: DependencyKey {
get {
let key = ObjectIdentifier(key)
// If we have stored value for the given key, return and exit.
if let value = storage[key] as? K.Value {
return value
}
#if DEBUG
// When we are calling set key path using
// `DependencyValues[\.myCustomValue] = "hello"` it invokes the getter first
// and in testing mode it incorrectly fails the tests when trying to set the
// dependency explicitly.
// See: https://bugs.swift.org/browse/SR-10203
if !isSetterOnKeyPathCalled {
// If app is running in testing mode fail the test.
if ProcessInfo.Arguments.isTesting {
let dependencyName = "\"\(K.Value.self)\""
let example = #"DependencyValues[\.pasteboard] = .stub"#
internal_XCTFail("You are trying to access \(dependencyName) dependency in this test case without assigning it. You can set this dependency as: \(example)")
return K.defaultValue
}
}
#endif
// If app is running in normal mode, return the `default` value.
return K.defaultValue
}
set {
storage[ObjectIdentifier(key)] = newValue
}
}
/// Accesses the dependency value associated with a key path.
public static subscript<T>(_ keyPath: KeyPath<Self, T>) -> T {
shared[keyPath: keyPath]
}
/// Accesses or updates the dependency value associated with a key path.
public static subscript<T>(_ keyPath: WritableKeyPath<Self, T>) -> T {
get { shared[keyPath: keyPath] }
set {
shared.isSetterOnKeyPathCalled = true
shared[keyPath: keyPath] = newValue
shared.isSetterOnKeyPathCalled = false
}
}
/// Reset all of the ``DependencyValues`` storage.
public static func resetAll() {
// We are clearing all of the dependencies, which will force next access to go
// through the `getter` in the `subscript` function above.
shared.storage = [:]
}
}Dependency View for Previews// MARK: - Dependency View
extension View {
/// Sets the dependency value of the specified key path to the given value.
///
/// Use this modifier in **previews** to set one of the writable properties of
/// the ``DependencyValues`` structure, including custom values that you create.
/// For example, you can set the value associated with the
/// ``DependencyValues/pasteboard`` key:
///
/// ```swift
/// struct Profile_Previews: PreviewProvider {
/// static var previews: some View {
/// ProfileView()
/// .dependency(\.pasteboard, .live)
/// }
/// }
/// ```
///
/// - Parameters:
/// - keyPath: A key path that indicates the property of the
/// ``DependencyValues`` structure to update.
/// - value: The new value to set for the item specified by `keyPath`.
///
/// - Returns: A view that has the given value set in its dependency.
public func dependency<V>(_ keyPath: WritableKeyPath<DependencyValues, V>, _ value: V) -> some View {
DependencyWriter(content: self) { values in
values[keyPath] = value
}
}
}
/// A view that writes dependency.
///
/// ```swift
/// DependencyWriter { values in
/// values[\.pasteboard] = .live
/// }
/// ```
private struct DependencyWriter<Content>: View where Content: View {
let body: Content
init(
content: @autoclosure @escaping () -> Content,
write: (DependencyValues.Type) -> Void
) {
self.body = content()
write(DependencyValues.self)
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Let's see how this goes when we integrate with our project. The two keys become cumbersome to deal with which is why we switched over to single key from original design and use getter to fail test if the explicit dependency was not set. But I understand the thinking behind the two keys. I've just tried to see if the single line approach would work and it was possible all along 🙃 and it works too. So thanks for helping me uncover it 😁 DependencyValues[\.audioRecorder].requestRecordPermission = { false } |
Beta Was this translation helpful? Give feedback.
-
|
Does that single line ensure the other lines will trigger |
Beta Was this translation helpful? Give feedback.
-
|
Yes. it's the same as above. The idea is:
Attempting to set an endpoint without setting the dependency fails the test
Setting the dependency first and then you can change whatever endpoint etc Added
|
Beta Was this translation helpful? Give feedback.
-
|
I think a sample project would be helpful so that we could tinker with it. Just to reiterate some of the things @stephencelis mentioned, the current system allows us to do a specific thing that I believe is not possible with what you are describing. Say we have a client with two endpoints: struct Client {
var fetchUsers: () async throws -> [User]
var updateUser: (User) async throws -> Void
}In this situation we have one endpoint that actually fetches data, but the other is doesn't return anything important, and so is a kind of "fire-and-forget". And in a reducer there's one user flow that only uses a single endpoint of the client: @Dependency(\.client) var client
…
case .buttonTapped:
return .run { send in
try await send(
.usersResponse(self.client.fetchUsers())
)
}Then, in tests we would like to override just that one single endpoint: let store = TestStore(…)
store.dependencies.client.fetchUsers = { [.mock] }
store.send(.buttonTapped)
store.receive(.usersResponse([.mock])) {
…
}So, that all works great, and your system will also work for that step up. Where we differ is what we would like to happen if the Like say we start updating a user in there as a fire-and-forget that runs in parallel: case .buttonTapped:
return .run { send in
async let _ = self.client.updateUser(state.selectedUser)
try await send(
.usersResponse(self.client.fetchUsers())
)
}With our system, this would immediately trigger a test failure because With your system it would silently pass because a store.dependencies.client = .unimplemented
store.dependencies.client.fetchUser = { … }…in order to get the behavior we want. And so this is why we are trying to nudge people into that direction from the very beginning when registering their dependencies with the library. BTW, we could also start a new topic for this discussion if you want more eyes on it. I've just created a beta category for our discussions. |
Beta Was this translation helpful? Give feedback.
-
|
The library has evolved a bit from when this discussion was had. The |
Beta Was this translation helpful? Give feedback.
-
|
I'm curious how you can use the @dependency system for dependencies that are not static and that require some dependencies of their own in order to be constructed. For example a I have started integrating TCA into some leaf nodes of my app and putting those features into modules. Consequently I have a huge "outside world" where my API clients and the rest of my app lives and my feature's initial State, Environment, and Store would be constructed by some non-TCA code. My I'm not sure how to build my |
Beta Was this translation helpful? Give feedback.
-
|
@tylerjames I've spun off a sub-discussion here: #1287 Let us know what you think! |
Beta Was this translation helpful? Give feedback.
-
|
Excellent, thanks! |
Beta Was this translation helpful? Give feedback.
-
|
This looks like a great move towards a cleaner API. You mentioned this approach will have performance gains around the number of stack frames and stack size, our biggest performance issue we've had using TCA in production is send recursion when you have a large app with lot's of features and child features. Will this move to protocols have a positive effect on the issue of send recursion? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah sure, I'll start a discussion at some point soon with a demo project! |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Very simple repo with extreme performance issues attached to the discussion |
Beta Was this translation helpful? Give feedback.
-
|
My team is experiencing this issue as well (exactly related to load more case) even though we had single Store on each page, but when the page getting more complex, it has tons of scope and the performance is noticeable. Btw my company is using RxSwift based TCA |
Beta Was this translation helpful? Give feedback.
-
|
Hi @jeffersonsetiawan, we have made a number of performance improvements recently, but you will need to port them all over to your fork. Hopefully you can move over to the official library soon, because it is going to be increasingly difficult to keep up-to-date with all of our upcoming changes. |
Beta Was this translation helpful? Give feedback.
-
|
Great stuff! I'm looking at updating a project for the beta, and I'm a bit confused about migrating some stuff. The migration guide has the following suggestion for migrating over a single reducer from the old to new style: should become: This works for the specific case in the guide, but there don't seem to be any affordances for optional pullbacks here. As far as I can tell the only way to get optionals working is this style, which requires both an empty reducer and for you to explicitly ignore the AnyReducer's argument using an underscore (In my case I have updated the dependencies to use Am I missing something here, or is this the recommended approach? |
Beta Was this translation helpful? Give feedback.
-
|
Good idea to add a "composition" section to the migration guide! It is mentioned in the announcement above, though a bit hidden:
The protocol uses Reduce { state, action in
// parent logic
}
.ifLet(state: \.child, action: /Action.child) {
Child()
}We'll also do our best to direct folks in the soft deprecation docs for the existing endpoints. That deprecation is blanketed over the entire |
Beta Was this translation helpful? Give feedback.
-
|
Yep, I'm aware of and using ifLet, ifCaseLet, and some custom modifiers I've already built on top of them for routing with ReducerProtocol, but can those be used when combining into using the "old" style |
Beta Was this translation helpful? Give feedback.
-
|
Tangential, but it would also be really nice to have a variant of |
Beta Was this translation helpful? Give feedback.
-
|
For adapting new reducers into old style chains, you use expenseReducer
.pullback(state: \Identified.value, action: .self)
.optional()
.pullback(state: \SignedInState.selectedExpense,
action: /SignedInAction.expense,
environment: { ExpenseDomain.Environment(api: $0.api) })became AnyReducer { environment in
ExpenseDomain(environment: .init(api: environment.api))
}
.pullback(state: \Identified.value, action: .self)
.optional()
.pullback(state: \SignedInState.selectedExpense,
action: /SignedInAction.expense,
environment: { ExpenseDomain.Environment(api: $0.api) })To go the other way (using an old reducer in a new builder) you can use a |
Beta Was this translation helpful? Give feedback.
-
|
Since this thread is getting long, consider starting a new discussions about the new ways of composing reducers, as well as migration paths, if you'd like to flesh out your thoughts on either (we added a fancy new "Beta" topic with a 🤠 emoji). |
Beta Was this translation helpful? Give feedback.
-
|
Didn't have time to test this in my project (and great work overall!) but there's already one thing that throws me off: @Dependency(\.date) var dateThe naming here implies that I will get a Thus, I believe a more explicit naming here would be a better choice considering that long-term using @Dependency(\.nowDate) var nowDateOr even just: @Dependency(\.now) var now |
Beta Was this translation helpful? Give feedback.
-
|
As an aside, and like extension DependencyValues {
public var now: Date {
self.date()
}
}And use |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for all the answers. I personally prefer clarity over brevity (as per the Swift API Design Guidelines), so I can see now that things seem to be quite flexible even with the new |
Beta Was this translation helpful? Give feedback.
-
|
@Jeehut Thanks for the discussion! We think it's worth adding a convenience property to |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! 💯 |
Beta Was this translation helpful? Give feedback.
-
|
If it helps with readability you can also explicitly spell out the type, e.g.: @Dependency(\.date) var date: () -> DateWe already adopt this approach with SwiftUI @Environment properties as I've always disliked the lack of explicit types when there's no default value to infer it from at the definition site, instead requiring you to find the environment key definition to find out what the type is. |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to implement a BindingReducer() in the beta branch following the docs here... https://github.com/pointfreeco/swift-composable-architecture/blob/protocol-beta/Examples/CaseStudies/SwiftUICaseStudies/01-GettingStarted-Bindings-Forms.swift But I'm getting two errors.
When I try to fix it it adds an empty reduce function.
Not sure if I've missed something somewhere though? Thanks |
Beta Was this translation helpful? Give feedback.
-
|
Oh hang on... does this require Swift 5.7 by any chance? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, if you're using |
Beta Was this translation helpful? Give feedback.
-
|
💥 Thanks! Thank you for persevering @tgrapperon 😄 |
Beta Was this translation helpful? Give feedback.
-
|
It was obvious from the error message, I should have spotted it earlier! |
Beta Was this translation helpful? Give feedback.
-
|
was there a change in Swift APIs that caused this seemingly breaking change from time the examples were written & usage now? curious. thanks for fix all! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks to everyone for all their great questions and feedback! This thread is getting a little more popular than we expected, so we have now created a dedicated beta category in GitHub discussions. Feel free to start a new topic there in order to get more visibility to your questions. 🤠 |
Beta Was this translation helpful? Give feedback.
-
|
@mbrandonw Thanks for this :) |
Beta Was this translation helpful? Give feedback.
-
|
Haven't started using this but it already sounds exciting! |
Beta Was this translation helpful? Give feedback.
-
|
This is AMAZING!!! I was so excited to learn of the features, I spoiled it all for myself so I can start integrating this functionality to my app right away :) I have a question. I'm trying to figure out how to migrate the ReducerProtocol changes to a UIViewController with a ViewState object: Is it just a matter of creating a It's probably as easy as that, but I don't know if I'm missing something :) |
Beta Was this translation helpful? Give feedback.
-
|
That's all there should be to it! Most of the changes are in the reducer layer, not the view. |
Beta Was this translation helpful? Give feedback.
-
Wow it's that easy!!! I haven't had any problems so far, but I'll certainly let you know! Thanks for everything that you guys are doing 🥳🥳🥳 |
Beta Was this translation helpful? Give feedback.
-
|
Now that dependencies can be added to a specific module using keys and the @dependency decorator, we no longer have to pass dependencies down a chain like before. My question however is whether this means we are inherently choosing to add some duplicate code if you have a situation where you have two modules that use the same dependency but are not totally related. Let's say for instance that you have a Home, Settings1, and Settings2 module. Let's also say I have a dependency deviceOrientation: () -> UIDeviceOrientation that I want to use in both Settings1 and Settings2. The way it worked before is that when you're instantiating the Settings environment from Home, it would've inherited the dependency at that point. However, there is no longer a "source of truth" because the boilerplate setup is quite annoying. We can't just define these dependencies in Home because if Home depends on Settings, you would introduce a circular dependency. I suppose you can create a new module specifically for dependencies and that would address this problem. In the examples though, I got the impression that these keys are defined in the module that uses the dependency. Is it implied that developers would prefer duplicate key code setup over the boilerplate chaining that was occurring before, or is there a way that I'm missing that would allow users to only setup the DependencyKey once, but would work on two modules that themselves don't have any direct or indirect dependency on each other? I imagine the answer is "Create a dependency module so it acts as source of truth", but I wanted to ask and make sure 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
The way I have created dependencies so far is to define the dependency and the key in the module the same module. So for instance I have an ApiClient module. In it I define the ApiClient type and the .apiClient dependency key. Anything that then wants to use that dependency has to import the ApiClient module. (If I correctly understood your question) The chaining of dependencies onto the root Reducer is not creating the keys but overwriting the default value for each given key. |
Beta Was this translation helpful? Give feedback.
-
|
Ah okay, that sounds like a good idea. In fact, in my specific use-case, it'd be perfect to house the deviceOrientation function in a DeviceClient module. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
In my early experiments with the pre-beta branch, I also found the best approach is to always define the main dependency key (including the unimplemented testValue) alongside the dependency client in its own module. The live dependency key definition can live either inside the module (if it has no external dependencies/or configuration and can be easily statically initialised) or if creating the live dependency is a bit more involved, define it in the main app target. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a way to have |
Beta Was this translation helpful? Give feedback.
-
|
I believe you can control these by setting the myReducer.dependency(\.context, .test) |
Beta Was this translation helpful? Give feedback.
-
|
The migration article link appears to be dead |
Beta Was this translation helpful? Give feedback.
-
|
We renamed the doc, here's the freshest link: https://github.com/pointfreeco/swift-composable-architecture/blob/protocol/Sources/ComposableArchitecture/Documentation.docc/Articles/ReducerProtocols.md |
Beta Was this translation helpful? Give feedback.
-
|
@mbrandonw that one is a 404 as well |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Ah yes, thanks @rzulkoski for responding! 🙂 Hopefully last rename before merging. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
If it's just an oversight, migrators can use this for now: @inlinable
func forEach<Element: ReducerProtocol, Key>(
_ toDictionaryState: WritableKeyPath<State, [Key: Element.State]>,
action toKeyedAction: CasePath<Action, (Key, Element.Action)>,
@ReducerBuilderOf<Element> _ element: @escaping () -> Element,
file: StaticString = #file,
fileID: StaticString = #fileID,
line: UInt = #line
) -> CombineReducers<ReducerBuilder<Self.State, Self.Action>._Sequence<Reduce<Self.State, Self.Action>, Self>> {
CombineReducers {
Reduce { state, action in
AnyReducer {
element()
}
.forEach(
state: toDictionaryState,
action: toKeyedAction,
environment: { _ in },
file: file,
fileID: fileID,
line: line
)
.callAsFunction(&state, action, ())
}
self
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Are tests still supposed to work when you append a reducer with .debug()? I'm seeing this appear when I slap the end of an initialized reducer with it: |
Beta Was this translation helpful? Give feedback.
-
|
@acosmicflamingo We're tracking down some issues around effects and concurrency and testing stability. Can you pull the latest version and see if it's more reliable? If not, we still have a bug we need to track down. |
Beta Was this translation helpful? Give feedback.
-
|
(As an aside, you can always add an explicit |
Beta Was this translation helpful? Give feedback.
-
|
I pulled the latest commit and unfortunately, the issue still appears. I'm sorry to be the bearer of bad news :( but at least there's a cool |
Beta Was this translation helpful? Give feedback.
-
|
@acosmicflamingo We pushed an update that suppresses the debug reducer's behavior for tests, which should allow you to write tests again without For what it's worth, one thing we like to do is only apply |
Beta Was this translation helpful? Give feedback.
-
|
Oh I understand! Thank you very much for the info and looking into these issues :D |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I'm trying to add the Composable Architecture (protocol-beta branch) in an existing iOS/WatchOS project on Xcode 13.4.1. I first encountered an error on the library integration in XCode which was also built for MacOS and was generating an error at the Composable architecture configuration: Now I'm facing issues compiling my project as composable architecture types are not found by the compiler:
I tried to follow the documentation and embedded the library in my project as I have more than one target :
I'm new to swift development and XCode and I don't see what I did wrong. Is there a documentation on how to configure a project in XCode to use the Composable Architecture ? Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
@fred00 Any chance you can reproduce in a fresh project that you can share here? Adding TCA to a project should be the same as adding any SPM package. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @stephencelis. I created a fresh project and added TCA to it without any issue. I then deleted TCA from my existing project and added it again and it is now building correctly. I think I misunderstood the installation part saying "If you want to use this library from multiple Xcode targets, or mixing Xcode targets and SPM targets, you must create a shared framework that depends on ComposableArchitecture and then depend on that framework in all of your targets.". When adding the package, we should not do anything on the primary target, the framework must only be manually added to the secondary one (in my case the WatchOS target). |
Beta Was this translation helpful? Give feedback.
-
|
Reducible doesn’t really make sense - the confirming type is not the
thing that is being reduced, it’s the state that is being reduced.
The conforming type is the thing that is capable of doing the reducing
therefore Reducer accurately describes this capability. I’m not sure
there’s a lot of benefit in trying to change a grammatically correct
term of art.
On September 13, 2022, GitHub ***@***.***> wrote:
How about Reducible? This goes along with what @lukeredpath
<https://github.com/lukeredpath> explained, which makes perfect sense.
However, it also makes it sound less of a type and more of a
capability (potentially added to a type or a component). It’s also
consistent with Swift’s native protocol naming like Codable.
—
Reply to this email directly, view it on GitHub
<https://github.com/pointfreeco/swift-composable-
architecture/discussions/1282#discussioncomment-3635178>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/AAAAEZLMD5UG3F55HZ5JB7LV6B2XLANCNFSM57ILRSLQ>.
You are receiving this because you were mentioned.Message ID:
<pointfreeco/swift-composable-architecture/repo-
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Wooow, this is one of the best things to happen to TCA! Thank you @mbrandonw and @stephencelis 👏🏼👏🏼👏🏼 Sometimes I have views that do not send any action, I still create a reducer with a I was wondering if it would make sense to add an extension to provide an empty reducer in this case: public extension ReducerProtocol where Action == Never {
func reduce(
into state: inout State,
action: Action
) -> Effect<Action, Never> {}
}So the reducer becomes struct Row: ReducerProtocol {
struct State {
// ...
}
typealias Action = Never
}What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
@omaralbeik there is an 'EmptyReducer' type included in the library. Does that suit your needs? |
Beta Was this translation helpful? Give feedback.
-
|
It is not exactly an |
Beta Was this translation helpful? Give feedback.
-
|
@omaralbeik a reducer reduces actions into state. If there are no actions I don’t understand why you’d need a reducer. It doesn’t make any sense. If you want to pass a store to a view that only reads state and doesn’t send actions you can pass in an actionless store. |
Beta Was this translation helpful? Give feedback.
-
|
@lukeredpath The main reason is consistency, and later on adding an action with the minimal amount of change, this is usually helpful for rows and smaller views. Here's an example: Books/BooksLogic.swiftstruct Books: ReducerProtocol {
struct State: Equatable {
var books: IdentifiedArrayOf<Book.State> = []
}
enum Action {
case viewAppeared
case book(Book.State.ID, Book.Action) // doesn't have to be included in switch as fas as `Book.Action` is `Never`
}
func reduce(into state: inout State, action: Action) -> Effect<Action, Never> {
switch action {
case .viewAppeared:
// load books
return .none
}
}
}Books/BooksView.swiftstruct BooksView: View {
let store: StoreOf<Books>
var body: some View {
List {
ForEachStore(
store.scope(state: \.books, action: Books.Action.book),
content: BookView.init
)
.onAppear { viewStore.send(.viewAppeared) }
}
}
}Book/BookLogic.swiftstruct Book: ReducerProtocol {
struct State: Equatable, Identifiable {
let id: Int
let title: String
}
typealias Action = Never
}Book/BookView.swiftstruct BookView: View {
let store: StoreOf<Book>
var body: some View {
WithViewStore(store) { viewStore in
Text(viewStore.title)
}
}
}Since the structure is in place (generated using an Xcode template, adding an action to |
Beta Was this translation helpful? Give feedback.
-
|
Hi @omaralbeik, while I can see the use case, it does seem to be quite specific to a particular work flow. Lately we've been wary of adding overloads for fear of dragging down compile times. We've even deprecated (and soon will remove) a bunch of overloads on This may have to be one that we don't add to the library, but it would be possible for you to add to your own projects. |
Beta Was this translation helpful? Give feedback.
-
|
@stephencelis @mbrandonw Great job with ReducerProtocol "beta" (as always), I've tried it in a small example app - and I love it! TL;DR: yar or nay on writing a new app using ReducerProtocol? How mature is it in your mind? I've have begun writing a large and rather complex app using TCA, with structured concurrency migration in place, have progress around 20% of MVP features. I would like to avoid finish the app app in a couple of months only to discover that ReducerProtocol is no longer in beta and is the proposed standard, and then have to rewrite 100% of the Reducers/Features. So my question is, how confident are you that you have "nailed everything" with ReducerProtocol, over 80% confident? :D |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Sajjon, the plan is to release a new version of the app with the |
Beta Was this translation helpful? Give feedback.
-
|
I started migrating to The driver was to redesign some of my internal clients in order to break the core logic into separate libraries. Doing so with the current environment passing method felt overwhelming. Moving everything to Migrating to
Store(
initialState: EditorRootState(),
reducer: Reduce(
EditorRootReducer,
environment: .init()
)
.dependencies {
// Dependencies that need to be initialized manually instead of via `liveValue`
$0.libraryClient = libraryClient
}
)Updating tests:
A few observations:
On that last point, I currently have mixed feelings about default Thinking out loud... on the other hand, I have a feeling that the inability to define a static |
Beta Was this translation helpful? Give feedback.
-
From our experience we have found that most (but not necessarily all) dependencies can be expressed with a single, static As an example, of the 20+ dependencies used in isowords, only a few needed special bootstrapping logic. For those, we simply do not conform the key to Having said that, your other 2 ideas are also good ones to explore. It is definitely possible to put multiple versions of a dependency into the system by having multiple keys/properties. And of course separate clients may also be the way to go sometimes. |
Beta Was this translation helpful? Give feedback.
-
|
Excellent, thanks @mbrandonw. The isowords The client I want to separate is an image asset loader. I configure one instance to resize and cache images on the fly, and this used across the app. Another instance does no resizing or caching and is used for exporting; the resizing happens in a renderer. I'll explore wrapping these as separate types so it's more explicit which functions each domain needs. Thinking about |
Beta Was this translation helpful? Give feedback.
-
That's unfortunately not going to work. Technically the I'm not sure how to accomplish what you want. I think it might be better for us to keep pushing techniques to help us make all kinds of dependencies work with |
Beta Was this translation helpful? Give feedback.
-
|
Chipping in with a small question: does it make sense the whole dependency management logic to be added into a separate library? |
Beta Was this translation helpful? Give feedback.
-
|
It's in the same package but exposed as a second library already if I'm not mistaken (In the proto-branche of course). |
Beta Was this translation helpful? Give feedback.
-
|
Hi @fila95, the dependency system is in its own library within the TCA package. This means you need to depend on TCA to get access to it, but you don't need to build TCA to use it. Someday in the future we may even break it out into its own package because we believe it has uses outside of TCA, such as server-side development and maybe even vanilla SwiftUI. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the clarification, sounds good to me 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
Has task cancellation been gone over with the protocol change? I'm wondering how to implement without use of the .cancellable func on |
Beta Was this translation helpful? Give feedback.
-
|
TL;DR use new SwiftUI CaseStudies have been updated and there's also extensive documentation provided in the library, specifically the parts talking about migration to swift concurrency. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, as @andreyz says, you can use the SwiftUI view modifier The long-living effect case study demonstrates how to do this: |
Beta Was this translation helpful? Give feedback.
-
|
Ah that is right. Haven't played with this yet, will have to try it. Thanks for the help! |
Beta Was this translation helpful? Give feedback.
-
|
One question about changing dependencies. I want to add a Demo-Client which can be toggled on or off. This means, in my Settings-Features I have a state struct MultiplatformApp: ReducerProtocol {
struct State: Equatable {
var demoMode: Bool = false
var feature: Feature.State
}
enum Action: Equatable {
case toggleDemoMode
case feature(Feature.Action)
}
var body: some ReducerProtocol<State, Action> {
Reduce { state, action in
switch action {
case .toggleDemoMode:
state.demoMode.toggle()
return .none
default:
return .none
}
}
Scope(state: \.feature, action: /Action.feature) {
Feature()
}
.dependency(\.apiClient, /* .demo or .live */ )
}
}This example will also only affect the child features, but in my case, the whole app should use the demo-client. |
Beta Was this translation helpful? Give feedback.
-
|
@mbrandonw Ah, yes, you're right. I think I'm filtering it out mentally because touching Ideally, I would like to be able to reuse |
Beta Was this translation helpful? Give feedback.
-
I just updated from I used to inject all the live dependencies like: MainApp()
.dependencies {
$0.products = env.products
$0.analytics = env.analyticsClient.logEvent
}the above code does not compile anymore; changed it to: MainApp()
.dependency(\.products, env.products)
.dependency(\.analytics, env.analyticsClient.logEvent)which works almost the same but also forced me to provide While (in my project) analytics used to have a dummy public extension DependencyValues {
var products: @Sendable () async throws -> [AppProduct] {
get { self[ProductsKey.self] }
set { self[ProductsKey.self] = newValue }
}
private enum ProductsKey: DependencyKey {
static var liveValue: @Sendable () async throws -> [AppProduct] = {
//preconditionFailure("Unimplemented") // <- used to work with dependencies
throw DependencyError.unimplemented // <- I need to provide an implementation now
}
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Hey @pokryfka, the MainApp()
.transformDependency(\.self) {
$0.products = env.products
$0.analytics = env.analyticsClient.logEvent
} |
Beta Was this translation helpful? Give feedback.
-
|
@tgrapperon I missed that, it does work, thank you! |
Beta Was this translation helpful? Give feedback.
-
|
No problem, it was a last minute change. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I'd like to ask how can I make dependency not shared between 2 app sessions? For instance I open the app in split view, currently they will share and use the same live dependencies, hence some state I stored in the live dependencies are shared among the 2 apps, which is not what we intend to have. We want to have app session (iOS app) / window session (macOS app) specific dependencies so that one does not affect the other. How could we achieve this using the new dependency system? |
Beta Was this translation helpful? Give feedback.
-
|
This can be demonstrated using isowords under protocol branch. If I perform an action, it's replayed on the other side of the split view. How do we make them independent of each other? Simulator.Screen.Recording.-.iPad.9th.generation.-.2022-10-09.at.12.23.11.mp4 |
Beta Was this translation helpful? Give feedback.
-
|
Let's say there're 2 users who want to log in isowords using different accounts in the split view and they want to play isowords in the same iPad. How can we separate them? |
Beta Was this translation helpful? Give feedback.
-
|
I think you have indeed two questions here:
Figuring out the first one is key as a starting point. When using the SwiftUI app lifecycle: @main
struct MyApp: App {
var body: some Scene {
WindowGroup {
SceneView(store: Store(
initialState: ...,
reducer: ...
))
}
}
}you need to be aware that How then does one get new Whatever you create or store in the struct SceneView: View {
@StateObject private var store: StoreOf<SceneReducer>
init(store: @autoclosure @escaping () -> StoreOf<SceneReducer>) {
self._store = .init(wrappedValue: store())
}
var body: some View { ... }
}If you did this, then at least you wouldn't see all navigations replicated between the split views. But login state would still be shared (at least via In the onAppear {
if sceneID == nil { sceneID = UUID().uuidString }
viewStore.send(.onAppear(sceneID: sceneID!))
}Now the Footnotes
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for suggestion. This should fix the shared state among scenes, what's left is to inject dynamic dependency per scene. It'd be great if @mbrandonw and @stephencelis can make an episode on this topic / add a case study about this once we have a more official solution, be it _Observe or other technique. |
Beta Was this translation helpful? Give feedback.
-
|
@josephktcheung I wouldn't look to isowords as an example of accomplishing a multi-scene application. We did not build it in that way and simply don't support split screen. This seems like a bigger topic that goes beyond the library and the protocol-beta branch. This is a problem that needs to be solved even in the old, environment-style of dependency management, and you have to solve this problem in plain, vanilla SwiftUI too. I would suggest starting a new discussion on the topic of multi-scene apps so that others can share their experiences and tips. I think this current discussion has gotten way too long and is hard to keep up with. |
Beta Was this translation helpful? Give feedback.
-
This link is broken now as the filename has changed to Updated link: |
Beta Was this translation helpful? Give feedback.
and others
-
Hello everyone!
We have kicked off a brand new series of episodes and we’d like to start a beta period for the changes to the library like we did for the concurrency tools. We believe this release is an even bigger one than the concurrency release, and will make writing and composing features in the Composable Architecture as friendly and intuitive as building interfaces in SwiftUI.
Although we have been working with the APIs for many, many months, we'd like to give the community some time to test things out and let us know of any problems.
All of these changes should be 100% backwards compatible, and so if you experience any compiler errors please let us know. Some aspects of the new tools introduced in this release only work in Swift 5.7, but we’ve still tried to make the experience for 5.6 as nice as possible. This should make it easier to slowly migrate your application without forcing you to be on the newest Xcode or Swift.
ReducerProtocolThere is a new way to create reducers in the library, and that is by conforming types to the
ReducerProtocol. So, where you previously would do something like this:…you will now do something like this:
This style of reducer comes with a number of benefits:
…and a whole lot more.
Further, the
ReducerProtocolgives us a natural place to express the composition of many reducers. If your feature composes many reducers together, such as the root-level reducer that combines reducers for each tab of an application, then previously you would express this using thecombineandpullbackoperators:For brevity we have omitted the transformations for turning the app environment into an activity, profile or settings environment, but suffice it to say that it typically requires quite a few lines.
This composition can now be expressed with the
ReducerProtocolby implementing abodyrequirement, which makes use of result builder syntax to provide a concise API for composing many reducers together in a way that should feel familiar to SwiftUI developers:A couple of things to note:
bodyautomatically combines reducers together by running them in order and merging their effects. No need to use an explicitcombineoperator.pullbackoperator has been reimagined as aScopereducer that transforms the parent domain into the child domain, and then runs a child reducer on that domain inside a result builder.Composing reducers into optional and collection domains has also improved with the builder style. See the documentation for
ifLet,ifCaseLet, andforEachfor more.Dependency management
The second big change in this release is an overhaul of how dependencies are managed when building an application with the library. Currently dependencies are managed rather explicitly by having each feature model an environment of all the dependencies needed to implement its logic and behavior:
Then, every parent feature must also have an environment struct that holds onto all of its dependencies, as well as all the dependencies of any child feature:
It must hold onto the child feature’s dependencies even if the parent feature doesn’t directly need the dependency. And then, when composing reducers via
pullback,forEachor any other compositional operator, we have to transform the parent environment to the child feature environment:This is a lot of boilerplate to maintain, and any changes made to dependences at the child layer will force you to make changes to every layer above it. However, if you do maintain all of this code the pay off is absolutely worth it since you get to instantly control the execution environment a reducer operates in. This is great for testing, and has other applications as well.
The
ReducerProtocolenables us to completely revamp how dependencies are managed in a Composable Architecture application. Dependencies can be added to a reducer using the new@Dependencyproperty wrapper, which is to reducers what SwiftUI’s@Environmentproperty is to views. The library even comes with many common dependencies provided right out of the box that you can use with no additional work:For custom, domain-specific dependencies, such as the
APIClient, you can perform a little bit of upfront work to register the dependency with the library by telling the library where to find the “live” version of the dependency and the “test” version:This allows you to use the
@Dependencyproperty wrapper with your own dependencies right along side the dependencies that ship with the library:By default the library will use the
liveValuedependency when running your code in non-test environments. This provides live versions of the dependencies, such as the real mainDispatchQueue, or the realDate.initinitializer, etc. When your code is run in tests, thetestValuewill be used, which should be a mocked or unimplemented version of the dependency that doesn’t need to interact with the outside world.Migration
We have an article prepared describing some steps you can take to slowly and incrementally migrate an existing Composable Architecture to the new protocol-style. If there are some migration scenarios that are not covered by this article we would love to know so that we can improvement article.
Trying the beta
To give the beta a shot, update your SPM dependencies to point to the protocol-beta branch:
This branch also includes updated demo applications using these APIs, so check them out if you're curious!
We really think these tools will make TCA even more fun and easier to use! If you take things for a spin, please let us know if you have any questions, comments, concerns, or suggestions!
Beta Was this translation helpful? Give feedback.
All reactions