Unexpected route id inconsistency about remix HOT 10 OPEN

This is because of this result (note the dashboard is present twice):

I think the reason for this is, that in defineRoutes you don't overwrite everything starting from "root" and your dashboard/route.tsx is compatible with the default remix routing. So what happens is remix picks up the remix compatible dashboard/route.tsx and then adds your routing definitions on top.

The dashboard is not duplicated if you specify the id that remix would naturally generate. The only way I've found to opt-out of remix's default routing to still run is create a custom routes folder:

https://stackblitz.com/edit/remix-run-remix-mg5olc?file=vite.config.ts

from remix.

We should warn about this - the solution arrived at above is accurate - if you want to manually define child routes of an existing file-based parent route, you will need to specify the parent route with the same ID that Remix uses on the file-system.

But our code should be smart enough to warn/error if a dup route is found so you don't end up with 2 path="dashboard" routes in the tree.

Leaving this open so we can take a look. The check would likely make sense to do here if anyone wants to take a stab. We should be able to detect if we're about to add a config-based route that has the same parentId/path/index values as an existing route.

from remix.

You can use ignoredRouteFiles: ['**/*'] to ignore every file inside app/routes and then use the routes function to define your routes by hand.

from remix.

The route ID is the filename relative to app folder without the file extension.

from remix.

update NVM, it makes sense:

Wait, it actually makes sense. Just confusing that the example mixes (custom) folder logic.

routes/_index.tsx as file, equivalent folder would be routes/_index/route.tsx to the ID would be routes/_index for both.

previous post:
@kiliman I've created a reproduction that is a bit easier to use:

Remix DOC on ID: https://remix.run/docs/en/main/hooks/use-route-loader-data
Blitzstack: https://stackblitz.com/edit/remix-run-remix-mmhd6w

Maybe remix did there some BC break within non-major version, but as I've mentioned in react-flat-routes before and you verified, the ID is the path of the file, not the pathname (typically including the filename itself). The example in the docs just provides file a file route example, not using folders.

But it makes sense, that the same route, expressed differently, should have the same ID, right?

So app/routes/teams.tsx and app/routes/teams/route.tsx should have the same id: routes/teams, not routes/teams and routes/teams/route.

That means, which I agree feels a bit weird, a top level _index route should have an ID of "routes".

from remix.

I think the issue is you're using code to define the routes, here Remix infer the id from the file without the extension, the special route file inside a folder is not something that applies anymore since you could name your route file with any name because you're using code.

So yeah this routes/dashboard/child/route.tsx will become routes/dashboard/child/route because it just removed the extension, if you wanted to get routes/dashboard/child you can pass an id yourself by doing route('child', 'routes/dashboard/child/route.tsx', { id: "routes/dashboard/child" }).

For the default convention I expect the /route to not be included and I think it's what happens, but when using code that doesn't apply anymore.

from remix.

When switching back to default routing everything is consistent, which confirms sergiodxa's statement:
https://stackblitz.com/edit/remix-run-remix-1pd9fm

So when you make custom route handling, you need to make sure to keep the ID consistency and ensure that they are unique at the end - makes sense.

from remix.

This is the config with the explicit ids.

When you navigate to dashboard/child, the id is different that when navigating to dashboard.

from remix.

Yep, it looks like it. I think there should be a note on the docs to replace the whole tree to avoid this kind of issues,

from remix.

Do you think it might make sense to have an option to opt-out of remix default routing, so if someone wants to implement a custom solution there is no chance of accidentally leak remix logic into own implementation? Especially when there are changes in the future major releases. The error message is nice, but only triggers when the case is tested. When a future change adds new potential cases, someone would have to think it all through to figure out what can happen. With this is disabled for a custom routing, only evtl. API changes (hopefully typed) need to be addressed.

from remix.