Eliminate the routes folder requirement

[dalelotts]

I love that routes are defined by convention in remix! Such a wonderful innovation.

However, I really dislike the package-by-type layout that comes along with this convention. It requires me to put unrelated files into the same folder. For example, the routes folder must contain the notes, login, logout and join files, but these files have nothing to do with each other, they are unassociated in every possible way, so why do they have to live together?

I'd like to suggest a project structure that locates all related files (CSS, TypeScript, JavaScript, images, tests, etc) together inside the same folder while continuing to use the directory structure to define the application routing.

Can we discuss using a file naming convention - rather than known folder names - to define routes, et al. By convention, name the file by what it is and put it anywhere you like. The following is an example for a notes app.

app
├── index.route.tsx
├── join.route.tsx   <--- could also be app/join/index.route.tsx
├── login.route.tsx
├── logout.route.tsx
├── notes
          ├── $noteid.route.tsx
          ├── note.tsx
          ├── user.unit-tests.tsx
          ├── user.e2e-tests.tsx
          ├── user.css
          ├── index.route.tsx   <--- index.route.tsx is the default component for a folder.
          ├── index.tests.tsx
          └── new
              ├── index.route.tsx   <--- Alternatively, this could be in the parent folder as new.route.tsx
              ├── new.css
              └── new.e2e-tests.js

This is a quick stab at a possible layout, I assume that I have missed some edge cases and the above is suboptimal.

The point is that remix can continue to determine the routes by looking for files named *.route.{js,jsx,ts,tsx}. Simple routes can remain the same, e.g. login.route.tsx and more complex entities can be grouped together into a folder. Just like it does now, the path to any *.route.{js,jsx,ts,tsx} is used to determine the routes for the app. Any folder that does not contain a *.route.tsx is not participating in routing.

Related changes to remix.config.js would allow the developer the freedom to group their code however they like. If they like grouping by type (as it is now) the following config will work - this would be the default config so this is not a breaking change.

module.exports = {
  // ...
  routeFiles: ["./routes/**/*.{js,jsx,ts,tsx}"], 
  e2eRouteFiles: ["cypress/support/test-routes/**/*.{js,jsx,ts,tsx}"], 
  // ...
};

and if the developer prefers something like the suggestion above, the following config could be used:

module.exports = {
  // ...
  routeFiles: ["**/*.route.{js,jsx,ts,tsx}"], 
  e2eRouteFiles: ["**/*.test-route.{js,jsx,ts,tsx}"], 
  // ...
};

[kiliman]

Remix already provides a way to define your own routes. The routes folder is just a convention. You are free to define routes outside of the routes folder.

Just use the provided feature to generate your own convention.

https://remix.run/docs/en/v1/api/conventions#routes

[dalelotts]

@kiliman my apologies for my earlier deleted comment and for taking so long to apologise. It won't happen again.

[kiliman]

@dalelotts No problem. We're good. If you need help creating a function to use your own routing convention let me know.

[dalelotts]

@kiliman I appreciate your understanding and the offer to help. Project structure is on the back burner for now. I'm working through how to get react-three-filber & drei to display an equirectangular image and not dump errors about SSR or outright crashing with "Cannot read properties of undefined (reading 'root')"... so much to learn!

[kiliman]

I would wrap the D3 stuff in <ClientOnly/> component from remix-utils.

https://github.com/sergiodxa/remix-utils#clientonly

[dalelotts]

I was about to start down that path, then I read this comment on the discord help channel.

I'll give <ClientOnly/> a try.

[sergiodxa]

You could use this https://remix.run/docs/en/v1/api/conventions#ignoredroutefiles to ignore any file inside routes without the .route.tsx extension, then you will be able to put any other file inside your routes folder.

[dalelotts]

I actually tried that before starting this discussion. It sort-of works. I have no idea if it will work with the models folder in the Grunge template.

However, I still have to have everything in the the routes folder if I do that. Code should communicate intent - the routes folder communicates the intent that is should hold routes, right? This is a bit of an anti-pattern and already has lead to other type specific folders like models, maybe hooks is next.

It's promoting a pattern of organization that is suboptimal in almost every circumstance. Other than the routes folder remix seems to be by far the best way to build websites. Having this limitation, which is possible to remove, makes it just a bit ugly. It's like having a beautiful, amazing Bugatti Chiron where one of the wheels is a temporary spare tire.

I guess I'm alone on this opinion. 🤷🏽‍♂️

[kiliman]

Hi @dalelotts

You should take a look at the new flat routes convention, especially the nested-flat routes. This is pretty close to the layout you wanted.

https://github.com/kiliman/remix-flat-routes

[dalelotts]

Wow, looks pretty good. A bit more flat than what I had in mind but worth a try.

[drewdecarme]

Wow I actually love this

[sergiocarneiro]

Hi @dalelotts,

In your ideal convention, where do you suggest to put the files shared across multiple routes?

Components, styles, hooks, models, types, services, utilities, integrations, ...

[dalelotts]

Well, the examples use the "group-by-type" approach and you don't give any concrete examples, and I have not used the group-by-type in at least 10 years so I'm probably not going to be able to map the locations in any reasonable way.

However, I'll try to add a bit more detail:

Imagine I have a shared Menu component that is displayed in a shared header component.

In group-by-type it may look this:
app/components/menu/index.js has the menu (or however you would name it) and app//components/header/index.js has the header that uses the menu.

I would do the following:
app/header/index.js contains the header component and app/header/menu.js contains the menu component. These two components are closely related (married if you will) so they should live together. Anything else, including styles, etc that are related to the shared header would go in the same folder.

Integrations are tests - they are testing one thing to make sure that thing integrates into the system correctly - therefore the integration tests live in the same folder as the thing under test - this is true for all tests.

Models is a good example of how "group-by-type" is problematic - for the most part, two models never talk to each other, never interact, never exchange messages, so why are they in the same folder. It's like living with someone that you never see and never talk to, but they have their stuff sitting in the middle of the living room. Why?

Now for something a bit more controversial, utilities are, IMO, a design failure. I have yet to see a utility file that followed SOLID, Law of Demeter, or most other reasonable design approaches. It's usually more of a "junk drawer" than something with intentional well defined design. So, as a result, I don't do this.

In short, thing that exchange messages often, or are otherwise closely related, all go in the same folder. Where are the components, styles, tests, etc related to what is displayed in the footer? In the footer folder, of course. Or would you rather say they are spit up with parts located in the Components, styles, hooks, models, types, services, utilities, integrations, ... folders?

[sergiocarneiro]

I'm not looking at any approach rather than the one you're suggesting, just trying to understand where you would put the categories I mentioned. You may not have the folder "hooks", but you surely need to have them somewhere.

So what happens if you want to have a hook that is both used in header and footer?

Same goes to all types of shared logic.

[dalelotts]

The short answer is, as always, "it depends". The slightly longer answer is the code is organized primarily by feature, route, or even purpose rather than by type.

So, Imagine there is a useTimout hook that works like setTimeout and is used in both the header and footer and perhaps even other places. It would likely be in app/useTimout/index.js or even app/useTimout.js since it really doesn't have any collaborators or dependencies.

Google is a good source for more research: here are a few example articles that I found by searching for react project structure or package-by-feature:
https://reactjs.org/docs/faq-structure.html
https://www.techyourchance.com/popular-package-structures/
https://proandroiddev.com/package-by-type-by-layer-by-feature-vs-package-by-layered-feature-e59921a4dffa
https://www.robinwieruch.de/react-folder-structure/

[sergiocarneiro]

I don't see a need to pick one approach over another. I personally use a combination of different approaches and is what works best.

The Popular Package Structures article you provided also says the Package By Feature will still required Package By Screen to be implemented, as features do not have screens. The example given is using the top-level folder screens, which in Remix is routes.

None incentivize top-level file pollution, and you should avoid that. You already have a lot of learning material to go through that can answer that.

To summarize and for the scope of this discussion, I don't think Remix is preventing any approach to be implemented the right way.

[dalelotts]

Yep, @kiliman, et al, made it clear that Remix is not preventing any specific approach.