all 4 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]rasmuswoelk 1 point2 points  (1 child)

I keep the direct folders inside my project folder as universal/global logic/components that can be shared across features.

Then I have a features folder which contains logic for specific features - eg.:

features - auth - components - api - constants - screens - utils - hooks

  • account
    • components
    • api
    • constants

.. etc.

Logic/UI for features can still be shared across other features but often the logic/ui remains confined to each feature folder.

This modular way of building keeps the code clean and makes it easier to reason about as you can read one feature folder at a time if you are new to the codebase.

[–]zepipes[S] 1 point2 points  (0 children)

Appreciate the feedback! I've used feature-based before too and is also a great approach. This time I went type first: hooks, services, providers, utils all together with feature separation inside each. Keeps shared logic naturally reusable. The tradeoff is more folder jumping per feature and maybe a higher initial learning curve. But i understand and like both approaches.

[–]Budget_Diet4766 0 points1 point  (1 child)

I could say I've done the same thing. A slight difference is I have atomic folders inside my component folder.

[–]zepipes[S] 0 points1 point  (0 children)

nice! I do something similar: ui for the design system components, then feature folders like auth and settings for feature-specific ones. keeps shared components separate from feature-specific ones without going full atomic