Block Explorer GUI rebuild
Why we need to rebuild the whole GUI?
At the very beginning, I must agree that the iteration approach is a much better way of writing software than a full rebuild. But the current state of code is unacceptable, and for now we will lose much more time trying to do anything useful with that state of code than just making the whole thing from scratch.
The list of issues with the current state of the code, after my audit:
- Lack of typescript. If we want to painlessly manage the data from the API, we have to prepare proper interfaces and types and structuralize the communication between components.
- Too many dependencies. I saw almost 30 dependencies in NPM, around 10 of them were dead, but still, it's (more or less) 20 dependencies in use. Most of them can be fully replaced by JS features or better tools.
- On the FE team, we decided on our basic technology stack, which is React + Next.js + Typescript + Tailwind and Shadcn UI (for style). Block Explorer uses only React from that list, and for other tasks – different tools. In my opinion, it's better to keep our infrastructure similar across other projects.
- No config. Right now, all API calls addresses are hardcoded in many methods. To use Block Explorer with different BEs, I had to modify 8 files. It's unacceptable.
- Calculations are done in an unsafe way. In the future, we'll try to avoid doing any math in FE's utils. Right now they are without any docs or comments, with strange hardcoded values and unsafe JS operations that may easily produce wrong results in decimal's precision.
- A lot of pointless utilities like getting +1 blocks, clearing filters, etc. All of that may be handled by better components.
- Using too many HTML tags. Like having
<StyledTableCell>
in one page declared (not called, declared) 36 times! - Lack of the generic code. The components are too specific and, despite having almost identical functionalities, are completely separate. Instead of using generic cards and tables, all are written for specific views.
- ...but at the same time, the style is shared across them! Specific tables use the style of other tables!
- The data flow across apps is a mess. Most of it is distributed by useContext, some by props, but without any clear logic in that. More in the next points:
- There is no one, reliable entry point for API data. Right now, the calls are started in useEffects across pages, presentational components, and in useContext. When looking from a distance, any component may be the first source of data, which makes providing it too chaotic to divide it into variables and provide it across smaller components clearly.
- Context is overused when, in most cases, props are obvious solutions (and better).
- There is no clear separation between getting data, handling it for FE's purposes, and saving it. And the chunks written to states are too big. That's another thing to fix with the new API later.
- Because of the lack of Typescript it's very difficult to know what presentational components are needed.
There are more minor issues, but the list above is the greatest reason for me to propose a complete rebuild. I think it's necessary for future upgrades in that project to create a solid structure that is easy to manage and follow. And let me tell you, this is a rather small app. It has 7 different pages and a few components for display. We don't need to handle user accounts, complicated forms, or input. That's why it should be possible to recreate it in a relatively short time.
The plan
I'll create more detailed descriptions for separate issues later. Here is only the general plan:
- Create a new Next.js React app. Configure it.
- Add and configure the necessary style dependencies.
- Create
FetchingService
for making a generic structure for API calls. The shape and full functionality of that service isn't fully known yet, but with the current number of endpoints, it won't be complicated at all. - Create a basic layout and parent component for app.
- Remake all the previous pages. Prepare types and interfaces for everything that should be displayed there. Plan the necessary child components.
- Add useContext and providers to the app for every case, when some data needs to be reusable across pages.
- Import presentational components from Shadcn UI and use them to recreate old views in pages.
- Add simple utils to the component. If something is more complicated or should be used across many pages, move it to a common file.
- Start restyling everything, from the recreation of the previous one to something a little nicer.
- If at any level of preparing the app, we see that we need some API upgrades, we'll create an issue for the BE's team. Keep in mind that API can be adjusted for our requirements.
- In the meantime, fix the obvious issues written in Gitlab, if they can be fixed in existing views without adding big functionalities.
After all that, we should have fresh, clear code and a working Block Explorer. Then we can do a lot of upgrades to the application, and with a solid base, I believe it will work for a long time.
I'll divide the work between me and @pberezka. Because most of that is on separate pages in separate contexts, it shouldn't be a problem at all to divide it between two people. Of course, we'll be in touch with the rest of the team.