-
Notifications
You must be signed in to change notification settings - Fork 81
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
[Editors] Redux/Folder organization #1239
Comments
@connorhaugh great proposal! Some questions I have...
|
There were three choices here:
|
@connorhaugh I agree with Jeremy, this is an excellent proposal. It solves the problem of separating the framework concerns from the internal application concerns, and it cleans up the confusing redux structure by putting the data folder and slices directly with the editors they supplement. I see that this extends to a revamping of the whole folder structure, and not just the redux part of the application. Which I think is a good thing. I think if you come from the pure React part of how this project is structured, we anyway need some changes, and I was going to suggest folder structure changes for that sometime in the future. I think it would be good to find our common ground here, and can go through everything just one time to create a very good folder structure that is sustainable in the long term. Right now you have a Right now an example looks like this: SRC and this can go down many more levels of nesting. Much better would be: SRC The naming is also improvable, for example, SettingsOption is functionality wise actually just a collapsible card (it has absolutely no logic that is related to answers), so we should call it CollapsibleCard and then we can reuse it in many other places. My concern with our current folder structure is that we have a deeply nested (and chaotic) structure where components are in other components' folders are in other components' folders and so on. This may seem intuitive, but in reality it is quite bad. It completely prevents components from being reused, and it also means when we build something we have a big discovery problem with existing components. I have been in more than one project that started with such a nested folder structure and we successfully moved to a much better non-nested folder structure because the former didn't work well enough. If you do a search for community discussions about React folder structure on the internet, what will be the common consensus and confirms my point is that 1. nested components are bad for multiple reasons 2. the most popular folder structure are something extremely flat like a pages and a components folder with ComponentA, ComponentB, ComponentC living next to each other and 3. because applications can grow extremely complex, flat hierarchies have their limits, so commonly grouping components by features but keeping them as flat as possible is a very good structure. features would mean I think something more like functionality instead of parent elements as we have them now. |
Another point to consider is how other teams facing the same questions organized their codebase. This proposed ADR which is in progress defines a set of best practices for folder structure. When discussed in the fedx frontend group, it received very favorable feedback, and it is also very much in line with React community recommendations (https://profy.dev/article/react-folder-structure). |
This is the tentative folder structure we are proposing after discussion. We are also proposing adopting the ADR on feature-based organization that our enterprise colleagues follow. Details like exact folder naming are left a bit open for now, as it is tentative. The next step is for me to put up this ADR and for the whole team to review it. Obviously additional feedback from outside our team is welcome and will be considered.
|
Folder structure proposal.
We Currently have this folder structure:
This has two problems:
Therefore, we should have this folder structure:
The text was updated successfully, but these errors were encountered: