4 ms·

I'm a fan of feature oriented directory structures... Instead of... tests auth login.test.ts controllers auth login.ts

I'm a fan of feature oriented directory structures... Instead of... tests auth login.test.ts controllers auth login.ts components auth login.tsx ... You would have... feature auth login login.data.ts login.data.test.ts login.controller.ts login.controller.test.ts login.form.tsx login.form.test.ts ... That, in my opinion should include tests... You can have shared components, etc... or break up sub-projects.. but within a given project, I prefer features/concerns over class/data type. edit: In the above case, controller is really a higher order hook along with a higher order function component that will get call the hook, then pass the state to the separate component for render/events. If you're doing server components, may want something similar but different depending on architecture or out of the box structures.

pixelready 2y ago
It’s interesting. I always go back and forth on this pattern. It makes sense to me logically, but where do you put your shared utils and such?
- langarus 2y ago
  In a commons folder?
- moritzwarhier 2y ago
  Why not both? Move your pure function utilities to a feature-agnostic folder whenever it makes sense, and import them into your feature. I agree that's where the problems begin though :)
- tracker1 2y ago
  feature/shared/utils/foo.ts feature/shared/utils/format-date.ts feature/shared/ux/(template|region|etc)/foo.ts Where ux are for components that may be referenced in multiple areas, or generic templates, etc. and shared are for utility methods, functions, etc.
  - whalesalad 2y ago
    I think the op is asking more on if a util is used across many features
    - garrettgrimsley 2y ago
      tracker1 is saying that in that case there would be a feature named shared, which other features then reference.
      - tracker1 2y ago
        yes... though, unlike above, I might be inclined to name the directory "!shared" to pump sorting to the top, which may feel weird/awkward.
- diegoholiveira 2y ago
  IMO, shared utils must be a library, like: features auth login libraries dates strings ... I don't like to have a package / library called `utils`, `commons`, `shared` and other generic words that does not indicate me what's the context of this folder.
  - tracker1 2y ago
    Cool, may start using that over shared, but may just use "!lib" I tend to use "!" in the beginning of directories I want elevated... in any case, thanks.
desireco42 2y ago
Yes, this makes more sense, you have tests close to the code it test. Even integration tests should be somewhere in that hierarchy. At the time I was even thinking that tests should be part of the same file where the component or feature is implemented. There were ways to make this work, but it required a lot of configuration at the time.
- jackblemming 2y ago
  I don’t like seeing test files close to the code. It’s clutter and distracting. Some people do and that’s fair, but there’s no one way.
  - floydnoel 2y ago
    when i was working on java microservices a few years back at a major cruise line, the tests were of course in a completely separate folder structure. it would take ages to traverse the file tree. isn't that a major waste of time and really poor devex?
    - jackblemming 2y ago
      Your IDE should handle this kind of drudgery for you. The tests folder layout needn't be complex and deep either.
      - floydnoel 2y ago
        what about those of us who still prefer to use terminals, not just point and click GUIs? relying on ever-more tooling feels too much like putting a band-aid over the problem to me.
mmckelvy 2y ago
This is the way.
muzani 2y ago
This is my preferred structure. The shape of the code should represent what it's trying to do. Optimize for peripheral vision.
binarydreams 2y ago
What if a feature (auth page/module) has aspects that could be reused by other major features too, how/where would you place them?
- tracker1 2y ago
  Are they related to authentication and login? Reference them from their feature directory for what it is.

pixelready 2y ago

It’s interesting. I always go back and forth on this pattern. It makes sense to me logically, but where do you put your shared utils and such?

langarus 2y ago
In a commons folder?
moritzwarhier 2y ago
Why not both? Move your pure function utilities to a feature-agnostic folder whenever it makes sense, and import them into your feature. I agree that's where the problems begin though :)
tracker1 2y ago
feature/shared/utils/foo.ts feature/shared/utils/format-date.ts feature/shared/ux/(template|region|etc)/foo.ts Where ux are for components that may be referenced in multiple areas, or generic templates, etc. and shared are for utility methods, functions, etc.
- whalesalad 2y ago
  I think the op is asking more on if a util is used across many features
  - garrettgrimsley 2y ago
    tracker1 is saying that in that case there would be a feature named shared, which other features then reference.
    - tracker1 2y ago
      yes... though, unlike above, I might be inclined to name the directory "!shared" to pump sorting to the top, which may feel weird/awkward.
diegoholiveira 2y ago
IMO, shared utils must be a library, like: features auth login libraries dates strings ... I don't like to have a package / library called `utils`, `commons`, `shared` and other generic words that does not indicate me what's the context of this folder.
- tracker1 2y ago
  Cool, may start using that over shared, but may just use "!lib" I tend to use "!" in the beginning of directories I want elevated... in any case, thanks.

desireco42 2y ago

Yes, this makes more sense, you have tests close to the code it test. Even integration tests should be somewhere in that hierarchy. At the time I was even thinking that tests should be part of the same file where the component or feature is implemented. There were ways to make this work, but it required a lot of configuration at the time.

jackblemming 2y ago
I don’t like seeing test files close to the code. It’s clutter and distracting. Some people do and that’s fair, but there’s no one way.
- floydnoel 2y ago
  when i was working on java microservices a few years back at a major cruise line, the tests were of course in a completely separate folder structure. it would take ages to traverse the file tree. isn't that a major waste of time and really poor devex?
  - jackblemming 2y ago
    Your IDE should handle this kind of drudgery for you. The tests folder layout needn't be complex and deep either.
    - floydnoel 2y ago
      what about those of us who still prefer to use terminals, not just point and click GUIs? relying on ever-more tooling feels too much like putting a band-aid over the problem to me.

mmckelvy 2y ago

This is the way.

muzani 2y ago

This is my preferred structure. The shape of the code should represent what it's trying to do. Optimize for peripheral vision.

binarydreams 2y ago

What if a feature (auth page/module) has aspects that could be reused by other major features too, how/where would you place them?

tracker1 2y ago
Are they related to authentication and login? Reference them from their feature directory for what it is.