Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Utility/Includes patterns #40

Open
kaisermann opened this issue Jan 30, 2020 · 3 comments
Open

Utility/Includes patterns #40

kaisermann opened this issue Jan 30, 2020 · 3 comments
Labels
documentation Improvements or additions to documentation practices/patterns

Comments

@kaisermann
Copy link
Contributor

kaisermann commented Jan 30, 2020

Is your feature request related to a problem? Please describe.

We should have a recommended way of organizing includes/utilities in our projects. I've seen some variations of:

  • A utils directory with a single index.ts file (doesn't make sense to me at all)
  • A modules/includes/utils directory with separate files with default exports

Describe the solution you'd like

I'd like to have a recommended way of adding utilities to a project. Personally I dislike creating a lot of folder structure with complex names, so I usually prefer a includes/modules directory with a file for each utility context or for each method. I also dislike having them exported as default since the name can be easily changed wherever they're imported.

Example:

src/runtime/
├── includes/
│   ├── flatObj.ts
│   ├── formatters.ts
│   ├── getClientLocale.ts
│   ├── loaderQueue.ts
│   ├── lookup.ts
│   └── memoize.ts

Or

src/runtime/
├── modules/
│   ├── flatObj.ts
│   ├── formatters.ts
│   ├── getClientLocale.ts
│   ├── loaderQueue.ts
│   ├── lookup.ts
│   └── memoize.ts

Describe alternatives you've considered

Additional context

@kaisermann kaisermann added documentation Improvements or additions to documentation practices/patterns labels Jan 30, 2020
@tiagonapoli
Copy link

tiagonapoli commented Jan 30, 2020

I prefer not to use default exports as well:
https://basarat.gitbook.io/typescript/main-1/defaultisbad

And I liked the idea of using includes for utilities

@klzns
Copy link
Contributor

klzns commented Jan 30, 2020

Why modules

I really like the name modules for this type of.... modules.

src/
└── modules/
    ├── flatObj.ts
    ├── formatters.ts
    ├── loaderQueue.ts
    ├── lookup.ts
    └── memoize.ts

The idea here is that any module inside this folder might be one day a npm package. So the mindset is that each module must have a clear API and specific domain to solve.

This pattern is used by developers of react-router.

Why not utils

When one uses the name utils this mindset and constraints are not clear. It's pretty common to see something like:

src/
└── utils/
    ├── CartUtils.ts
    └── CurrencyUtils.ts

And the developers add new functions to this files ad hoc.

@guilhermebruzzi
Copy link
Contributor

On inStore we are trying to do:

src/
└── cart/
    ├── components
    ├──  actions.ts
    ├──  ...
    └── utils.ts
└── /
    ├── components
    ├──  actions.ts
    ├──  ...
    └── utils.ts

It's like the modules idea that @klzns said but with folders on the root

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation practices/patterns
Projects
None yet
Development

No branches or pull requests

4 participants