New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review client-side code structure, state management etc. #1083

Closed
borekb opened this Issue Jun 27, 2016 · 1 comment

Comments

Projects
2 participants
@borekb
Copy link
Member

borekb commented Jun 27, 2016

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.

@borekb borekb added this to the 4.0 milestone Jun 27, 2016

@Ishirak

This comment has been minimized.

Copy link
Member

Ishirak commented Jul 5, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment