Best practices for directory-based routing with lots of non-route files

[alexkatz]

Hi,

Loving the library so far. I'm thinking of trying it out in a portion of one of my company's mid-sized and internal enterprise SPAs, and possibly migrating the entire thing over eventually if it works out.

I'm struggling to picture what a large directory-based project structure looks like, though. I tend to group by feature, and I can't seem to find a satisfying way to have route and non-route files coexist.

Ideally, I'd like to have a routes/ directory like this:

__root.tsx
route.tsx
accounts/
  route.tsx
  utils.ts
  useSomeAccountsHook.ts
  constants.ts
reports/
  route.tsx
  useSomeReportsHook.ts
  utils.ts

Is there a way to have tsr detect only the route.tsx files (in addition to __root.tsx) and ignore the other files?

The routeFilePrefix config option almost works if set to "route", but it forces this prefix to be applied to directories as well, and breaks if accounts/ is not renamed routeaccounts/, for example.

I'd prefer not to use the routeFileIgnorePrefix option, as the vast majority of files in this directory would be unrelated to routing and an intrusive prefix would appear everywhere.

Is the best option to simply not house feature directories within routes/?

Edit: It seems something like a routeFileIncludePattern option with a value like "((route|__root).tsx)" would do the trick, given it applies to files but not directories. I'd happily contribute toward such functionality.

For now I am using the ~ character as a prefix:

~__root.tsx
~route.tsx
~accounts/
   ~route.tsx
   utils.ts
   useSomeAccountsHook.ts
   constants.ts
~reports/
   ~route.tsx
   useSomeReportsHook.ts
   utils.ts

[alexkatz]

Ultimately I decided to keep my /routes directory flat, and stick with this type of approach, which seems more of the Tanstack Router way:

accounts/
  utils.ts
  useSomeAccountsHook.ts
  constants.ts
reports/
  useSomeReportsHook.ts
  utils.ts
routes/
  __root.tsx
  accounts.tsx
  reports.tsx

And I've set up Typescript import aliases to allow statements like import useSomeAccountsHook from '@/accounts'. This flattened style of organizing by feature is nice. I'm really enjoying this setup as I port more routes over.

[manuel-mauky]

I'm having the same "issue" and in the end I came to the same conclusion like you to use a separate directory structure for the actual features and keep the routes in another directory but I'm not really happy with this. That way, features are not really self-contained - you always have to also look into the routes directory.

I would like to configure it so that only files with route.tsx name are considered and all other files are ignored.

Instead of the routeFilePrefix I'd like to have a routeFileSuffix or something like that and without having to rename the directories themself.

[alexkatz]

Yeah I’d still love a setup like that.

These days, to make things as feature-directory-like as possible, I minimize what’s in the actual route files. I limit each file to only the exported route and its lifecycle methods — importing even its component from its corresponding feature folder.

The downside to this is the inability to use the Route instance within the component, but that’s easy enough to do in a type safe way wherever you need via getRouteApi.

[Misaka-0x447f]

A library may shouldn't limit how people use that... If library developers wants to enforce something, it is okay to enforce by default but please keep a switch -- not every project will be really large that requires such enforce.