Organization of folders and files

[mark-omarov]

I believe we could improve folders and code organization in the project.
The current way of storing everything in the root folder is not appealing (my personal opinion, up for a discussion).
I'd like to propose establishing and agreeing upon the structure of the project, documenting our decisions, and following it as the standard of the project.

NextJS allows src directory, I think in general it's a good idea to isolate business logic, utils, models, APIs, and components inside the source folder.

NextJS has built-in support for absolute imports, I don't think anyone would be against it.

If we will have absolute imports configured, I think it's a good idea to structure src child directories appropriately.
I'm a big fan of the feature-sliced design, I think it's a great methodology that does allow tweaking to fit any project requirements and does not enforce its opinions heavily.
For our case, since we use NextJS, we can tweak it a little bit, to fit our needs, and exclude some layers, still having a great level of decomposition.

Onboarding is also easy with it, as essentially every new member just needs to read the documentation once, and understanding how the project is structured will be easy to grasp, instead of figuring it out, or asking the community to explain it. The concept of public APIs is an amazing thing and has served me very well in the past.

Please go ahead and read through the documentation to understand in-depth my proposed tweaks to this methodology in our context down below. (Some images might not yet be translated, let me know if you need any help understanding them).

Since we're using NextJS, the heavy lifting of routes is already taken care of, but there's an overlap of naming between NextJS pages, and pages for the FSD methodology, I think a solution could be either renaming the FSD pages into something like pages-components/pages-layer or simply re-exporting. By re-exporting, I mean leaving NextJS pages folder in the root directory, and only importing to that directory exported pages from the src/pages, and all of the FSD methodology-based code keep in the src folder. Not the cleanest way, but I guess it comes at its costs.

The problem of having both FSD and NextJS pages together is that it seems NextJS doesn't allow anything except pages themselves, however, pages might have their own uniq components, styles, and models to them, and as of now, there's no way to place them in the same folder with NextJS.

The idea here is to transfer gradually, we can start building new implementations with the help of methodology, while giving people time to finish their currently running tasks in the way they're already doing it, and then gradually move old pieces to the new structure, that's already in place, reducing the potential room for conflicts. We don't have to follow the methodology strictly, we can bend it to fit our needs, or simply scrap parts we want from it.

As a bonus for maintainers, I can speak from experience, that planning work for somebody, when you can outline your solution in understandable terms like layers, slices, widgets, and features is extremely helpful. It brings clarity to the person responsible for the delivery of a given task and takes away guessing where to place things when done right.

I'd like to hear more thought on it from you guys, let's start this discussion. 😃

[iShibi]

I'm up for moving pages, components, and style into an src folder to keep the root directory uncluttered. Not sure about FSD tho, doesn't seem that it's required at the moment. If a need arises we can get back to this discussion again.

[ykdojo]

FSD is this right? https://www.essentialdesigns.net/what-is-an-fsd/#:~:text=A%20Functional%20Specification%20Document%20(FSD,each%20item's%20functionality%20and%20flow.

[mark-omarov]

Yeah and no 😄
I'm not talking about a functional spec document, I'm talking about this:
https://feature-sliced.design/

[Jonyango]

I love the idea of improving the code organization. I looked through the F.S.D. documentation, and it seems like overkill for now but something that can be adopted once the project grows. Aren't there any other methodologies we can adopt? Also, what @iShibi suggested seems like a good way to start, and we can probably add a services folder for our API calls. We haven't talked about it yet; where would state management fit in F.S.D.?

[mark-omarov]

State management would fit into model segment of slices.
I agree we could simply adopt it as we grow. I'm not aware of other well established methodologies, if you know any - please share, I would love to check it out.