Hacker News Reader

Comment by tracker1 | Hacker News Reader

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.

View on HN

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?

In a commons folder?

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 :)

    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.

I think the op is asking more on if a util is used across many features

tracker1 is saying that in that case there would be a feature named shared, which other features then reference.

yes... though, unlike above, I might be inclined to name the directory "!shared" to pump sorting to the top, which may feel weird/awkward.

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.

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.

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.

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.

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?

Your IDE should handle this kind of drudgery for you. The tests folder layout needn't be complex and deep either.

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.

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

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

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

This is the way.

Reply on news.ycombinator.com