Open hvkale opened 6 years ago
Actually thinking about it more made me realize it is definitely not the best idea to call this action from Widget's build
function for various reasons
build
multiple times during its lifetime and it is not ideal to do something as heavy as a network call every time build
is called.state
and if data is null
or empty, make a call.state
for null
or empty data isn't ideal either cause null
or empty data could be legitimate states. It does not always mean that network call was never made.I think the best approach would be that the store (MessageStore
in this example) also listens to user auth state changes and as soon as the user is logged in, this store also receives an action callback and kickstarts the network fetch instead of waiting until widget does it.
This approach works well in this case but also leaves a question, what if this MessageStore
were to depend on some data from UserStore
? Meaning that both UserStore
and MessageStore
listen to same action callback but for MessageStore
to react to that action callback, it needs something from UserStore
. In this case how do you make sure that UserStore
always finishes its execution before MessageStore
starts its execution? I believe React's Flux has API waitFor()
The title of this issue could be a little misleading but I was not sure how else to describe my thought process, so please stay with me and read along.
I am writing a Flutter application that uses flutter_flux. I have a few stores and a few views (widgets) so far. Right now I am in a dilemma on how to do the network API calls. My widget loads but does not have any data to display yet, which is fine, but now it needs to call my network API service that responds with data. Here is what I am thinking design-wise. Please share your opinions on it.
Widget -> Action -> Store -> Network Service Call -> trigger()
In this design, the widget kicks off an action something like
fetchMessages
and the store listening to this actionMessageStore
receives a call to this action. In the action callback, this store kicks the network call that returnsFuture
. In thethen()
callback of thatFuture
, this store mutates it's own data and callstrigger()
so that the original view that started this now receives a callback. Similarly, also incatchError
of the sameFuture
, this store callstrigger()
with some other mutation that maintains error states.In this design, I am not exactly sure where do I call action from the widget? In
build
or ininitState
? My thinking is that ininitState
the widget will grab data from store but it will benull
or empty initially, andbuild
will render empty view but at the same time, kickstarts the cycle described above, which calls back to the widget later and thebuild
function now has data to render, re-grabbed from store.Do you think it is a good pattern? It still abides to Flux's unidirectional data flow and does not let store data to be manipulated in any way other than an action callback.