questions - folders restructure

[edenvidal]

@atulbhatt-system32 why do we have representation of the turn into inside the src and outside?

[edenvidal]

@atulbhatt-system32 is it possible to move this to where the cmdk menus are? (we no longer need the "ref" context, they can just live where they should)

[edenvidal]

@atulbhatt-system32 why do we need this?

[edenvidal]

@atulbhatt-system32 why do we need "pages/main" if there's just one page inside? and, can we somehow combine all of the things there to their area of concern? for example move cmdk stuff into common? then, i believe the mainpage.tsx can be combines with index.tsx (at the root)?

[edenvidal]

same questions for constants - do you believe they can live more contextually to where they affect and related mostly? hard for me to understand the different between global/index/main (global, index, and main are entering into a bar... oh! app decide to join too)

[edenvidal]

@atulbhatt-system32 i believe the content of this folder should live in the root and the folder shouldn't exist:

[edenvidal]

@atulbhatt-system32 for the sake of simplicity, i believe this can also be combine with what we decide as the macro context (root, index.tsx...)?

[edenvidal]

@atulbhatt-system32 same goes for main, global, index in here

[edenvidal]

@atulbhatt-system32 let's try to contextualize the (not so very) common components to where they are used.

• loader is not used in many places. it is used once. it is in once place, triggered sometimes. same goes for notifications, panelheader, etc.

[edenvidal]

@atulbhatt-system32 if we don't need "main" and "common" (and @stanislavasal is moving "canvas" into "stageview"), then we also don't need "components"

[edenvidal]

@atulbhatt-system32 same in redux, i believe combining things here will make our life easier too. would combine main with root and global. it'll all have one index and it'll be easy to maintain.

[edenvidal]

@atulbhatt-system32 same for global, index, main in here. would just have "index"? then, files and elements can live inside "nodes"? (btw nodes are great!!!)

[edenvidal]

@atulbhatt-system32 apparently, i can even imagine how everything inside "services" goes to their are of concern? lmk the limitations if any (combining global and main and app into "index" already feels natural to me at all levels)

[edenvidal]

@atulbhatt-system32 to summarize - i'd say everything can be much simpler, it feels like the global stuff can be defined as global stuff under the name "index" the specific stuff can live under the specific area, as much as possible.

[atulbhatt-system32]

@atulbhatt-system32 why do we have representation of the turn into inside the src and outside?

There are internal actions and external. The external ones are outside and internal ones are inside src.

[atulbhatt-system32]

@atulbhatt-system32 is it possible to move this to where the cmdk menus are? (we no longer need the "ref" context, they can just live where they should)

Sure we can move them where they make more sense. The project has evolved since these were all set. We will need to the update the imports wherever they are done!

[atulbhatt-system32]

@atulbhatt-system32 why do we need this?

I checked it and I think we had it to support different props passing via typescript. And @stanislavasal can do something about it or we can take AI help to improve this.

[atulbhatt-system32]

@atulbhatt-system32 why do we need "pages/main" if there's just one page inside? and, can we somehow combine all of the things there to their area of concern? for example move cmdk stuff into common? then, i believe the mainpage.tsx can be combines with index.tsx (at the root)?

Again this is the structure from the beginning and yes if there aren't going to be any more pages we can pull everything out and update the imports.

[atulbhatt-system32]

same questions for constants - do you believe they can live more contextually to where they affect and related mostly? hard for me to understand the different between global/index/main (global, index, and main are entering into a bar... oh! app decide to join too)

What we can do is have a single files instead of global and main both. But as some of the types are used in more than one place in the project it will be good to have then in a particular file instead of repeating there creation wherever they are needed.

[atulbhatt-system32]

@atulbhatt-system32 i believe the content of this folder should live in the root and the folder shouldn't exist:

yes following the same analogy of not having any other page, it can be done. But instead of root it should be inside src.

[atulbhatt-system32]

@atulbhatt-system32 same in redux, i believe combining things here will make our life easier too. would combine main with root and global. it'll all have one index and it'll be easy to maintain.

We can put global inside main and directly use it inside main reducer and then even pull out everything out of main and use directly in root.

[atulbhatt-system32]

@atulbhatt-system32 same for global, index, main in here. would just have "index"? then, files and elements can live inside "nodes"? (btw nodes are great!!!)

Sure it can be done. It's just a matter of preference.

[atulbhatt-system32]

@atulbhatt-system32 apparently, i can even imagine how everything inside "services" goes to their are of concern? lmk the limitations if any (combining global and main and app into "index" already feels natural to me at all levels)

There shouldn't be any limitation in simplifying or segregation here. Only imports will be required to be fixed.

[edenvidal]

@atulbhatt-system32 why do we have representation of the turn into inside the src and outside?

There are internal actions and external. The external ones are outside and internal ones are inside src.

@atulbhatt-system32, why is there a "turn into" in both internal and external?

[atulbhatt-system32]

@atulbhatt-system32 why do we have representation of the turn into inside the src and outside?

There are internal actions and external. The external ones are outside and internal ones are inside src.

@atulbhatt-system32, why is there a "turn into" in both internal and external?

@edenvidal the external one was there only for example but it is not used. So can be removed.

[edenvidal]

@atulbhatt-system32 @stanislavasal can we delete those?

[edenvidal]

@atulbhatt-system32 same in redux, i believe combining things here will make our life easier too. would combine main with root and global. it'll all have one index and it'll be easy to maintain.

We can put global inside main and directly use it inside main reducer and then even pull out everything out of main and use directly in root.

@atulbhatt-system32 @stanislavasal and then we can pull out everything out of _root and simply have the redux.

@atulbhatt-system32 which bring me to the following question about redux - isn't it even better to have the reducers live inside their are of concern (which is pretty straightforward)? or am i missing something and the coherency between them is higher than i think. i'd love a short and sweet explanation ❤️🙏

[edenvidal]

@atulbhatt-system32 do we need this? now that it runs on vercel

[edenvidal]

@atulbhatt-system32 , @stanislavasal ideally, this is how everything need to look like afrer we've carefully moved stuff, changed imports, and some files and imports names (i just discover vscode is helpful with that when doing it slowly) (i might missed the redux folder and the other build and environment files) lmk if it make sense

[atulbhatt-system32]

@atulbhatt-system32 @stanislavasal can we delete those?

No they are required!

[atulbhatt-system32]

@atulbhatt-system32 same in redux, i believe combining things here will make our life easier too. would combine main with root and global. it'll all have one index and it'll be easy to maintain.

We can put global inside main and directly use it inside main reducer and then even pull out everything out of main and use directly in root.

@atulbhatt-system32 @stanislavasal and then we can pull out everything out of _root and simply have the redux.

@atulbhatt-system32 which bring me to the following question about redux - isn't it even better to have the reducers live inside their are of concern (which is pretty straightforward)? or am i missing something and the coherency between them is higher than i think. i'd love a short and sweet explanation ❤️🙏

The folder architecture is done in the way it is done currently. You can keep it the way you want if it doesn't causes any conflict and is easily importable. But this is the way a developer expects all the stuff related to redux kept local to redux.

[atulbhatt-system32]

@atulbhatt-system32 do we need this? now that it runs on vercel

These are required by the development server and also by the build tools. This is independent of where you host your site.

[edenvidal]

@atulbhatt-system32 see the current folder restructure. wdyt?

[atulbhatt-system32]

@edenvidal looks good. Really reflects everything clearly in the way a person see things in the UI.