refactor - global : new folder structure

[rbalet]

What would you like

A new folder structure

I'm coming from angular and I'm struggling a little bit with th actual folder structure. I hope it will make sens, but I want to add this issue so, maybe, we could debate with some react developers about the right good folder structure. I know I still have a lot to learn here :)

I've already published a folder structure for angular that we can use. I also had a look at this article which was talking about how the guy was structuring his react project.

So, here is a quick proposal (I'm not a react pro and hope it will make sense, if not then I excuse myself '^^).

src
├── assets (will contain flask_micro.png & logo.blue.png if it is still used)
├── components (*components)
├── layouts (*layouts - further explenation)
├── pages (*pages)
├── core (*core)
│ └── logic
└── store (store.js)
├── actions
└── reducers

I see the problem that will arrise about paths, but once we will have update to typescript, we would be able to use path from our tsconfig.json file and it will make everything much more cleaner :)

Further explanation :

*components the actual folder, I also wanted to add a fragment folder (I explain the difference here), but it isn't really react standard

*layouts We already have a layout folder but it is quite static, what I would do is :

• Create a main-layout (or grid-wrapper) that contains grid-sidebar and grid-contents
• Create a sidebar-layout which will contains sidebar-header, sidebar-content and sidebar-footer

Doing it like this would help us :

1. Remove the sidebar in one click (if we want to hide it when we are on smaller laptop)
2. Adding into the sidebar-content some specificity (useful for #51 and #56)

*pages I cannot find the main page '^^ I thought at the beginning that it was the App folder but doesn't look like, is this folder still used? Objective : put our page here, so when someone starts working on the repo he would be able to see directly where the app start, also see that we have only one page and so on. (this folder isn't that important, but could be useful if the app need another page or so one)

*core Contains global function that our app need to run, will make sense later if we add interfaces, although I'm not really sure how to organize it in this project. I also added the logic folder inside (can possibly don't make any sense '^^)

Well, I hope I didn't tell too much foolish things.

[FelixHenninger]

Hej Raphaël, and many thanks for your feedback! I for sure hear you regarding the folder structure -- there's for sure some potential for improvement here, and it's valuable to get an outside perspective, so let's cease this opportunity!

I think you might find it interesting to look at the folder structure for create-react-app to get started, because they describe the code entry point we use (src/index.js). There are also countless articles about structuring redux apps, which (to my mind) resemble our code much more closely than the article linked above.

Here are a couple of quick thoughts: First, we have quite a number of the folders you propose already, simply because some are standards in the React (or rather Redux) world, such as actions and reducers. Regarding the other differences:

• assets in your suggestion is already present in form of the static directory in the repo. You're right that logo.blue.png is no longer used and could be removed, but I disagree about moving the footer icon into the assets -- in my (current) view, as long as they are not re-used globally (and as far as I know we don't have any global assets), I would rather have static files bundled together with the components that use them (again, if they are only used in one place).
• layouts: You've already spotted that this exists as components/Layout. The sidebar lives in components/Sidebar, where you could also add further components. So my philosophy generally has been that all parts of the application are components; the main difference is in their scope (i.e. we have a few very general ones, like App and Layout, and some fairly specific ones like Icon; there's also a distinction between presentational and container components, as well as higher-order-components, that isn't super-visible in our project structure, but I'm not sure it should be). I'm not sure what you mean by the folder being 'static', could you clarify? (I really like the idea of adding a sidebar toggle from a UI perspective though! In my view that would go into the Layout component)
• pages: I'm assuming that this is what you would call routes or views in other frameworks? The reason we don't have this is that there's really only one view in the current implementation: The global view state only knows which component in the study is currently opened (for completeness, some of the modals are run through the global state). If no component is open, we show the welcome screen. I would be super-open to adding a router so that changes in the view are reflected in the URL, but I don't think that's strictly necessary, and might even be confusing if the URL points to components from a previous study. I'm not entirely sure here, but I'm open to discussion.
• What you describe as core seems, in my understanding (feel free to correct me though!), very similar to our logic folder? In the builder, there is very little actual core logic as the interaction with the components drives most of what's going on, alongside the redux-based state management. Most of the logic relates to generating the preview and saving experiments to disk in various formats.

Ok, so much for now -- I hope things make slightly more sense, and helps you navigate the code a little better. I'm in principle open to restructuring, but as with many things I would ask you to do a cost/benefit analysis: I personally have a strong preference for working on specific functionality, and I would encourage you to work with the code a bit, and let's fix things as specific pain points become clear. I realize that you are used to a different project structure, please understand that I'm used to what we have right now 🙂.

Kind regards, and thanks again for your feedback!

-Felix

[rbalet]

I think only the cost/benefit analysis make the difference here and I completely agree with you.
I'm closing the Issue for the moment :)