Hammock thoughts

Coming into the refactor I knew I wanted to replace our current state management. I built the whole plan based on the idea that we will be using a new state management solution. Then it dawned upon me that, yes, again, I was working in my own head. I was suddenly not so sure that the team would be on board with me...

Yes, I am talking about the Redux or not question. I made a full plan based on the premise that we will be moving to Mobx. After some time planning, I suddenly realized that non of my teammates ever used Mobx, so it might not be such a great idea.

In order to move successfully forward, I (with the help of my boss) did two things: 1. Provide the space to run a test with Mobx - each of us build a small todo application using Mobx and tried to work with a remote server to actually have a feel for the technology. This was my boss' idea and many thanks to him. 2. I started thinking, if I have to use Redux, how would I do so in a way that I won't hate myself.

Luckily, the test run was a success and we are transitioning to Mobx. But meanwhile, I actually have an idea how I would use Redux if I must. I started by listing the things that I like in Mobx, and what I don't like in Redux.

Like (Mobx):

• Clear place to view where there logic actually happens.
• Data is served the way I want to consume it.

Dislike (Redux):

• Too many files. Whenever I want to make a change I have to edit at least 3 different files.
• Middlewares... not sure if I really dislike this, but I wouldn't use it for crucial logic as it is hidden.
• Asynchronous work is hard. This is more of a point to remember so I have a good solution for it later.

These were the main issues I had. I started reading on the one hand more opinionated approaches to using Redux, and tried to re-think how I would model my stores. For starters, I looked at all the different solutions for async work, and found that my personal favorite are simple thunks. This gets two birds with one stone - I wanted to keep the logic in the action creators. Instead of having relatively dumb actions, I wanted store most of the logic there.

Next, To solve the clarity of the way I consume the data, I wanted to start using more selectors. Yes, this is a solved problem, the main issue was with our implementation. But I still find it important to decide how you want to things to work.

Regarding the sheer amount of files you need to edit each time, I found the ducks-modular-redux idea quite appealing. Not sure of the exact implementation, but I did think I'll try to move all logic to one file. I tend to agree that if I add or edit an action, I will usually have to edit the reducer and selector, so why nt keep them close together. The thought was to start with all of them in one file, then slowly separate them when needed, but keep them close.

And that's the gist of it. I never actually got a chance to try this out, but at least if I ever have to work with Redux again, I do have a clear idea regarding how I might like to do so.

Cheers