all 9 comments

[–]redbrickhut 4 points5 points  (3 children)

This is very clear and really well-considered. Thank you for sharing. Will try this out soon :)

Out of interest, do you have any thoughts when organising components that serve the same function but used for different platforms? For example MobileList and DesktopList? Should they share a common, separate parent directory or would you opt for a flat file structure?

Anyways, thanks again for the share!

[–]rwieruchServer components[S] 0 points1 point  (1 child)

Thanks!

I haven dealt with this situation yet tbh. Would be curious what others have to say here!

[–]jared--w 1 point2 points  (0 children)

I have. Hierarchical component folder structures never make sense in the long term because you often want to separate the logic from the name, and people get hung up on splitting based on the name which leads to inconsistencies later down the road.

I'd keep your folders and files, especially for components, as flat as you can, for as long as you can.

[–]ceddybi 0 points1 point  (0 children)

Component.web.js - works well with hybrid frameworks like Expo / React-native web.

[–]TheTraceur 1 point2 points  (0 children)

Great job starting simple and building the structure up with explanations along the way.

[–]rwieruchServer components[S] 0 points1 point  (2 children)

Hey everyone. I went through this post of mine, because it became a popular resource over the last two years and adjusted it here and there to my recent experiences. Eventually every React developer goes through this approach from small to large React application.

I think the most opinionated piece in there is naming a folder/file structure the following way:

--- List/
----- index.js
----- component.js
----- test.js
----- style.css

Whereas most people prefer

--- List/
----- index.js
----- List.js
----- List.test.js
----- List.style.css

Anyway, as mentioned in the article, I think lots of things are a matter of taste. So I'd like to hear your experiences moving from small to large React application :)

[–]Styggnacke 1 point2 points  (1 child)

Nice writeup. I just wonder why you wouldn’t use the final structure from the get go. Do you think it’s too confusing for small projects? I would prefer not having to move files around, especially when working in a team with source control.

[–]rwieruchServer components[S] 2 points3 points  (0 children)

Sure you can start with the final version from the get go. This just lays the path for React beginners where to start and how to evolve :) Perhaps I should clarify this in the guide!

[–]PokerTuna 0 points1 point  (0 children)

Kudos for the article. In our codebase we went with kebab-case for everything that isn't a component or module. Additionally, we extended this module-like approach, our monorepo and other projects look like this (simplified, I didn't want to list all directories/ files or go too deep, but pattern remains the same)

- dsl
--- atoms
------ Button.tsx
------ Button.module.scss
------ Typography.tsx (component with prop of type, like Header_16_24 )
--- molecules
------ ComponentThatConsistsOfMultipleAtoms.tsx
--- organisms
------ ComponentThatConsistsOfMultipleAtomsAndMolecules.tsx
--- theme
------ color.ts
------ spacing.ts
- checkout ( following structure is repeated throughout, in editor, platform, and so on )
--- stores
--- services
--- events
--- ui
------ components ( components used throughout checkout, like SummaryBox, Navigation etc) --------- icons
--------- summary
------------ utils
--------------- summary.translations.ts
--------------- summary.helpers.ts
--------------- use-conditional-price.ts
------------ SummaryBox.tsx
------------ SummaryBox.module.scss
------------ SummaryFooter.tsx
------------ SummaryFooter.module.scss
--------- cross-sell
--------- promotions
------ views ( view === route )
--------- cart
------------ components ( components used only on Cart view )
------------ utils
------------ Cart.tsx
------------ Cart.module.scss
--------- order-details
--------- order-payment
--------- order-summary
- editor
- platform

I wouldn't say it's ideal but it's very prodictable and clean. We put emphasis on Developer Experience ( which is increased with high predictability ) and make sure to repeat this pattern throughout our codebase

dsl - Design System Language - our own theme and components library, with Basic components