React, Redux, Webpack
A little of context
Coping with this was difficult. I’m not a fan of front end development, yet I’ve done it quite a lot. My concerns have never been a page looking nice, but a page working good, instead. So you probably will never see me talking about CSS or SASS. I’m an advocate of using things as Bootstrap, Foundation or Google’s Material Design (not sure about this one), so that the page won’t look ugly.
So I started a project not so long ago. This project is called Karbono, and to be honest, I had already started it long ago. Things were just so hectic and it got forgotten. When I took it back, I wasn’t happy with any of what I saw there. Neither backend nor frontend were something I’d feel proud of.
You know? It’s supposed to be about the money, but for me it’s more about the challenge. I redid the backend in a really awesome way (but this article is not about it) and the frontend had to be awesome too. The frontend was initially done with AngularJS and RequireJs. I could’ve continue with that but as I told you, it’s more about the challenge. What was that awesome technology that everyone was using? React! Let’s learn React!
At that time I wasn’t (self) aware that a technology (library, framework, etc) clicks with me when I have understood its philosophy. I was the kind of programmer who was trying to make ANOTHER philosophy fit with a new technology that I was barely discovering. Making AngularJS’ mindset fit in a React project is just plain wrong, whoever is going from AngularJS to React, please don’t try to make a React project thinking in AngularJS way. You’ll see, they have different motivations, and to begin with, AngularJS is a framework, React is a library. You have to use react with many other libraries like Redux, Lodash, RxJs, etc! But this is not a comparison between those two technologies. That being said, I finally understood it, so I looked for a framework that uses React, and so Flux appeared. Flux ended up being just a collection of ideas of how to develop web apps, but it didn’t have a clear implementation. Then Yeoman appeared and gave subtle hints that something called Redux was being used by many. And I looked at it and loved it. That’s when I finally started to understand those 3 technologies. So here we go!
Redux is just a state container for a web app with a very cleary philosophy, really easy to understand. For those who like functional programming, Redux is a delight! Why? because its state transitions are represented with a function… a reduction function (that’s surely why it’s called Redux). If you’ve ever reduced a list, you know you are reducing the items in the list to produce a result, right?. Well, with that analogy, the items in the list are actions in the web app, and the result is the current state of the app. If a new action is reduced, a new state is created. Easy huh? In Scala notation it’d be like:
In Redux, contrary to Flux, there’s only one store. And there’s only one way to change the state of that store, and it’s by dispatching an action. The store, as you might’ve guessed by now, is created with the reduction function (and a initial state). Where to put async actions, such as api calls? well, Redux makes it clear: Not in the reduction function, that function is always synchronous . But you can start tasks that end up dispatching many actions, such as “started loading items”, “obtained items from async action”.
React was difficult to understand. Basically because I understood Redux first, and because I came from Angular. The main concept to understand is NO TWO WAY BINDING. The second concept to understand is “forget about DOM manipulation, you render it all always in a virtual dom, and react will handle the dom manipulation, and it’ll do it in an optimized way”. The third is something it’s better said in types.
type Component = (Props,State)=>DOM
Or, let’s tray say that in words. A react components is merely a render function that uses the provided props, and the current state to produce DOM. If you change the state, new render… if you change the props, new render! That’s it.
The third one was troublesome to me. Mainly, again, because I learnt Redux first, and in the tutorials they use what is called stateless React components. I faced it when trying to open and close modals with Redux. Not nice to have a Boolean in the Redux state for every modal that may exist in an app. You just don’t want to pollute the global state with attributes like “isFilePickerForStockModalOpen”. Certain state properties of the whole app just don’t deserve to be in the Redux Store. That’s when the state of the React Components comes in handy. There you could have that attribute without polluting the Redux Store… neat huh?
There are certain rules of thumb when deciding if using react component state or redux store to save the state of something. Guess you’ll infer it yourself, and if not, check this