Monday, June 5, 2017

React-Redux Concepts for API Devs


If you landed here, then chances are you are an API developer who wants to know what this React-Redux buzz is all about.  I'm transitioning biaschecker.org to React-Redux.  I maintain the API and front end technology stacks for this service.

For this post, I'm not going to say a lot about why I chose the stack.  What I'm going to cover are those concepts I, and I'm assuming other, API Devs probably struggle with when looking at the combination of technologies above.

What is React? Redux?
More appropriately, what are react and redux?  This is probably a useful time to get into what they are not.

React is not Redux
Say it again a few times.  Good.  These are separate libraries which do entirely different things.  I'll link the formal docs for both at the end, but here I'll explain a bit.

React is a component definition library.  It's also pretty simple.  You get a React component by subclassing component (basically), and that component gives you some cool features, like only re-rendering when it needs to. I use subclassing loosely, though.  It is JavaScript after all, and it'll be confusing to get into it in a conceptual discussion, so let's say it's close enough.

But...react is not ES6.  Nor is redux. All of those fancy syntactical changes in ES6 are not react, but react really is more digestible in ES6.  Note that if you're a web dev, then you probably laughed just then.  But if you've been knee deep in API or service development like me, you need to know this.
Redux is a way to store state and monitor state changes, if you're a web dev.  A good way that helps me to think about it is as a messaging system, with a subscription model.  As with any messaging system, the format of messages is something producers (your app) and consumers (also your app) need to agree on.

With that system, however, comes a huge list of limitations on how you should use it. These are conventions.  If you step outside of the conventions, people already in the community should, and will, yell at you.  I'll cover these in more detail.

Summarizing, react != redux != es6.  React == components, redux == state and messaging.

One more thing.  These technologies live in Nodejs, and are very disciplined (as seems to be the habit of the node evosystem) with regards to separation of concerns.  This means installing react and redux and even react-redux (bridge lib which makes a lot of things easier) will only ever be enough for test apps.  If you want to do real apps, you'll need a lot more.  I'll link some resources I've used.

Gotchas
Okay, so you've read about actions and reducers, and that there should only be one store. I'll fill you in on what probably wasn't explained.

Reducers only change state, without side effects.  Actions return events which tell the reducers when to change state (and dispatch those events).  So when do I make my API calls?

Well, in the action functions, before returning the event.  The results of those calls return bits of data you add to the event before returning it for dispatch.  It seems simple, but it's actually confusing because the action functions are called from the reducers.  This makes those API calls side effects, yes?  Conveniently ignore that complication.  This is a convention, and actions are the right place.

Why doesn't my state ever change when my react component re-renders?

Too much magic.  You've been swimming in java or c# too long without coming up for air.  There's literally nothing magical about react and redux.  React does what it says, and tries to re-render when it thinks it's time to (glossing over the fact that I'm kind of conflating react and react-dom).  If you want your component to be smarter than that, you need to make it so.

Fortunately, redux exposes a subscribe method (see? messaging) which will notify you when something else in your app changes the state.  Hook this, and look for things in the state that your component knows about.

The biggest hurdle in understanding react, redux, react-redux for me so far, is what I've mentioned here.  Conflation of ES6, react and redux concerns, expecting too much magic, and being a bit too literal in interpreting the associated conventions.  Learn from my mistakes (and ask me anything - I'll respond if I can).

Links:
React:  https://facebook.github.io/react/
Redux: http://redux.js.org/