Exploring Redux loading semantics.
• Mark Eschbach
Back to the identity application. I’m jazzed about this one, but I’ve eventually got to finish out cloud-nginx-proxy. Anyway, onto implementing services. So back to the question of how to deal with loading of user data.
So my plan to dispatch in the dispatch wiring method when connecting a component partially worked. It spit out a bunch of errors on the console about not being able to dispatch an action while dispatching an action. It would have been cool for the action dispatcher queue them up like once per tick or something. I’m wondering if I’ll find out later most dispatch cycles are dispatched immediately. Stack traces certianly were long. Much longer than Java’s which people seem to complain about alot.
So it looks like I’m just trying to be too smart. Based on this conversation it looks like componentWillMount
is the correct place to put any initialzation code. The state reducer definitely runs as the state is properly reduced. Unfortunately the dispatch
properties aren’t attached at this point in the lifecycle. Looks like this is intended so componentDidMount
is the key. I wonder what the use cases for componentWilMount
are? I’m sure I’ll run into them shortly. Works like s charm. I had a little scare because the performance of the system dropped however this was due to low battery.
So onto building an action! I haven’t really read through nor thought through where the API calls should live. In theory and according to the redux advanced async tutorial I have the action actually go through dispatching using a promis generator. I skimmed the article then found out I would need to additional middleware. Unforunately I’m not familair enough with this stack to feel comfortable including additional environmentally altering things. I was hoping to peak at the redux-thunk source to figure out the inner workings. The linked gem of a session comes off rather arrogant: Why Do I Need This? If you’re not sure whether you need it, you probably don’t. Almost as bad as the begining of the year when I mentioned to the react devs their tutorial was objectively broken…and they told me my many years of expierence wasn’t good enough for them to listen. Looking for an approach which allows me to check if an entity is cached prior to hitting the serve turned up as an anti-pattern, expect ya know, for the reason why: caching. Anyway, I’ll cu thte cache and force the decision into the component, I don’t feel like this is the correct choice because this will force all components interested in this entity to dupelicate code.
Well that worked out. Cached and everything! Awesome. Bed time now though.