Review client-side code structure, state management etc.

[borekb]

We started the JS UI rewrite more than a year ago and getting UI features there was the primary focus for the past year. In the v4 timeframe, we should review whether the current structure still fits. Specifically:

• Should we start using Redux / another state management library?
• Is the code / folder structure fine?
• Do we want to keep using TypeScript?

Any high-level comments are welcome.

[Ishirak]

Should we start using Redux / another state management library?

In a single word. Yes.

Absence of a state management library makes it ​sometimes​ hard to follow the codebase. Some components do more than just a one thing, which make them hard to reason about and any change to them can bring a lot of unwanted bugs. Also any further SPA’s functions can be hard to implement without a state management library. See #1091.

Is the code / folder structure fine?

Primary directory structure is good.

All of the configuration files are on a good level of readability and functionality. Therefore, any further changes to them will be easy to do.

Sadly, structure of React.js components and the techniques used in the codebase are not so good. Components, which communicate with APIs or are parent components, have sometimes very bad readability, inconsistent structure and are hard to follow. Also further changes to the components will definitely cause a lot unnecessary bugs.

All of the components lack consistent format and some of the components even pursue OOP techniques in their communication, which are not ideal in the React.js functionality and ecosystem.

Most of the components do more than just a one thing, which leads to a bad readability and clarity. Part of the possible solution is to use a state management library, which can resolve some of the state managemet problems, but cannot resolve all of the problems, especially clarity and readability of really huge components. Those component have to be split into smaller ones.

Structure of components is also not ready for further changes and possible new functionality. None of the components deals with the fact that is not necessary to render itself and its component subtree. Therefore, some of the new functionality can lead to a bad user experience, because React.js won’t be fast enough without optimization.

Do we want to keep using TypeScript?

What advantage(s) does TypeScript have? Is current TypeScript codebase implementation clear enough? Can be current TypeScript codebase implementation improved? Does the team possess experience of another way of SPA development, especially with React.js library? Can be such an implementation clearer, more readable? And will it be the same in the future?

These are just examples of a few basic questions which the team has to ask and answer to. If the team uses TypeScript just for the intellisense or because it just looks like OOP language, then maybe is time to start looking around for more options. On the other hand, if the team uses TypeScript features which another development technique does not possess and can’t develop without these features, then change can be painful and not effective.