In this other case we are going to be working with react components. ReactJs with a Flux architecture offers another approach to work with this problem.
First the folder structure is this one:
Here is the diagram in order to understand about Flux architecture:
In this case, redux has the same folder structure as the one presented by Flux, although it has a little change. Now it has a folder called reducers instead of storages.
To me redux seems to have some good things and some particularities that cames to my head when I was developing.
In the first impression after watching those 30 videos from Dan, I thought about that kind of simplicity on solving problems is the one that make us happy in our day by day as developers.
Also during this redux learning I had to deal with some new things. React router, this router brings a lot to the developer, and you will find that there are many options like react-redux-router and others. I just used one, and in this case with browser history as strategy, in other frameworks I always used hash strategy so in order to learn something new I just tried that one.
Writing about Redux actually makes me feel very close to Ecma 6 / 7. It is great experience!.
Lets go a bit further and think about what redux brings to me:
Simple and Declarative
Simple and Declarative
Looking at how things are solved in those 30 videos of Dan Abramov is inspiring. All of this redux idea brings to light a lot of techniches from Dan Abramov to do things easier and simple, like presentation objects, and separation of concerns.
Working with react Flux brings a lot of different tools to work with. I felt like redux brings some kind of guidance on how to solve a problem in a particular way, we will go further on this in the following points like in the cons of redux. I beleive this gives a ground on where to go for redux as a solution, so I found guidance here.
One of the points that Redux talks about is communication between components and separations of concerns. For example, the structure that comes to my mind when thinking in a redux solution would be a tree of components where the containers of an application says to the child what to do. This comes with Flux too, but Dan showed me in those 30 videos how to delegate from a container to a component my needs to be solved. I just called Communication in lake of a better name to say so.
Having a few talks with some of my collegues about flux, we have a discussion about communications and states, and how all this flux thing would actually be stable enough in biggers applications without taking care on some aspects that matters to a good developing practice.
Redux brings to light the concept of pure functions and inmutable states to his solution to problems. I feel this as a preventive thing to reach in biggers applications where every component could actually have an state setted by some information in a storage, I feel there could be some cases where inestability could come if we don't have carefull on our decisions with the state.
Abstractions and Green
Abstractions and Green
May be because I was learning about ECMA 6 / 7 and jsx in the same time, but with so many Abstractions that all this brings I found many errors that happens in my code without any good signal on what was going on. This is hard for beginners, because they step on those little problems like missing a typo or very small things that does not have anything to do with the main problem they are solving
I know that react components life cycle is plain simple and that jsx is also simple, but it would be great to have some sort of help bringing as clear as possible little problems or details a developer come accross. Although many of this is being worked with tools like the google developers tool for react. If you have any other tools thanks in advance XD.
As we said Inmutable States also serve as a prevention to solve problems. But I beleive there would be ocassions where having inmutable states would not solve for certain problems. Also thinking on inmutable states makes me think I have to be very close to free listeners on the unmount of a component and see that those states will not be having any other reference in memory, having a good profiling on big react applications would be great in order to bring to light those key value points on unmounting or taking care of states.
I know that state should be serializable, and there should not be many problems about garbage collections. But I beleive there should be some other precausions to be taken care or analyzed if you go a bit further on bigger apps with inmutable states and history about them.
This is something we have to take care too, everything in the ecosystem of redux is inmutable by definition. So if you go for Redux, no library messing around with your state, thats not a big problem, but is to pay attention.
Redux is a nice point of view in order to solve many problems with Flux in my case, and I beleive it brings of simplicity and concepts to be clarified in a team before working in order to solve problems in the best way possible.
I know Redux will grow a lot and will bring key values to development of the day by day of any web developer, I am glad to learnt about it, and it will be in the first line when thinking on my next developments.
As a boiler plate I just go through:
Redux easy boilerplate
I know that using a boiler plate as a first instance is not the best. But as I knew a bit about webpack and this is making those configurations for Redux in a very simple and nice way I just decided to use it and learnt from it.