title: Statefull components interaction with store that might be async
body: <p>I’m working on a React Flux project where async interaction is an ongoing thing and I’m still a bit wonky when it comes to the react lifecycle.</p>
  
  <p>In my statefull components I have a getStateFromStores function, if there is no state in store, this returns a false bool, otherwise it returns the state.</p>
  
  <p>As I have it right now the cycle is as following:</p>
  
  <p>I have one bound function (ES6 react class) in my components called getState(), this simply invokes getStateFromStores and checks that the return is not false, and if not, invokes setState() with the state.</p>
  
  <p>Since notifications of state change can come from different sources, I like to declare the logic in one place (getState)</p>
  
  <p>State change can come from the following:</p>
  
  <ul>
  <li><p>ComponentDidMount (should I move this to initialState?)
  This is the first thing that happens in the components lifecycle. (And unless state already exists in our store, we get false in return)</p></li>
  <li><p>ComponentWillReceiveProps
  If state is changed in parent component, we notify the component that it should fetch new state with the new props.</p></li>
  <li><p>Store change listener
  When store has new state, getState is invoked as the callback (although a bit problematic, because emit can happened for reasons other than as a consequence of the given component’s call – so I might implement an onStoreChange as the callback who in turn calls getState)</p></li>
  </ul>
  
  <p>Im toying around with a state prop called fetching which I can use to control the flow, but is this problematic? – because every time I change state it triggers a render (?) — could I use static for this?</p>
  
  <p>I imagine something of the following; DidMount triggers getState(), getState sets fetching to true, and now all other invoke-tries will fail because of the bool check.</p>
  
  <p>Then I’d implement a resetState, that brings back the state to default (fetching false) and then getState can be triggered again.</p>
  
  <p>I’d abstract all this functionality in a “Higher-Order component”</p>
  
  <p>Thanks!</p>