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


I loved this one. And now that I think of it. My experience with front end development skyrocketed at some point out of mere curiosity and perfectionism (I know that’s bad for entrepreneurs, but I refuse to change that). I started using RequireJS because they all said it was cool, and I kind of loved it… or at least I understood it. When I started using Webpack I didn’t even know what it was doing, and at some point I just wanted to use Webpack as if it were RequireJS. You’ll see I make that mistake quite often. At some point I said to myself: “I hate Yeoman, that shit gives you all you need, but you understand shit”, so I decided to understand Webpack before continuing with the project… and I understood it. Everything about it sits in a simple idea: “Webpack only knows how to create a bundle given an entry js file that depends ONLY on other js files” (there are actually more, but that’s the more important to me). Everything that goes beyond that idea can fit as long as you transform it into Javascript (those are called Loaders). So the loaders take a file in some other format and process it to produce Javascript. That way you can make a js file depend on a SASS file. You can even chain loaders that produce other kinds of formats, the only restriction is that the last loader should return Javascript. There’s also the concept of Plugins; they are used to do post processing of the the javascript bundle produced by Webpack. Things like linting, uglification and minification are made by plugins. So that’s it.

Like what you read? Give Alejandro Navas a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.