Integrating Redux

You all know that Redux made the difference few years ago and now a lot of developers are starting using it (mostly together with React).
What people really miss is that Redux can be used alone inside a frameworkless project (or inside a project that has a framework/library that is not React).

I - as senior - recently decided to introduce Redux inside an enterprise project to manage the big amount of data that frontend has to deal with. One of the perks of having Redux is to have a one-way-flow to store the data, which basically sets some rules among the team and the project itself. Having rules is good. You team decide which ones and after that you are good to go.

After the integration

So, after three weeks of refactor, coding, testing, bugfix and lot of changes among the application (they were a lot, trust me), the application ended up having almost TWO HUNDRED REDUCERS, all of the them listening to the same actions. I can’t share too much about why so many, but it was due to the project needs and architecture.
The application didn’t have any subscritions to the state changes, so there wasn’t a reactive change based on the data inside the Redux store. Everything was done to manage in a clean and fixed way the data inside the application.

Even though there was no UI involved, the number of accesses done to the state was a lot! Also, the number of actions to store the data was a lot. (I did put some logging and I was impressed).

Although, there were no performance regressions inside the application.

Further optimisations

Here’s the good part of the article. Have you ever thought of importing a reducer only when is needed? I don’t think so. You might say that there’s no need because Redux is fast and you are right. However, sometimes there are cases where is better to do it. Like this one.

Redux gives us an API called replaceReducer which is basically what is needed is this case.

It’s not well documented but it gives you an idea of when to use it.

And that’s what I did inside the code! We already had code splitting inside the application. There’s a key point about this API, the next reducer that you provide will replace the old one, which means that you have to provide a new object that contains also the old reducers.

Snippets

So, let’s put all these idea together and see how this idea could be applied to a real world scenario. First of all let’s make a function that it actually create a new root reducer.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// two fake reducers for starter
const foo = (state = {}, action) => state;
const bar = (state = {}, action) => state;

// or `let` if you want to stick with functional/immutability
const currentReducers = {
foo,
bar
}

export function nextReducer (newReducers) {
// make some check here, here's is done with lodash. You could extend the check
if (_.isObject(newReducers)) {
// I'd suggest the latter approach
Object.assign(currentReducers, newReducers)
// .. or
currentReducers = {
...currentReducers,
...newReducers
}
}

return combineReducers(currentReducers)
}

So we have a snippet that gives a new root reducer with the new reducers that we want. How do we use it?
Let’s suppose that we are already inside a code splitted section of the application, for example the admin section. After the import() statement, we should behave like this:

1
2
3
4
5
6
7
8
// adminReducers.js where we have the reducers for the admin section
import { sideBar } from './sidebar'
import { settings } from './settings'

export const adminReducers = {
sideBar,
settings
}

Now let’s what’s inside the page where we actually need these reducers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import { nextReducer } from 'path/to/nextReducer'
import { store } from 'path/to/my/store'

import('path/to/admin/main/page', ({ renderPage }) => {
// let's request our new reducers
requestAdminReducers()
.then(({ adminReducers }) => {
const newRootReducer = nextReducer(adminReducers)
store.replaceReducer(newRootReducer)
renderPage();
})
})

function requestAdminReducers () {
return import('path/to/adminReducers.js')
}

Voila’!

Comment and share

Preface

I recently started a new job in bank company as Senior UI Developer. When I first joined I was told that the the company itself was using cutting edge technologies and stuff like that. In a world like this, a Frontend Developer loves to work with such technologies, and so am I.

Once I started, I understood that everything was misunderstood. They actually use cutting edge technologies but the whole ecosystem around it is fucked up. There’s a legacy thing, there’s a half legacy thing and there’s a cutting edge technology thing that is really bad used.

Bad choice

Although, the will of the team is to refactor the whole application smoothly and gracefully using the latest technologies and least, but not last, some technology that is well maintained and there’s assurance that it will be supported for the next five years at least.

The library that was chosen at that time was made by a guy there, so when he left it wasn’t maintained anymore. Bad choice.

Right choice

The frontend has grown so fast and so big that now it has become really difficult to evaluate what to use inside an application. Five or seven years ago there was mainly jQuery and that was always the correct choice (yeah, let’s also remember Dojo).

Nowadays there are lot of choices and which is good because it forces the concurrency and the evolution between vendors; from another point of view it’s bad because the decision process is longer and harder.

I don’t want to bother you people with libraries and frameworks we have around. I want to share how I take a decision.

The factors

I will now list which are the factors that, from my point of view, have to take in consideration when choosing a library/framework.

The Context

First of all the context is really important. I have worked in a company where they didn’t want to have a Single Page application because they were running an existing e-commerce and they wanted to target the widest range of customers. Also, there was the SEO to take in consideration as they have competition and they run SEM campaigns on the different search engines.

We didn’t want to use old technologies. So I created a POC using ReactJS and demonstrated the Server Side Rendering. That was like heaven. Giving the possibility to use a cutting edge technology and providing HTML straight from the server without losing optimizations. I know that Google crawlers are able to run JavaScript but there are other crawlers that can’t. That’s something to take in consideration because the business matters.

I another job we were dealing with an internal application. A website running through a dedicated application installed in the client machines. In that case we had move leverage and a wider choice of libraries. In the the end, I arrived that there was the entire ReactJS ecosystem. Brilliant. That ecosystem was perfect because we wanted to have the ability to create/manipulate components through an external configuration and at the same time being able to have a Metadata computer engine that could be standalone.

The beauty was that were aiming to have something like Redux has: the library and the connector for ReactJS. We wanted to have the Metadata computer and metadata transmitter for React. Good times.

Now, here I have to take a big decision that will impact the internal development for the next five years.

The functionality

Choice must be taken based on what you need. You don’t use a library if it doesn’t do what you really need, or it doesn’t allow you to add custom functionality.

Every application and every company has different requirements. You must take them in consideration when you have to choose your library/framework. You can’t choose it based on the hype of the moment, especially if you are working for an enterprise company, where stability and support are important. As I mentioned before, at the moment there’s an internal library that is not supported by nobody, fixes are done internally. There’s no improvement, it doesn’t allow you to do much.

If you need a templating system application because you don’t want to make too much leverage on the JavaScript side, you will choose something like Mustache or VueJS. Definitely not a library such as React or Preact. There’s no templating involved.

If you need SSR (Server side rendering), you could use AngularJS or ReactJS or VueJS or any other library or framework that gives you that.

If you need browser testing, you will definitely karma because is quite supported by the community.

The ecosystem

That’s really important. You want to use something that is widely used and where the community and the Open Source world is happy to work with. Redux has got a really big ecosystem where they created all sort of libraries on top it. In two years the type of libraries has grown a lot and now there are add-on for every kind of purpose.

Sometimes that’s driven by the hype of the moment but you have to take in consideration that once people start playing with a tool, they understand if is manipulable or not. And if is, which is the extent.

The support

Having a person that is fully committed to the implementation and fixing bugs is really reassuring. That’s why libraries such as AngularJS and ReactJS became really popular in the past few years. They are backed up by giants so for sure they have money to pay their developers.

Sometimes another libraries are Open Source so the commitment of the people is limited to their free time because they don’t earn anything from what they are doing. We now that the community is helpful but sometimes it’s just difficult. Thankfully, if the library is successful, you will backers and sponsors somehow.

Conclusion

So, choose with calm and do not force your decision driven by the hype of the moment. Document yourself, make experiments and make sure that the library will give you want!

Comment and share

  • page 1 of 1

Emanuele Stoppa

Programmer, Gamer and music listener


Senior UI Developer, Contractor


Dublin