@nanocba Can you share an example
viewModel(state:)
factory method implementation? Am curious what you do there
That's on the presenter's side. Basically, a presenter always take some state and converts that into the view model that view needs. Note that the concept of view model is not that from MVVM. These are pure view models. They don't have any functions, just properties that map 1:1 to view properties. The type of things you see inside this viewModel(state:)
method is always transformations from state to view model, such as if the state exposes a date and you need to display it in the view, this is the place where you format the Date into a String.
func foo(params) -> (Thunk, Promise)
, then use let (thunk, promise) = thunk(params); dispatch(thunk); promise.then { ... }
-- This can be wrapped into helper functions and/or extensions on the base types such that you can do so without boilerplate, giving you what you're asking for.
extension Store { func dispatch(_ thunkAndPromise: (Thunk, Promise)) -> Promise { ... }
)
How would you model state in a table view driven by an NSFetchResultsController?
I can let the NSFetchResultsControllerDelegateupdate the table view by inserting, updating, moving and deleting view and when the delegate methodcontrollerDidChangeContent(_:)is called, update the state using the fetch results controller's propertyfetchedObjects`.
If I use the FRC fetchedObjects and convert my entities to structs I will lose the benefits of faults (large objects can be represented by a fault instead, until they really are needed.) unless I just map fetchedObjects to their objectIDs and only keep the objectIDs in the state and create a state for a cell lazily when it is needed.
Hey everyone, I hope you are doing good. I would like to share with you a new framework that I have been working on in the last couple of months. It’s called Caesura and it’s powered by ReSwift.
Main features:
Please, visit the repository for more information and I strongly recommend you to try the example project to see what the framework is capable of.
Any suggestion is more than welcome, as well as your star ;)
Cheers!
Hey guys, it's me again :) Hope you are doing well. I've been using ReSwift for a year now and there is always some concern in my mind: is it really a good practice to keep all the states/substates in the memory?
Say I have a view, which dispatches an action to its middleware, the middleware talks to the network service and fetches the data back, after that it fires an action to set the data to its viewState, then the view observed its state changes and reflects that. Everything works perfect. But if I keep doing this for each modules in my app, will it keep increasing the memory usage and some day it might be too high?
I would like to know what are the todos and not-todos when dealing with various modules with various data (info displayed/stored in the state).
LoadInitialStateAction
that resolves with an array of [Item]
; i have a middleware guard
ing 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
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