Replies: 25 comments 113 replies
-
|
Switch to the beta branch. Everything is fine with compilation and tests, although I should mention that there are only a few of them at the moment, as the project is new and under active development. If I understand correctly, @.Shared is only applicable within reducers, right? But what if we need to modify the shared state within some dependency? I believe many of us, if not all, deal with the following scenario: We need to log out by clearing/refreshing access tokens if our ApiClient dependency encounters a 401 error for any request. Currently, I'm using the approach mentioned in the last episode, with a get-set-stream where my authReducer is listening to the stream from another dependency named SharedState, where these apiTokens reside in memory. When my app starts, the authReducer reads values from keychain and sets persisted token to SharedState dependency, which is using by apiClient for network requests. When the SharedState dependency's stream sends nil , authReducer will clear the keychain/sharedState and send action to the parent for logout on UI level) |
Beta Was this translation helpful? Give feedback.
-
|
I've got the answer in Slack, so my comment now, is just for statistics. Or may be, someone will make an addition to it, here. |
Beta Was this translation helpful? Give feedback.
-
|
I would have use if I understand this is probably the minority use-case and you may have considered reasons for providing the defaults you do. Just putting it out there; you could save me some copy-paste implementation. |
Beta Was this translation helpful? Give feedback.
-
|
@kamcma Do you want to sketch out what you would like that to look like in practice? Right now the configuration is pretty simple with just |
Beta Was this translation helpful? Give feedback.
-
|
Alright, in sketching this out, I have refined my idea. The conversion concept is cribbed entirely from swift-parsing, with one of the associated types pinned to So I think you'd actually want a conversion to be a parameter at the // in TCA
protocol FileConversion<Output> {
associatedtype Output
func apply(_ input: Data) throws -> Output
func unapply(_ output: Output) throws -> Data
}
struct JSON<Value: Codable>: FileConversion {
let decoder: JSONDecoder
let encoder: JSONEncoder
init(
_ type: Value.Type,
decoder: JSONDecoder = .init(),
encoder: JSONEncoder = .init()
) {
self.decoder = decoder
self.encoder = encoder
}
func apply(_ input: Data) throws -> Output {
try self.decoder.decode(Value.self, from: input)
}
func unapply(_ output: Value) throws -> Data {
try self.encoder.encode(output)
}
}
extension FileConversion {
static func json<Value>(
_ type: Value.Type,
decoder: JSONDecoder = .init(),
encoder: JSONEncoder = .init()
) -> Self where Self == JSON<Value> {
.init(type, decoder: decoder, encoder: encoder)
}
}
class _FileStorageKeyWithConfigurableConversion<Value: Sendable>: PersistenceKey, @unchecked Sendable {
init(url: URL, conversion: any FileConversion<Value>) { }
func load() -> Value? {
unimplemented()
}
func save(_ value: Value) { }
}
extension _FileStorageKeyWithConfigurableConversion: Hashable {
static func == (lhs: _FileStorageKeyWithConfigurableConversion, rhs: _FileStorageKeyWithConfigurableConversion) -> Bool {
unimplemented()
}
func hash(into hasher: inout Hasher) { }
}
extension PersistenceKey {
static func _fileStorage<Value: Codable>(_ url: URL) -> Self where Self == _FileStorageKeyWithConfigurableConversion<Value> {
_FileStorageKeyWithConfigurableConversion(url: url, conversion: .json(Value.self))
}
}
// in consumer
struct CustomFileConversion<Value>: FileConversion {
init(_ type: Value.Type) { }
func apply(_ input: Data) throws -> Value {
unimplemented()
}
func unapply(_ output: Value) throws -> Data {
unimplemented()
}
}
extension PersistenceKey {
static func _fileStorageWithCustomConversion<Value>(_ url: URL) -> Self where Self == _FileStorageKeyWithConfigurableConversion<Value> {
_FileStorageKeyWithConfigurableConversion(url: url, conversion: CustomFileConversion(Value.self))
}
}
extension URL {
static let jsonURL = URL(string: "")!
static let customConversionURL = URL(string: "")!
}
@Reducer
struct BarFeature {
struct State {
@Shared(._fileStorage(.jsonURL)) var baz: Int = 0
@Shared(._fileStorageWithCustomConversion(.customConversionURL)) var qux: Int = 0
}
}Actually, further idea: if you're not wild about the API surface area introduced by the |
Beta Was this translation helpful? Give feedback.
-
|
I have hit an unexpected TestStore behaviour when testing feature composition which uses both shared state and delegation actions pattern. Here is an example project: https://github.com/Malauch/tca-shared-state-delegate-action-test-issue. It's very artificial stripped down example but illustrates the issue. The problem is that if a child feature sends delegate action which when is received by parent feature it causes mutation of shared state (in parent feature reducer), then test store shows state mutation on sending delegate action instead of receiving it. When commenting out shared state property wrapper attribute and use just normal property it works as expected. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Malauch, yeah this is currently an annoyance when working with shared state, and so far we have mainly seen it crop up when using delegate actions (or more generally, synchronous effects). The fix is to make a pretty substantial change to how I will say though that there is a chance you do not even need to use the delegate action to mutate shared state anymore. There is a chance your child feature could make the mutation directly and skip the delegate action. That is what we were able to do in the SyncUps app. So, while not a solution in all cases, it may help out a few situations. |
Beta Was this translation helpful? Give feedback.
-
|
That's understandable. For these rare situation when it is more sensible to still use delegate action, then just moving state assertion from |
Beta Was this translation helpful? Give feedback.
-
|
I tried to convert one of my shared state dependency client into this new shared state machinery. That dependency client was also saving data on disk for purpose of persistence and sharing data with widgets. Therefore I used I have some other project when helper and main app runs as two separate processes and exchange data via saving and monitoring changes to filesystem. It's implemented using similar mechanism as fileStorage persistence strategy. I didn't try it yet but it should be possible to easily replace this communication dependency client with shared state machinery. However that 5 s. delay would be too long. Is this 5s really minimum reasonable value? Do you have any plan to make it configurable? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Malauch, thanks for the demo project! That helps a lot since I'm not super familiar with widgets. We will discuss and get back to you. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Malauch, we did some experimentation with having an explicit We're thinking that perhaps it would be best to just drop the throttle duration to 1 second and not provide any customization. That seems to serve widgets well, and a disk write per second isn't bad at all. Would that resolve the issues you are seeing with widgets? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mbrandonw, It’s better. However without additional debounce on Obviously, adding additional 1.1s debounce on let updates = state.$count.publisher.debounce(for: 1.1, scheduler: DispatchQueue.main)
return .run { send in
for await _ in updates.values {
widgetCenter.reloadAllTimelines()
}
}That much delay on refresh seems to be reasonable. It’s not perfect but feasible. However, in that case I would still prefer to use separate client to write to disk immediately and refresh widget after the save - just to avoid estimating necessary debounce delay. It’s understandable that finding perfect balance between simplicity and functionality for built-in persistence strategy is very tricky and not every use case would covered. It’s still an amazing tool. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Malauch, another option is for you to listen to changes to the file using We use |
Beta Was this translation helpful? Give feedback.
-
|
@Malauch One other change we just added was making the throttling eager and not debouncing the first save. So if there hasn't been a save in the last 1 second, the save will be instantaneous. Rx diagram would look like this: |
Beta Was this translation helpful? Give feedback.
-
|
Excellent! "persistence" is indeed a crucial component missing from the TCA framework 🙌🏻 I have tried to migrate one of my projects to this new tool and although it was not as straight as I expected, it (kind of) worked! Nice! However, it seems more like a What are your thoughts on this? Oh and:
|
Beta Was this translation helpful? Give feedback.
-
|
If we disregard persistence, being able to So along the same lines as |
Beta Was this translation helpful? Give feedback.
-
|
Hi @jshier, the use case you are describing will be discussed in the next 2 episodes of the series, and there's a new case study that demonstrates this too. I'm curious if this is similar to your situation and if it helps. To me it seems correct to model this as a piece of state.nextStep = NextStep.State(subState: state.$formData.subState)In this situation, the next screen only has access to |
Beta Was this translation helpful? Give feedback.
-
|
Hi @MojtabaHs & @jshier, when y'all have a chance it would be nice to get some feedback on what is posted above. |
Beta Was this translation helpful? Give feedback.
-
|
@mbrandonw Your suggestion is essentially what I had to move to, and what I was trying to avoid. My point was that that simplest version of the "build a value through a flow" is simply to share that value from the root reducer and allow each child to bind to the bits it needs directly, rather than having to indirect through sub properties in each child's state. Of course, this isn't possible sometimes, as some screens may need other values too, in which case a sub property from the parent shared state makes a lot of sense. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mbrandonw, sorry for the late response. I'm impressed by this new tool and trying it in many different ways to find optimal solutions. One important point is that some generic features do not (should not) know the logic of the shared state. Imagine 3 Then something like this in its parent which is a non-generic parent: Please let me know what you think about this method. Also, defining the initializer was a pain since Xcode could not automatically infer and generate it for me and it looks so ugly :D About the delay issue, I've found that it was intended and there is another thread in which you guys are discussing the alternatives for situations like handling widgets. About the unexpected reinitializing, the issue was with the refactoring process where the parent was missing the change callback from the child (the classic method). I've used another approach (as I tried to describe above) and this issue was solved with no effort 🙌🏻 |
Beta Was this translation helpful? Give feedback.
-
Yep, no problems here. Updating and building worked fine
Tests passed, no behavioural difference noticed. To note, my test suite is small.
Converted a feature today and it went smoothly. This feature was a multistep form using a coordinator that manages a navigation stack. Previously I was doing at least 2 nasty things to pass data around: A few things I had trouble with while converting.
|
Beta Was this translation helpful? Give feedback.
-
I'm able to pass along the unwrapped data on initialization, but as I understand it, if the data changes I would need to pass it to the child again, and I think I would need to use the publisher to do that. In the example below,
An example. There are 2 problems here:
|
Beta Was this translation helpful? Give feedback.
-
Hi @IanHoar, no, that is not correct. It is possible to derive a In your example you would change it like so: // Module boundary
@Reducer
struct Fizz {
struct State {
- var title: String
+ @Shared var title: String
}
}
@Reducer
struct Bar {
struct State {
let fizz: Fizz.State
@Shared var data: FooBarData
init(data: Shared<FooBarData>) {
self._data = data
- self.fizz = .init(title: data.wrappedValue.title)
+ self.fizz = .init(title: data.title)
}
}
enum Action {
case fizz(Fizz.Action)
}
}It really is instructive to think of
The problems you are experiencing are just problems with property wrappers in general, and you just have to be aware of the work arounds. To fix you can do the following: // Module boundary
@Reducer
struct Fizz {
struct State {
- var title: String
+ @Shared var title: String
}
}
@Reducer
struct Bar {
struct State {
let fizz: Fizz.State
@Shared(.inMemory("storage")) var data: FooBarData = .init(title: "title")
init() {
+ @Shared(.inMemory("storage")) var data: FooBarData = .init(title: "title")
- self.fizz = .init(title: data.title)
+ self.fizz = .init(title: $data.title)
}
}
enum Action {
case fizz(Fizz.Action)
}
}It may seem strange, but property wrappers do complicate initialization quite a bit, and you run into similar problems in vanilla SwiftUI (e.g. needing to do |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, thanks for the feedback. I'm trying to touch things as lightly as possible with these new changes which is why I didn't think to mark the |
Beta Was this translation helpful? Give feedback.
-
I understand why |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Thomvis, have you seen that |
Beta Was this translation helpful? Give feedback.
-
|
Hello. 👋 I started updating one of my projects and ran into a strange issue. I also have a question. First the question. What's the recommended way to use Now, the strange issue. Create a brand new app, add TCA with the import ComposableArchitecture
import Foundation
@Reducer
public struct Foo {
public struct State: Equatable {
@Shared(.appStorage("foo")) public internal(set) var foo: Int? = nil
public init() {}
}
}
@Reducer
public struct AppDelegate {
public struct State: Equatable {
@Shared(.appStorage("dateOfFirstLaunch")) public internal(set) var dateOfFirstLaunch: Date? = nil
public init() {}
}
}When you try to build it, you should get the errors Type 'AppDelegate.State' does not conform to protocol 'Equatable'and No exact matches in call to static method 'appStorage'but only for the Any ideas? Many thanks in advance. |
Beta Was this translation helpful? Give feedback.
-
|
I'd go even so far as to suggest |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that would make |
Beta Was this translation helpful? Give feedback.
-
@wltrup That definitely is not the case at all. The child feature will have this in their @Shared(.appStorage("count")) private var _count = 0
var count: Int { _count }Nothing in those lines of code references types in the parent domain, therefore it can be compiled without the parent.
It would be unfortunate for the most common use case to become the more verbose API. From our perspective most people will be able to get along just fine with We still think some concrete use cases for "read only" |
Beta Was this translation helpful? Give feedback.
-
|
Oh... I misunderstood your original post. I thought that @Shared(.appStorage("count")) private var _count = 0
var count: Int { _count }was in the parent type, not the child, so that the child would have to invoke |
Beta Was this translation helpful? Give feedback.
-
|
People have brought up some interesting use cases for a read-only |
Beta Was this translation helpful? Give feedback.
-
|
Hello, on my SwiftUI macOS app, I tried |
Beta Was this translation helpful? Give feedback.
-
|
In general, I am quite supportive of the "make it work like vanilla SwiftUI, but for TCA" approach. Maybe Apple had a good reason for making |
Beta Was this translation helpful? Give feedback.
-
|
I guess another argument for making Still: I personally will try to always set my own defaults with |
Beta Was this translation helpful? Give feedback.
-
|
@kamcma Thanks for the links. We are a bit torn between mimicking |
Beta Was this translation helpful? Give feedback.
-
|
@kamcma This PR #2904 should resolve the issue you brought up. It does break from how |
Beta Was this translation helpful? Give feedback.
-
|
It had not occurred to me that you would not be able to register defaults for users of the keypath-based API. (Though in hindsight I can clearly see why: the key is not visible to TCA.) That's a bummer for me, who wishes to use the keypath-based API. Hmm. Is the difference in behavior concerning? If I use the keypath API and continue to register my own defaults, and users of the string API stumble over the subtly different behavior from |
Beta Was this translation helpful? Give feedback.
-
|
Can somebody provide an example of how to observe changes of a shared state property in a reducer? The reducer should react to such changes for example by sending an action. Currently I do create a long running effect using the shared values Publisher: But that does not work completely as expected. Although I use Another problem is that I need to trigger an action whenever one of two shared values changes. Currently I need to create two effects (like the one above) and merge them, where both effects trigger the same action: This is a lot of boilerplate code... |
Beta Was this translation helpful? Give feedback.
-
I don't understand how that is possible. If you really are seeing that behavior then that would point to a problem with
It's not necessary to use async tools here. The Combine operators work just fine, and they make things quite a bit simpler: return .publisher { [shared1 = state.$shared1, shared2 = state.$shared2] in
shared1.map(Action.someAction1)
.merge(with: shared2.map(Action.someAction2)
} |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Brandon! Using Combine operators indeed is much simpler and works as expected. |
Beta Was this translation helpful? Give feedback.
-
|
Also, since TCA (and SwiftUI) is moving away from Combine, I would think that in the long run using a Publisher should not be the default and recommended way to observe changes to a shared property in a reducer (when you can not use |
Beta Was this translation helpful? Give feedback.
-
|
@mbrandonw do you think it's worth adding an extension on Something along the lines of: |
Beta Was this translation helpful? Give feedback.
-
@tkunst891 It's not so much that TCA (or SwiftUI for that matter) is moving away from Combine, it's that we are trying to become less entangled with it at the core of the library. Combine is still top-notch when it comes to guaranteeing how data is delivered to subscribers and for combining and transforming multiple streams of data. You saw yourself what the equivalent async/await code looked like using task groups. Clearly there is a lot of room for improvement. Also, Combine is going to be around for a long time, and so there is no rush to remove every mention of it from the library. We certainly will provide a non-Combine way of listening for changes to
@rowjo We don't feel that such an extension needs to be provided in the library, but it can definitely be defined by others outside the library. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the work, guys -- I'm excited about this new addition to the framework. How do you recommend setting up a migration strategy when using file storage persistence? I could write to a separate file with version info and use that to direct the loading of the data, but there doesn't appear to be a way to intervene in the load process as the framework stands. I suppose I could write my own |
Beta Was this translation helpful? Give feedback.
-
|
Hi @seanmrich, I'm not sure we want to bake the notion of migration directly into |
Beta Was this translation helpful? Give feedback.
-
|
That's a nice solution. Greatly appreciated! |
Beta Was this translation helpful? Give feedback.
-
|
Is specifying a custom UserDefaults suite supported with appStorage? |
Beta Was this translation helpful? Give feedback.
-
|
let store: StoreOf<RootFeature> = Store(initialState: RootFeature.State()) {
RootFeature()
} withDependencies: {
$0.defaultAppStorage = UserDefaults(suiteName: "mySuite")!
} |
Beta Was this translation helpful? Give feedback.
-
|
Thanks 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that's the best way to do it. We did not expose an option on |
Beta Was this translation helpful? Give feedback.
-
|
Has there been any discussion on how utilizing shared state would work when it comes to destination enums, where only certain cases would utilize shared state functionality? For example, in my @Reducer
public struct Home {
@Reducer(state: .equatable, action: .equatable)
public enum Destination {
case mediaLibrary(Shared<MediaLibrary>)
case settings(Settings)
}
}However, this certainly doesn't work because the macro expects a reducer and not a reducer wrapped in case .view(.mediaLibraryButtonTapped):
return .run { @MainActor send in
let state: Shared<MediaLibrary.State> = .init(
wrappedValue: .init(),
.inMemory("mediaLibrary")
)
send(.internal(.destinationResponse(.mediaLibrary(state.wrappedValue))))
}
)But that also doesn't work because that instance isn't saved anywhere. One may say to just slap on Are there any alternatives other than just having a reference to |
Beta Was this translation helpful? Give feedback.
-
|
Hi @acosmicflamingo, we think that typically it's more appropriate to share little bits of data within a reducer feature rather than the entire feature's state. Can you try that? |
Beta Was this translation helpful? Give feedback.
-
|
Sure! I can see how that goes; thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Hi! So far using the branch was flawless and didn't break anything in my application. One thing I'm struggling with though are non-exhaustive tests. I get the I haven't found a way to use |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Sorry, this is a long thread, hard to keep track of everything. |
Beta Was this translation helpful? Give feedback.
-
|
Builds backwards with no issues. 
(i.e. Also, would be interesting to understand how can I monitor changes to the shared state in a child state, so I can react to it? Could be a good addition to the guide. |
Beta Was this translation helpful? Give feedback.
-
|
@freak4pc Shared state should diff just fine. Can you share a repro? |
Beta Was this translation helpful? Give feedback.
-
|
I think the specific case is shared state modified via a Binding (BindableAction) |
Beta Was this translation helpful? Give feedback.
-
|
I believe this is working just fine: 
From your screenshot it seems that You will need to apply var body: some ReducerOf<Self> {
CombineReducers {
BindingReducer()
Reduce { … }
}
._printChanges()
}Or apply SomeReducer()
._printChanges() |
Beta Was this translation helpful? Give feedback.
-
|
I'm having some difficulty with overriding |
Beta Was this translation helpful? Give feedback.
-
|
If I derive the |
Beta Was this translation helpful? Give feedback.
-
|
Hi @hiltonc, can you share the code that constructed the Here is an example of how we do this in SyncUps: ForEach(store.$syncUps.elements) { $syncUp in
NavigationLink(state: AppFeature.Path.State.detail(SyncUpDetail.State(syncUp: $syncUp))) {
CardView(syncUp: syncUp)
}In this situation the Had we done it like this instead: ForEach(store.syncUps) { syncUp in
NavigationLink(state: AppFeature.Path.State.detail(SyncUpDetail.State(syncUp: Shared(syncUp)))) {
CardView(syncUp: syncUp)
}…then this would have been problematic. The So, if you were doing something like that then it would be expected that the shared stated went back to using the default app storage instead of the overridden one. |
Beta Was this translation helpful? Give feedback.
-
|
Here's what I originally had in my app: NavigationLink(state: SettingsReducer.Path.State.playback(.init())) {
Label("Playback", systemImage: "speaker.wave.3")
}And this is what I changed it to so that it works: @ObservableState
struct State: Equatable {
var playback = SettingsReducer.Path.State.playback(.init())
...
}
...
NavigationLink(state: store.playback) {
Label("Playback", systemImage: "speaker.wave.3")
}I was also able to reproduce this with the NavigationLink(
"Go to screen C",
state: NavigationDemo.Path.State.screenC(ScreenC.State())
) |
Beta Was this translation helpful? Give feedback.
-
|
Ah I see, so you aren't using a computed property, but instead a completely separate stored property. The reason that is working is because it then captures the In reality, We do have some planned changes to TCA in the (hopefully) not too distance future that may make it possible for |
Beta Was this translation helpful? Give feedback.
-
|
The only snag I've come across so far is the naming of the PersistenceKey function... With my Firebase RemoteConfig implementation I have an So in the closure I run the However... the ideal way of doing this is like... But... The compiler doesn't like this as it thinks I'm trying to use the I can change this to something like... But it would be nice to not have to do that. Would it be possible to rename the 😄 Thanks |
Beta Was this translation helpful? Give feedback.
-
|
This fails to compile... struct Bar {
func doThing(completion: @escaping () -> Void) {
completion()
}
}
struct Foo {
var bar: Bar = .init()
func doThing(didSet: @escaping (Int) -> Void) {
bar.doThing {
didSet(42)
}
}
}
But this works... struct Bar {
func doThing(completion: @escaping () -> Void) {
completion()
}
}
struct Foo {
var bar: Bar = .init()
func doThing(didSet: @escaping (Int) -> Void) {
bar.doThing {
let value = 42
didSet(value)
}
}
}
|
Beta Was this translation helpful? Give feedback.
-
|
TBH... it seems like it shouldn't be confusing this at all. So it's def a Swift/Compiler issue rather than anything in this repo. But it would help to change the name to avoid causing the issue. |
Beta Was this translation helpful? Give feedback.
-
|
Also, this compiles... struct Bar {
func doThing(completion: @escaping (Int) -> Void) {
completion(42)
}
}
struct Foo {
var bar: Bar = .init()
func doThing(didSet: @escaping (Int) -> Void) {
bar.doThing { value in
didSet(value)
}
}
}
It's the |
Beta Was this translation helpful? Give feedback.
-
|
Hi @oliverfoggin, this does seem to be a Swift compiler bug that should be reported to Apple. At the very least you can escape `didSet`(42)Further, you can always give public func subscribe(
initialValue: Value?,
didSet didSetValue: @escaping (Value?) -> Void
) -> Shared<Value>.SubscriptionSo given that I think we are less inclined to change the name for now. |
Beta Was this translation helpful? Give feedback.
-
|
Fair enough. And yeah it's definitely a compiler bug. Thanks for taking a look at it. 👍🏻 |
Beta Was this translation helpful? Give feedback.
-
|
I was wondering if I'm the only one who thinks it could be useful to have As a side note: could be also useful to explore the possibility to sync those UserDefaults values into iCloud, maybe with NSUbiquitousKeyValueStore. What do you think? Thanks! |
Beta Was this translation helpful? Give feedback.
-
I don't understand how. This seems to work just fine: struct User {
var name: String
}
extension UserDefaults {
var user: User? {
get { string(forKey: "userName").map { User(name: $0) } }
set { set(newValue?.name, forKey: "userName") }
}
}
print(UserDefaults.standard.user)
UserDefaults.standard.user = User(name: "Blob Jr.")
print(UserDefaults.standard.user)That said, it's probably not be a good idea to perform JSON decoding at every read access of the property in an app performing state diffs the way SwiftUI and Observation do: you may be surprised how often the app is busy decoding JSON if you do. (A better way, if possible, would be to perform the decoding lazily and invalidate the cached result when the backing |
Beta Was this translation helpful? Give feedback.
-
|
If extension PersistenceReaderKey {
public static func appStorage<Value: Codable>(_ key: String) -> Self
where Self == CodableAppStorageKey<Value, AppStorageKey<Data?>> {
CodableAppStorageKey(key)
}
public static func appStorage<Value: Codable>(
_ keyPath: ReferenceWritableKeyPath<UserDefaults, Data?>
) -> Self where Self == CodableAppStorageKey<Value, AppStorageKeyPathKey<Data?>> {
CodableAppStorageKey(keyPath)
}
}
public struct CodableAppStorageKey<Value: Codable, UnderlyingKey: PersistenceKey>: PersistenceKey
where UnderlyingKey.Value == Data? {
private let appStorageKey: UnderlyingKey
public init(_ key: String)
where UnderlyingKey == AppStorageKey<Data?> {
self.appStorageKey = AppStorageKey(key)
}
public init(_ keyPath: ReferenceWritableKeyPath<UserDefaults, UnderlyingKey.Value>)
where UnderlyingKey == AppStorageKeyPathKey<Data?> {
self.appStorageKey = AppStorageKeyPathKey(keyPath)
}
public func load(initialValue: Value?) -> Value? {
let initialValue = initialValue.flatMap { try? JSONEncoder().encode($0) }
let value = self.appStorageKey.load(initialValue: initialValue)
return value?.flatMap { try? JSONDecoder().decode(Value.self, from: $0) }
}
public func save(_ value: Value) {
let value = try? JSONEncoder().encode(value)
self.appStorageKey.save(value)
}
public func subscribe(
initialValue: Value?,
didSet: @Sendable @escaping (_ newValue: Value?) -> Void
) -> Shared<Value>.Subscription {
let initialValue = initialValue.flatMap { try? JSONEncoder().encode($0) }
let subscription = self.appStorageKey.subscribe(initialValue: initialValue) { newValue in
let newValue = newValue?.flatMap { try? JSONDecoder().decode(Value.self, from: $0) }
didSet(newValue)
}
return Shared.Subscription(onCancel: subscription.cancel)
}
}and use it like: @Shared(.appStorage("value")) var value: MyCodable? |
Beta Was this translation helpful? Give feedback.
-
|
@pyrtsa The crash happens when you try to observe 
|
Beta Was this translation helpful? Give feedback.
-
@hiltonc That does seem like an oversight. Want to PR against the shared-state-beta branch to make it public? |
Beta Was this translation helpful? Give feedback.
-
|
Will do, thank you. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any way to scope/map a For example, I'm trying to do something like this... @Reducer
struct Child {
@ObservableState
struct State {
@Shared var customer: Customer
// other properties
}
}
@Reducer
struct Parent {
@ObservableState
struct State {
@Shared var customer: Customer?
var childState: Child.State?
}
var body: some ReducerOf<Self> {
BindingReducer()
Reduce { state, action in
switch action {
case .binding(\.customer):
// if customer is set to non-nil value for the first time, initialize childState
// if customer is set to nil, set childState to nil
}
}
}
In the above example, the child state is only valid if a customer is selected. The user needs to take action to select a customer which should then create the childState and their customer properties should stay in sync as long as a non-nil customer is selected on the parent. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mludowise-stripe, we do have a tool for this, but it's tuned for dynamic member lookup right now. It allows you to do something like: if let field = $shared.optionalField {
field // Shared<Field>
}But in your situation you want to unwrap if let customer = $optionalCustomer[dynamicMember: \.self] {
customer // Shared<Customer>
}And we can think more about other ways to surface this tool for non-dynamic member lookup situations. |
Beta Was this translation helpful? Give feedback.
-
|
We just added some convenience initializers to if let customer = Shared($optionalCustomer) {
customer // Shared<Customer>
} |
Beta Was this translation helpful? Give feedback.
-
|
I've been trying the beta using an icloud drive to save the data. It kind of works but isn't great when 2 copies are running at the same time. Most changes get seen on the other copy but I've had some weird things like only half the new text of an item is seen. Are there any plans to add functionality to deal with this kind of thing or is it something I could take care of with a custom persistence? |
Beta Was this translation helpful? Give feedback.
-
|
For a macOS app willTerminateNotification is definitely needed to not lose data when the application quits. |
Beta Was this translation helpful? Give feedback.
-
|
I'm creating some more custom When creating the Defined as... But... the Because I think the The So, this would only ever It looks like there isn't ever a trigger that occurs when a Gonna try something else. But right now it's not running the |
Beta Was this translation helpful? Give feedback.
-
|
This is to be expected for now. Shared state with a persistence strategy does currently live forever and so there is no Now, there is a possibility that in the future we will be able to tear down subscriptions (and invoke But I'm curious, what bug are you seeing that is caused by this? It shouldn't be a problem for these subscriptions to live for the duration of the app. |
Beta Was this translation helpful? Give feedback.
-
|
I'm using the It has a nifty thing where you can show a This uses the However, that relies on having the subscription cancelled when the view/features go off screen. So I can see the feature flags slowly building up and appearing as I navigate through the app. But when I pop out, they all remain and none are removed even though they are not actually affecting anything. It's not a huge problem but one that will stop me using the From the look of the apis that are available though it does feel incorrect. Especially since we're given an Thanks |
Beta Was this translation helpful? Give feedback.
-
The subscription also gives the persistence strategy the ability to keep objects alive. So no matter what we need a subscription-type object with a trailing closure to capture things. So really all we can do is rename the closure, but the closure is correctly named technically. And in the future we may be able to actually deallocate references when there is no state in the app holding onto it. |
Beta Was this translation helpful? Give feedback.
-
|
It would seem more correct to me to either not have the closure there at all or to create it something like In your I'm fine with not being able to cancel the subscriptions. But I think it would be more correct to write the APIs in a way that makes that more obvious. |
Beta Was this translation helpful? Give feedback.
-
|
Hiey, I'm working with this shared-beta branch for a while and I'm thrilled how great it all works. What I noticed is that the publisher is only emitting changes that happen after the subscription. It would be great if this could behave like a CurrentValueSubject (or provide a way to define the behavior) and provide the current value upon subscription. Is there something I'm missing here? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @DoddaSrinivasan, can you explain a bit why you need to it to behave like a |
Beta Was this translation helpful? Give feedback.
-
|
I seem to have run into an issue with inMemory Shared publisher observation. I am observing the publisher in an onTask action such as: However if the the feature this is in goes away (More on this in a minute) and I write to the shared property from somewhere else, the action is still being fired and I get the purple warning of doom. So my set up at root is such that I have a SignInView and a HomeView and root swaps these features based on authentication state that can change from a couple different places. So when authenticated we show HomeView when not we show SignInView. This is handled similar to this: The problem arises when HomeView pushes a childview that has that task observation then authentication switches while it is presented, if I then mutate that inMemory property from root, I get the error. It appears that the publisher is holding onto the child. Is this a memory leak? I have a full demo I can paste here if anyone wants. I have also raised this on Slack where I pasted the full demo of this happening. This seems to be a very common pattern in setting up sign in and home view based on auth state, so am I just doing it wrong? |
Beta Was this translation helpful? Give feedback.
-
|
So I am able to reproduce this even using the techniques you mentioned. It seems this is happening when you mutate a @shared property from the result of an AsyncStream observation. So I am observing an Async Stream of activities and when I get a result in the success Action I set the @shared property of actions to the result. This seems to be causing my issue. Perhaps I am not setting something up correctly though. But I feel like this would be a very common pattern with Shared State. Getting a response from an api and sharing it with the whole app. This example is getting a bit verbose. If you want I can put this in a project and post the GH link but here it is in one file so anyone can just copy and paste it and run it. I am using a timer to simulate something happening to trigger a root reset to home. You just need to push the child and wait for the timer to hit 10 then you will see the warning You will need to add 1 line to your main: |
Beta Was this translation helpful? Give feedback.
-
|
Hi @wshamp, thanks for the reproducible project. Unfortunately it is a lot of code, so I'm going to have to find some time to really go through it. If you are able to pare it down a bit that would help a lot. If it really is related to mutating shared state in an async stream, then maybe it's possible to get a demo that only has that. And ideally even something that can be represented as a unit test. |
Beta Was this translation helpful? Give feedback.
-
|
So it really seems to be about a couple things that make the code long. like Navigation stack and observing shared state and observing an Async Stream. I don't think I can parse this down any further as this is the crux of the situation. If you do have time to take a look that would be great but I know you are busy. I do think this will be a pretty common pattern though for shared state. Here are the bullet points.
I cannot reproduce this if I do not push a child onto a nav stack. Meaning if Home just observes the activities everything works fine. But as soon as I push a child that observes them I get the issue The issue does not happen if I don't observe an Async Steam. Meaning if I use a publisher it works fine |
Beta Was this translation helpful? Give feedback.
-
|
So I was able to parse this down a bit further. Though it still is dependent on a navigation stack so there is the boiler plate code of a parent / child features and a root feature so I put it into a project. It is just under 200 lines of code. And this demonstrates the issue. In this new version you only have to run the project and after 5 seconds the child will be dismissed and the purple warning will happen. I can also create a bug for this since the tools have now been released if you wish. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @wshamp, I don't think an issue is appropriate right now because it's not clear there is a bug in the library. However, if you wanted to create a new discussion then I think that would be best, because this discussion has grown far too long. I will be closing it soon. |
Beta Was this translation helpful? Give feedback.
-
|
I started using the beta this last week to see how it goes with sharing settings in my app. I was looking at how things work with file storage persistence. It calls this init in ValueReference.swift: extension Shared {
public init(
wrappedValue value: Value,
_ persistenceKey: some PersistenceKey<Value>,
fileID: StaticString = #fileID,
line: UInt = #line
) { ... }
}which got me looking at all of them and I am wondering if all the wrappedValue portions should be changed to |
Beta Was this translation helpful? Give feedback.
-
|
Hi @bscothern, thanks for the suggestion. Could you start a new discussion for this topic? Now that the tools have been officially released we want to close out this beta discussion. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to close this discussion now that the tools have been officially released. |
Beta Was this translation helpful? Give feedback.
and others
-
Hello all, today we are beginning a very exciting beta for the Composable Architecture. It brings all new tools to the library for sharing state in your application and persisting data.
To try out the beta you can point your dependency on the Composable Architecture to the
shared-state-betabranch. We have prepared a migration guide that can be followed to try updating some of your features, and there is a dedicated article with more information on the tools.We do not recommend depending on this beta branch for long term, active development of your application. It is likely to have many breaking changes in the coming weeks or months until its final release.
But we would appreciate if everyone could point their projects to the
shared-state-betabranch and let us know a few things:@Sharedin a few features, and does it behave as you expect when running your application and tests?@Sharedcannot do that you would like it to do?Beta Was this translation helpful? Give feedback.
All reactions