Colocation of Routes + Other Stuff in File Tree (components, utils, tests, etc...)

[jjhiggz]

Colocate Other Stuff With Your Routes

A feature request from a dev who is not disciplined about code structure 💡

Introduction

I didn't see a way for doing this in the docs, but it would be really awesome if there was a way to colocate components (or other non-route things like tests or utils) with routes. Route groups could be used in tandem with this...

Here's just an idea of what that could look like (% sign is being used to denote that nothing inside is a route )

- components
   // These would be "Everywhere" components
- utils
   // Everywhere utils
- routes
   (auth)
      - login.tsx
      - logout.tsx
      - join.tsx
      - %auth-utils // nothing inside of this folder is a route
        - hash-password.ts 
        - create-user.ts
      - %components // nothing inside of this folder is a route
        - login-form.tsx 
    (dashboard)
       - dashboard.tsx
       - %dashboard-stores // nothing inside of this folder is a route
          sidebar-store.ts
          active-window-store.ts
       - %dashboard-utils// nothing inside of this folder is a route
          ...

Why?

To me it feels like a top level components folder should be for your design system components (think a shadCN button, or a reusable input element, or something that is used everywhere). Without the ability to colocate route-specific components to their routes, I tend to place components build specifically for the /dashboard route in the high level components directory. I run into the same exact problem for utils, server fns, styles, schemas etc...

To combat this, what I usually do is just recreate the file/folder structure that's already in my router into my higher level folders. For example...

- components
   - dashboard/
     - dashboard-form.tsx
     - sidebar-button.tsx
     - sidebar-button.test.ts
- utils
  - dashboard/
     - do-some-string-thing.ts
     - do-some-string-thing.test.ts
     
- server-fns
  - dashboard/
      - get-some-entity.ts
      - get-some-entity.test.ts

Now I have 3 sources of truth that I have to maintain the integrity of my file system if I want to keep things organized as opposed to one. This requires discipline, and I'm terrible at discipline.

What I love about this new proposed pattern (the first example with %folder-name), is that much like Tanstack Router already does, it encourages the developer to make the simplest solution first, then work their way towards a structure that makes sense. Often when I make a button for a page, I'm not married to the notion that this Button is so great that I should put it everywhere on my app. As I start building more and more features, that's when I come to the conclusion of whether or not this is reusable in other places. I'd rather move a Button out of a localized scope and rename it, than be forced to put everything in a global scope.

In theory this could pair really nicely with an eslint plugin or something of the sorts. I can imagine a system that enforces (Don't import a component that's not from a parent scope), that way as I build I have a very clear strategy of adding new files to my codebase...

• start as deeply nested as you possibly can
• when your linter screams at you, move the scope outward

In theory this could give developers a much clearer idea of where their components are being used, and also probably make the codebase a lot more discoverable for newcomers to try and figure out which code is tightly coupled together.

Where/Who this is coming from

I've been working on a remix app for 2 years. Right now I'm the middle of switching to Tanstack Start , as it was either upgrade to V7 which would be a pain (I know because all other remix upgrades have been a pain), or just switch to something more alluring to me anyways (BTW Tanstack Start has been friggin' beautifully intuitive and well thought out so far). Even in porting from one framework to another, and literally copying over file by file, I still can't seem to settle on a folder structure that feels great (Maybe it's just a skill issue who knows). Ultimately it really doesn't matter that much as the sole developer because Typescripts' LSP is pretty amazing and I know my codebase pretty damn well, but it still irks me when I see the chaos.

For context of the scope of the project, here's a screenshot of it...

Conclusion

If there's no support for this I totally get it, I'm super appreciative of all the things this framework is solving. It really feels like y'all care deeply about the developer experience and I'm extremely grateful for it. TBH I'm a bit blown away how the alpha version already has:

• Amazing composability on server fns:
  • middleware (global, client, server)
  • validations
  • call from frontend or backend
• It's so easy to just dump a CDN in, or use a client only library
  • This was actually the nail in the coffin that made me switch I spent hours and hours trying to get React Tooltip, React Hot Toast, and iframe resizer to work and just decided that I could probably port all 40k lines of this thing over in two days (I'm actually pretty close to achieving that)
• The typesafety is genuinely mind boggling
• The context sharing is incredibly well done and intuitive

Anyways, I'm curious what y'all think about this! Thanks a bunch if you've made it this far ❤️

[schiller-manuel]

isn't this already possible via

• routeFileIgnorePrefix
• routeFileIgnorePattern

?

https://tanstack.com/router/v1/docs/framework/react/guide/file-based-routing#options

[jjhiggz]

oh no way!

Yup that makes sense! Gracias

[schiller-manuel]

so can we close this? or is something missing?

[jjhiggz]

yeah, sorry I'll do that now