Folder structure.

[n-igarashi]

env, asset, route, store etc.

Luan
Regarding to the folder structure in the template
I think we can learn a lot from folder structure of Amplify
We can use the monorepo pattern to store all common packages.
When starting new project, tech lead will choose which packages the project use.
https://github.com/aws-amplify/amplify-js/blob/main/packages

[mvn-luanvu-hn]

I think this folder structure is great https://maxrozen.com/guidelines-improve-react-app-folder-structure
Currently I'm following this folder structure.

[mvn-luanvu-hn]

Hi @jinmayamashita ,
I think the following structure can be used in case:
The JSX of a page is very large, so we want to split it into child components and these components are not needed to be reused in other pages.

|-- pages/
|   |-- UserProfile/
|   |   |-- Components/
|   |   |   |-- SomeUserProfileComponent/
|   |   |   |   |-- SomeUserProfileComponent.ts
|   |   |   |   |-- SomeUserProfileComponent.test.ts
|   |   |-- UserProfile.ts
|   |   |-- UserProfile.test.ts
|   |-- index.ts

[jinmayamashita]

@mvn-luanvu-hn B As you said, the advantage of having a child component is that it reduces the amount of code on the page.

However, I think there are some disadvantages to having a child component for a page 🤔

• More props relays to child component, so more maintenance costs
• It becomes difficult to grasp the whole components of application.

If you are using Atomic Design, you may want to use Organism. (even if it's a component that's used only on a specific page)

Example
(I've been trying to refactor the code of https://github.com/monstar-lab-oss/admin-panel-template-reactjs) 🙇

[mvn-luanvu-hn]

@jinmayamashita
Thanks for your opinions!
I have some feedbacks below

More props relays to child component, so more maintenance costs
It becomes difficult to grasp the whole components of application.

=> Yes, this is a disadvantage of having multiple child components.
But I have found that in some cases the large JSX of a component will make maintenance more complicated.
So there is a trade-off between multiple child components and a large JSX component.
It depends on context of each component, developers can choose which method is good for component.

If you are using Atomic Design, you may want to use Organism. (even if it's a component that's used only on a specific page)

=> Because in some cases child components of a page can not be reused in other pages, so I think we don't need to put child components into the folder src/components
Instead we put child components of a page into the page folder only

|-- pages/
|   |-- UserProfile/
|   |   |-- Components/
|   |   |   |-- SomeUserProfileComponent/                -> this component can not be reused in other pages
|   |   |   |   |-- SomeUserProfileComponent.ts
|   |   |   |   |-- SomeUserProfileComponent.test.ts
|   |   |-- UserProfile.ts
|   |   |-- UserProfile.test.ts
|   |-- index.ts

[yannde]

I assume the pages folder will include

• pageName.ts
• pageName.scss
• pageName.test.ts
• components/
• childPageName/
• routes?

[mvn-luanvu-hn]

@yannde
The above structure does not have the following sub-folders in the page folders

• childPageName/
• routes?

We can follow the structure of admin template which looks like your above idea.

[yukinoda]

If there's no specific folder structure preference, I think it would be good using the admin panel template's structure
so the dev experience when working with both admin panel template and this boilerplate in a project is the same.

[yannde]

@yukinoda @mvn-luanvu-hn
The admin panel groups a lot of the logic and screens together in the feature folder. That works as long as they follow the same structure, but that won't necessarily always be the case.

For the use of smaccs we can discuss that along with the styling

[mvn-luanvu-hn]

@yannde @yukinoda

The admin panel groups a lot of the logic and screens together in the feature folder. That works as long as they follow the same structure, but that won't necessarily always be the case.

I think we don't need this feature src/features/settings and use the rest of features

[mvn-luanvu-hn]

In addition should we use Redux? I think we can use useReducer or context.
They will support code splitting better to make features more modular and improve performance.

[n-igarashi]

@mvn-luanvu-hn

In addition should we use Redux? I think we can use useReducer or context.

I agree with you.
I am also interested in Recoil, but it is still in the experimental stage.
https://recoiljs.org/

[jinmayamashita]

@mvn-luanvu-hn We might not need Redux.
However, do we need to manage the state in global in the first place?

If the state you want to manage is the data fetched from the server we can consider using the server state lib such as React Query as we discussed in the MTG (We can use also React Context for only client state like application theme).

While most traditional state management libraries are great for working with client state, they are not so great at working with async or server state. This is because server state is totally different.
https://react-query.tanstack.com/overview

There are some advantages.

• Once the data is fetched, it is cached.
• Memoizing query results with structural sharing
• No need to keep track of the detailed status of the data retrieved from the server (loading, error status, etc.)

Codesandbox

[mvn-luanvu-hn]

@n-igarashi @yukinoda @yannde
I think we can make one more repository in addition to react/vue template repository like Amplify

In this repository we can put common packages like eslint rules, API, ... into it
And in the react/vue template repository we can import which common packages the template uses
I think this pattern will help us easily to share and upgrade common packages

I have made a little example here https://www.npmjs.com/package/@luanvuvt/eslint-config-react
And in the react/vue template we can import the common package like below

[mvn-luanvu-hn]

Hi,
I have just added another package named @luanvuvt/react-shared and put code of the feature permission of the admin template for demonstrating this monorepo structure
https://github.com/mvn-luanvu-hn/lerna-demo/tree/master/packages/react-shared/src

[n-igarashi]

@mvn-luanvu-hn

I think we can make one more repository in addition to react/vue template repository like Amplify

I agree with you.
I haven't had a chance to look at the samples yet, but I thought it would be a good idea to create a repository for common use.

[n-igarashi]

@mvn-luanvu-hn
I've added a new repository!
https://github.com/monstar-lab-oss/web-frontend-common-packages
Do you think this is a good name?

[mvn-luanvu-hn]

@n-igarashi

I've added a new repository!
https://github.com/monstar-lab-oss/web-frontend-common-packages
Do you think this is a good name?

I think it's OK 👍

[jinmayamashita]

@ptrkdan

Since there's still an ongoing discussion, I left a comment. 😄

In my experience, the structure based on /features modules in ML VN/JP, while common, often makes it challenging to grasp the functionalities provided by the application. 🤔

e.g.

• https://github.com/monstar-lab-oss/ml-frontend/tree/develop/src/features
• https://github.com/monstar-lab-oss/admin-panel-template-reactjs/tree/main/src/features

├── README.md
├── index.html
├── package-lock.json
├── package.json
├── src
|  ├── app.tsx
|  ├── components
|  |  ├── app-layout
|  |  |  ├── app-layout.tsx
|  |  |  └── index.ts
|  |  └── button
|  |     ├── button.tsx
|  |     └── index.ts
|  ├── features
|  |  ├── approval-status
|  |  |  ├── api
|  |  |  ├── components
|  |  |  |  └── approval-info-change-amount.tsx
|  |  |  ├── index.ts
|  |  |  ├── pages
|  |  |  |  ├── approval-list-search.tsx
|  |  |  |  └── approval-list.tsx
|  |  |  └── routes
|  |  |     └── approval-status.routes.ts
|  |  ├── not-found
|  |  |  ├── index.ts
|  |  |  ├── pages
|  |  |  |  └── not-found.tsx
|  |  |  └── routes
|  |  |     └── not-found.routes.ts
|  |  ├── reject-reasons
|  |  |  ├── api
|  |  |  ├── components
|  |  |  |  └── reject-history.tsx
|  |  |  ├── index.ts
|  |  |  ├── pages
|  |  |  |  └── reject.tsx
|  |  |  └── routes
|  |  |     └── reject-reasons.routes.ts
|  |  └── signin
|  |     ├── api
|  |     ├── components
|  |     |  ├── sign-in-fail.tsx
|  |     |  └── sign-in-form.tsx
|  |     ├── index.ts
|  |     ├── pages
|  |     |  └── signin.tsx
|  |     └── routes
|  |        └── signin.routes.ts
|  ├── main.tsx
|  ├── router.tsx
|  └── vite-env.d.ts
├── tsconfig.json
├── tsconfig.node.json
├── vite.config.ts
└── vitest-setup.ts

As projects become larger, it becomes more difficult to maintain an easy-to-understand structure, but surprisingly, this method seems to make it easier to maintain. (It also seems good to thoroughly review the naming of filenames and folder names.)

refs. https://www.joshwcomeau.com/react/file-structure/

As a suggestion, I've thought about the structure of the final generated boilerplate as follows, and I'd like to discuss it when you have time.

├── README.md
├── index.html
├── package.json
├── src
|  ├── app.tsx
|  ├── components
|  |  ├── app-layout
|  |  |  ├── app-layout.tsx
|  |  |  └── index.ts
|  |  ├── app-sidebar
|  |  |  ├── app-sidebar.stories.ts
|  |  |  ├── app-sidebar.tsx
|  |  |  └── index.ts
|  |  ├── button
|  |  |  ├── button.stories.ts
|  |  |  ├── button.styles.ts
|  |  |  ├── button.test.tsx
|  |  |  ├── button.tsx
|  |  |  └── index.ts
|  |  ├── table
|  |  |  ├── index.ts
|  |  |  ├── table.helpers.test.ts
|  |  |  ├── table.helpers.ts
|  |  |  ├── table.stories.tsx
|  |  |  ├── table.test.tsx
|  |  |  └── table.tsx
|  |  └── user-table
|  |     ├── index.ts
|  |     ├── use-data.ts
|  |     ├── use-remove-user.ts
|  |     ├── use-update-user.ts
|  |     ├── user-table.stories.tsx
|  |     ├── user-table.test.tsx
|  |     └── user-table.tsx
|  ├── helpers
|  |  ├── remove-keys.halpers.test.ts
|  |  └── remove-keys.helpers.ts
|  ├── main.tsx
|  ├── pages
|  |  ├── dashboard.tsx
|  |  ├── signin.tsx
|  |  └── users.tsx
|  ├── router.tsx
|  └── vite-env.d.ts
├── test
|  ├── mock-query-client-provider.tsx
|  └── vitest-setup.ts
├── tsconfig.json
├── tsconfig.node.json
└── vite.config.ts

[jinmayamashita]

Next action: Exploring ideas on where to place code with business domain logic. 🚀

[jinmayamashita]

@ptrkdan @seiya0914

It may be more of an issue with unclear component names than domain knowledge. 🤔
Could this be resolved by naming the components more explicitly to reflect their functions?

For example, with UserTable, it's not clear whether it represents a table that can manipulate users or just view them.

If specific actions (like editing, selecting, deleting) are possible, the following names could be considered:

• EditableUserTable: A table that allows editing of user information.
• InteractiveUserTable: A table that includes interactions with user (selection, filtering, etc.).

|  |  ├── editable-user-table
|  |  |  ├── index.ts
|  |  |  ├── editable-user-table.tsx
|  |  |  ├── hooks
|  |  |  |  ├── use-fetch-user.ts
|  |  |  |  ├── use-remove-user.ts
|  |  |  |  └── use-update-user.ts

[jinmayamashita]

I came to realize that it's difficult to completely eliminate the business domain. 😓
However, instead of focusing on the business domain, I tried focusing on the functionalities (not features).

https://github.com/jinmayamashita/farm-examples/blob/main/README.md

@ptrkdan @seiya0914
So what do you think of this structure?
I would appreciate it if you could review it and see if it could be applicable to a real project. 🤔

[ptrkdan]

@jinmayamashita cc: @seiya0914

Could this be resolved by naming the components more explicitly to reflect their functions?

This could be a possible solution, though you lose extensibility.
With your example above, if the requirements allow you to filter users in certain (not all) editable user tables, would that be a separate, EditableInteractiveUserTable component, would it be implemented under EditableUserTable, or would it be under InteractiveUserTable.
It may be possible if you're really careful of what you name your components, but I feel like it will only cause more headaches 🤔

I came to realize that it's difficult to completely eliminate the business domain. 😓
However, instead of focusing on the business domain, I tried focusing on the functionalities (not features).

https://github.com/jinmayamashita/farm-examples/blob/main/README.md

At first glance, it looks like a more reasonable idea! (Awesome acronym too 😅)
I think it's difficult to fully grasp its potential (and drawbacks) without actually applying it, so let me consider it a bit more 🙏

[jinmayamashita]

@ptrkdan

EditableInteractiveUserTable component, would it be implemented under EditableUserTable, or would it be under InteractiveUserTable.
It may be possible if you're really careful of what you name your components, but I feel like it will only cause more headaches 🤔

I agree with you. Striving for clear and careful naming is crucial, but it can certainly lead to more complications and discussions than initially anticipated 💢