## Investigation

### Objective
Figure out the way to implement bundles (temporary sections) feature.<br> 
User should be able to rearrange bundles by drag-n-drop. CRUD should be implemented.

### Outcome


Due to the design absence of adding a new section to the homefeed functionality, I decided to follow the existing (tabs and lists) approach.
In order to complete the story, a few questions have to be answered.

 - How do I add a new tab?
 - How does the new tab switch content components?
 - How to add a content component to another tab?
 - Can Drag-n-Drop current implementation be reused for this feature?

As a result of conversation with all the frontenders in the Selectives area and my own reverse engineering research, here is what I found:

No frontenders know how to add new tabs, switch between them, or add tab-content components.
The Drag-n-Drop functionality is a custom, opinionated implementation that cannot be reused or even maintained due to an absence of proper knowledge transfer. A large number of implementation nuances will prevent that.

I also spoke with the designer - Misha. His opinion is that this application require more attention and love than it actually gets.
There is also no design for this app (neither an old or new one).

The opinion that I got from the backend developer was quite similar to the frontenders: there is no clear setup, implementing a new feature will require reverse engineering and data flow tracing. Adrian is leaving, and there is no opportunity for proper knowledge transfer.

I have to mention that the documentation for this project is outdated and cannot be followed in order to implement this new feature.

**Expert opinion:**

 - ***General conclusion*** is: this codebase is not maintainable from a client-side perspective (1 or 2 out of 10 for maintainability).
 - The main reasons for this are: ***poor frontend architecture***, ***crazy endless prop drilling*** (this alone puts this app in a very dangerous state), ***mixing approaches*** within similar components (functional components coexist with class components), absence of the Separation of Concerns principle, DRY principle, overal age of approaches were used, but there was no formal state management solution.
 - This setup combines client-side and back-end side areas of responsibility a lot.
 - There are also no standards for such things as: intendation, linting, typing, prettifying. Those things are not recommended, those things are must-haves for frontend development, not even for 2022, but it has been like that since 2016.
 - Domain expert absence makes this project on the edge of a completely unmaintainable state.

As a solution, I suggest creating a new setup that will have all the things I mentioned above and transferring the functionality of Go-Site-Management feature by feature, requirement after requirement. Aligned with a new frontend setup, this might be the first step to a much more maintainable, scalable, and readable setup that will be implemented across the area for other apps.

All of the frontenders (and designer) in the Selectives area support this idea.

This will also help to mark clear boundaries between the client and server sides, helping developers to focus on their own area of expertise, and will bring a lot of benefits for backenders as well. The representation layer should be separated from the data layer.

DEMO: [click](https://d3m07r6okrnrg.cloudfront.net/gsm-react/index.html)

REPO: [click](https://bitbucket.org/persgroep/gsm-react/src/master/)