Optimize file structure of Bliz.js

[ivanjeremic]

Hi, I'm new to Blitz but one thing that I saw where I think this can be done cleaner is how the generated files are structured.

When I run in my Blitz app blitz generate all projects I get a file structure like this.

📦app
┣ 📂api
┃ ┗ 📜.keep
┣ 📂auth
┃ ┣ 📂components
┃ ┃ ┣ 📜LoginForm.tsx
┃ ┃ ┗ 📜SignupForm.tsx
┃ ┣ 📂mutations
┃ ┃ ┣ 📜changePassword.ts
┃ ┃ ┣ 📜forgotPassword.test.ts
┃ ┃ ┣ 📜forgotPassword.ts
┃ ┃ ┣ 📜login.ts
┃ ┃ ┣ 📜logout.ts
┃ ┃ ┣ 📜resetPassword.test.ts
┃ ┃ ┣ 📜resetPassword.ts
┃ ┃ ┗ 📜signup.ts
┃ ┣ 📂pages
┃ ┃ ┣ 📜forgot-password.tsx
┃ ┃ ┣ 📜login.tsx
┃ ┃ ┣ 📜reset-password.tsx
┃ ┃ ┗ 📜signup.tsx
┃ ┗ 📜validations.ts
┣ 📂core
┃ ┣ 📂components
┃ ┃ ┣ 📜Form.tsx
┃ ┃ ┗ 📜LabeledTextField.tsx
┃ ┣ 📂hooks
┃ ┃ ┗ 📜useCurrentUser.ts
┃ ┣ 📂layouts
┃ ┃ ┗ 📜Layout.tsx
┃ ┗ 📂styles
┃ ┃ ┗ 📜index.css
┣ 📂pages
┃ ┣ 📂projects
┃ ┃ ┣ 📂[projectId]
┃ ┃ ┃ ┗ 📜edit.tsx
┃ ┃ ┣ 📜[projectId].tsx
┃ ┃ ┣ 📜index.tsx
┃ ┃ ┗ 📜new.tsx
┃ ┣ 📜404.tsx
┃ ┣ 📜_app.tsx
┃ ┣ 📜_document.tsx
┃ ┣ 📜index.test.tsx
┃ ┗ 📜index.tsx
┣ 📂projects
┃ ┣ 📂components
┃ ┃ ┗ 📜ProjectForm.tsx
┃ ┣ 📂mutations
┃ ┃ ┣ 📜createProject.ts
┃ ┃ ┣ 📜deleteProject.ts
┃ ┃ ┗ 📜updateProject.ts
┃ ┗ 📂queries
┃ ┃ ┣ 📜getProject.ts
┃ ┃ ┗ 📜getProjects.ts
┗ 📂users
┃ ┗ 📂queries
┃ ┃ ┗ 📜getCurrentUser.ts

We generate inside the app a folder projects and under app/pages also, why not have a folder called 'data' under 'app' where the 'projects' folder, for example, is generated and this folder holds not only components, mutations, queries but also the routes/pages this way every data model created has a central place which holds everything from mutations & queries to the pages/routes it is up to the framework later to merge them correctly. This is I think it could look.

📦app
┣ 📂api
┃ ┗ 📜.keep
┣ 📂auth
┃ ┣ 📂components
┃ ┃ ┣ 📜LoginForm.tsx
┃ ┃ ┗ 📜SignupForm.tsx
┃ ┣ 📂mutations
┃ ┃ ┣ 📜changePassword.ts
┃ ┃ ┣ 📜forgotPassword.test.ts
┃ ┃ ┣ 📜forgotPassword.ts
┃ ┃ ┣ 📜login.ts
┃ ┃ ┣ 📜logout.ts
┃ ┃ ┣ 📜resetPassword.test.ts
┃ ┃ ┣ 📜resetPassword.ts
┃ ┃ ┗ 📜signup.ts
┃ ┣ 📂pages
┃ ┃ ┣ 📜forgot-password.tsx
┃ ┃ ┣ 📜login.tsx
┃ ┃ ┣ 📜reset-password.tsx
┃ ┃ ┗ 📜signup.tsx
┃ ┗ 📜validations.ts
┣ 📂core
┃ ┣ 📂components
┃ ┃ ┣ 📜Form.tsx
┃ ┃ ┗ 📜LabeledTextField.tsx
┃ ┣ 📂hooks
┃ ┃ ┗ 📜useCurrentUser.ts
┃ ┣ 📂layouts
┃ ┃ ┗ 📜Layout.tsx
┃ ┗ 📂styles
┃ ┃ ┗ 📜index.css
┣ 📂data
┃ ┗ 📂projects
┃ ┃ ┣ 📂components
┃ ┃ ┃ ┗ 📜ProjectForm.tsx
┃ ┃ ┣ 📂mutations
┃ ┃ ┃ ┣ 📜createProject.ts
┃ ┃ ┃ ┣ 📜deleteProject.ts
┃ ┃ ┃ ┗ 📜updateProject.ts
┃ ┃ ┣ 📂pages
┃ ┃ ┃ ┣ 📂[projectId]
┃ ┃ ┃ ┃ ┗ 📜edit.tsx
┃ ┃ ┃ ┣ 📜[projectId].tsx
┃ ┃ ┃ ┣ 📜index.tsx
┃ ┃ ┃ ┗ 📜new.tsx
┃ ┃ ┗ 📂queries
┃ ┃ ┃ ┣ 📜getProject.ts
┃ ┃ ┃ ┗ 📜getProjects.ts
┣ 📂pages
┃ ┣ 📜_app.tsx
┃ ┣ 📜_document.tsx
┃ ┣ 📜404.tsx
┃ ┣ 📜index.test.tsx
┃ ┗ 📜index.tsx
┗ 📂users
┃ ┗ 📂queries
┃ ┃ ┗ 📜getCurrentUser.ts

It is similar to the way the already existing auth folder is structured and like I said I'm new to blitz and the current generate cli command always puts pages inside the default pages directory and it does not structure it like the auth folder which is the perfect way because it makes everything cleaner, maybe there is an cli option I'm not aware of so correct me if I'm wrong. Thanks

[MrLeebo]

I don't think this proposal is an improvement. To begin, there is a mistake in the proposed folder structure,

-/data/projects/pages/[projectId].tsx
+/data/projects/pages/projects/[projectId].tsx

You need to have the resource folder after /pages because the folders before it won't be part of the URL route. All of your resource pages would conflict with each other. This creates a redundancy, because projects appears in the path twice. That is why the pages are organized the way they are, and also to better represent the relationship between nested resources (e.g. Project has many Tasks).

auth is different, all of the auth pages sit at the application root and won't conflict with non-auth pages. I don't think you should use it as a template for resources.

I don't see value in inserting a folder called data into the folder structure. It's just one more folder to click past before you get to the code. Also, data would be an overloaded term in this context. I'd expect a "data" folder to contain CSVs of domain/seed data, not application module code. If you want to keep all of your module code inside a central folder, I'd suggest core over data, but personally I'd do without.

[ivanjeremic]

I don't think this proposal is an improvement. To begin, there is a mistake in the proposed folder structure,

-/data/projects/pages/[projectId].tsx
+/data/projects/pages/projects/[projectId].tsx

You need to have the resource folder after /pages because the folders before it won't be part of the URL route. All of your resource pages would conflict with each other. This creates a redundancy, because projects appears in the path twice. That is why the pages are organized the way they are, and also to better represent the relationship between nested resources (e.g. Project has many Tasks).

auth is different, all of the auth pages sit at the application root and won't conflict with non-auth pages. I don't think you should use it as a template for resources.

I don't see value in inserting a folder called data into the folder structure. It's just one more folder to click past before you get to the code. Also, data would be an overloaded term in this context. I'd expect a "data" folder to contain CSVs of domain/seed data, not application module code. If you want to keep all of your module code inside a central folder, I'd suggest core over data, but personally I'd do without.

It is less about if the folder is called 'data' or not even if there is no folder at all still fine, the main point is to have the pages inside the same folder where also the queries and mutations are generated.

[flybayer]

It is less about if the folder is called 'data' or not even if there is no folder at all still fine, the main point is to have the pages inside the same folder where also the queries and mutations are generated.

We actually started out with this approach, but then changed. See #1694 for the context behind the change.

That said, I think we can add a config option that allows users to opt into this behavior. I converted this issue into a discussion, but if you are good with adding a config option, then please open a new issue specifically for that. :)