Open DysektAI opened 2 months ago
- Background: historically it's (was?) a CRA convention. In the code when importing you reference components by their folder name, never by the js file, and then i_dont_know_who_specificaly will look for the index.js file inside and the exported parts in it.
I wasn't familiar with this older CRA convention either. Understanding this helps clarify why it was done that way.
Referencing imports by the js file is a relatively new thing required by ECMAScript.
I've heard about the need for explicit extensions with ECMAScript, but haven't needed to implement it in my project, which still runs smoothly without specifying .js or .jsx extensions. (I did have issues when using package.json type: module
removing it fixed a lot of the issues but to use Vite it was required and still don't see any issues maybe my ESLint isn't configured correctly)
Because we recently migrated to ECMAScript it can be useful to also migrate the naming convention 👍 Discussion points:
- Should the folder be renamed too or the file named as folder?
I typically organize components like 'settings' under src/components/settings/
and then import them into src/pages/settings.jsx
for rendering. This setup works well for my /settings route as I can add and remove components easily or simply edit those components in their respective files if needed.
- Do we need a folder if we only have the jsx file inside (without CSS)?
For components using inline styling, especially with frameworks like MUI that use the sx prop, external CSS files aren't necessary. However, for those that do have associated CSS, structuring folders like this could be more organized:
/src
/components
/BarterTooltip
BarterTooltip.jsx
/styles
/BarterTooltip
BarterTooltip.css
- Background: historically it's (was?) a CRA convention. Totaly should be done moving forward 👍
Once the above are addressed at least for the most part, it would be beneficial to move forward with implementing Vite.
Switching to Vite would streamline workflow, significantly reduce server startup times and improve build speeds with efficient Hot Module Reloading (HMR).
Overall, transitioning to a clearer structure and simplifying the codebase will enhance the development process greatly.
@DysektAI I'll say that if you want to take on the monumental effort to rename all react components from js
to jsx
go for it 👍
This will prepare us better for when we are ready to switch to Vite or Next.js
1.) There are a LOT of "index.js" files being used to define components as I never seen this before in my time of using react unless using index.js to import multiple components into one file for easier use and access here is the best resource I found that explains this:
2.) Properly use .js and .jsx as explained below which currently is mostly .js extensions in the project. (The reason why this isn't an apparent issue when using CRA is because it uses webpack and babel under the hood to handle these files no differently)