Project Structure

[Diogo Mafra]

Description

Here we should choose which structure the project should follow. We need to carefully discuss things here in order to agree on something with great scalability.

My suggestion is:

/src
  /api
  /components
  /pages
  /routes
  /styles
  /types
  /utils

This is a project structure that isn't a domain-specific one. What does it mean? That we're not following a DDD approach on the frontend. Maybe we should think about something more focused like

/src
  /core
  /components
  /pages
  /utils
  /styles

Inside core we would have all modules separated by domain. An example of how this would work with Apolo's context.

/core
  /wallet
    /components
      /wallet
      /walletCard
    /pages
      /wallets
      /create-wallet
    /services
    /styles
    /utils

You must be thinking: "Why do you have components, pages, and utils outside core?" Because we have multiple components, pages, and utils that are not domain-related such as visual components and authentication pages.

What do you guys think about these 2 approaches? Which one is your favorite and you think scales better?

[Guilherme Luiz]

I can't see a long-term advantage into using the patterns bellow and it also looks odd to me 🤠 .

/core
  /wallet
    /components
      /wallet
      /walletCard
    /pages
      /wallets
      /create-wallet
    /services
    /styles
    /utils

I'd rather use the one you suggested @diogomqbm

[Paulo Henrique]

The first approach suggested by @diogomqbm (without the src/core folder structure) seems to be more suitable (with some caveats). The second approach looks very opinionated, redundant, and somewhat similar to atomic design. And I don't particularly like it, because it can generate a lot of discussion around the best composition of that src/core folder and can make the structure more confusing because of the folder redundancy. So, I agree with @GuilhermeLLS that this does not seem to be scalable.

Regarding the components structure, more specifically, in the Apolo project, we don't use any methodology for the component structure other than the component-page and component folders (src/pages and src/components). This is the simplest standard of structure (and I think the simpler and less opinionated, the better) which already comes by default in the most popular frameworks, such as Next.js and Gatsby.js. This simplicity comes from the fact that, actually, everything is a component.

In relation to the composition of the src/pages, src/components folders, we try to follow the idea which is based on to move files around until it feels right which exactly reflects our thought described by Dan Abramov in his tweet.