dispatching the fetchProjects thunk leads to a recursive dispatch and crashes the app.
haha
that feels like something that should be enforced by the compiler though, i wonder if store.subscriber's select function should require the struct to conform to Equatable
Ran into a weird bug in my app that boiled down to a store subscriber caching a value, which didn't mix well with the order of store subscribers being informed of state updates. The general-purpose answer seems to be: put the cache info into the state, not into some service in the app. It's a super weird situation, though, because the cache was introduced to make NSTextView editing a bit less error prone. After all these years, I still wonder if I'm holding it wrong and if doing even more in the ReSwift stack would solve the problems.
i'm amidst porting a side project to use ReSwift and am unsure how to resolve certain scenarios. what i'm grappling with right now is chaining asynchronous actions together
i have a
LoadInitialStateAction that resolves with an array of [Item]; i have a middleware guarding for that action, and if it is .loaded(items), i dispatch(someThunk); someThunk being the next asynchronous action that relies on items. what i'm running into is the ReSwift:ConcurrentMutationStateError- Action has been dispatched while a previous action is being processed occurring when my someThunk returns quickly
i tried wrapping my main
store and using a serial queue internally to dispatch, but that didnt work :worried: my fix was basically DispatchQueue.main.asyncAfter(.now() + 1) https://twitter.com/ios_memes/status/1159781903559528450/photo/1
this seems like a really common need, so i feel like i'm missing something - any advice welcome! (and i'll try to pay it forward with what i learn)
@hrln the error should only appear when you dispatch from multiple queues. Assuming you dispatch on the main queue by default, DispatchQueue.main.async without a delay should do the trick just as well since the main queue finishes one run loop run, which in your case would be the state mutation, before the next thing is processed.
Using 2 dispatch queues in your app is not a problem as long as you remember to return to main. It's a good practice to build components in a way that the caller doesn't notice if the queue/thread/... that work is done on is changed. So if you use a BG dispatch queue for networking, dispatch the result back on the main queue, and don't force callers to take care of that.
in folks ReSwift setups, are there any techniques you tend to use involving queue management ?
e.g. recently we stumbled upon EKEventStore producing results on an Apple-internal, non-main queue to everyone's surprise
@DivineDominion Hello, so i have my data save in my postgresql table, and i did all the nodejs api stuff, my request is good i test it on postman but when i try to show it on my app it didnt work, i try to print the data it show me "nil" and when i try to print the state of data in my reducer it show me an empty []
yes of course
What's not working there? Is the await-block never called? Is the thunk's block not executed when you dispatch?
inside the all(...)
i try to add it to and change the currency too
but it's still didn't work
and when i add it, my "AllBadgeActionSuccess" is never called
Hi there! I've just started using the SwiftUI branch of ReSwift. I was using my own Redux implementation before but ran into several issues with the observers. Does anyone know if the SwiftUI branch has a way to filter the observed state? I know SwiftUI should take care of deciding which parts of the view to redraw but it doesn't seem to work very well. Using a single state always causes my whole view to be redrawn and other undesired behaviour. @mjarvis Do you have any information to that? :)
@marcoboerner Sounds like you've found what you're looking for! I'm sorry I've been unable to formalize it more but taking an approach near the bottom of ReSwift/ReSwift#455 should do what you need :)