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(...)
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 :)
I'd love to get a second pair of eyes to talk about my ReSwift approaches in 2 apps eventually. If a ReSwift pro is available for hire for an hour here and there, please email :) https://christiantietze.de/contact/
So I have a thunk that conditionally dispatches another thunk.
But Thunks don't play nicely with the
.dispatches() assertion
I could breakout out the core functionality into a separate function, but that creates a route to start calling side-effects without going through the thunks.
Put another way: I am testing thunk A which can dispatch thunk B. Asserting that A dispatches B with
ExpectThunk().dispatches() doesn't work and it gets in the way of asserting other dispatches() that occur after B is dispatched.
Perhaps I'm thinking about it all wrong and I shouldn't be dispatching thunks from thunks?
Carryon. :-)