A better way to organize redux state
As a tech lead at Holloway, I think a lot about software from a theoretical standpoint, sometimes it can be pure philosophy or hardcore algebra. In software engineering interviews, math questions are often used to test analytical skills. But it’s not just in interviews that you need to think mathematically. I’ve found it’s wiser to spend a few days thinking and analyzing a problem before you write a line of code.
A few years ago, in an interview for an engineering role at Stripe, I got a question about building a data store that deletes values after some timeout (or makes them inaccessible). This is a beautiful puzzle because it can be solved by many approaches, most of them will work, but only a few will be good ones.
The puzzle found a place in my memory between things I’m coming back from time to time to self-reflect.
Suddenly I realized that having the ability to set a lifetime for records in key-value store (or not deleting them at all), changes the way how we can organize and work with things like redux store state. For example, we can forget about overwriting records in a store state.
Folks who work with databases probably would not understand my excitement. There is no such thing as overwrite in DB. You can write, update, or delete a record. But the redux state is a bit different thing.
First of all, it is client-side, and client-side apps are stateful, so you need to have a state that describes which data to render and actual data that will be rendered. Redux is very handy when you need to keep data like that somewhere for your app.
Some random todo-app could have a store state that looks like that:
It is obvious that we need to put everything into a store to describe what app can render at the moment. And fetch new data when needed, resolve route state for example, or load data to show task details inside a popover.
But what if there is a need to load data before a user clicks a link, or if we need to cache data…
