[question / discussion] how to maintain makeRoutes.tsx

[xela92]

Hi,

In your idea, what's the correct way for the user to maintain makeRoutes.tsx file?

Few minutes ago I was having a issue with declarative-routing (initialized few days ago) that you just fixed yesterday here

I didn't have this change locally because, as you clearly stated, you want this to become a user-owned routing system and so the makeRoutes file is a copy made on init. It took me a bit to realize that the fix was made in a non-self-updating file, checking your latest commits, and I thought it was not so straight forward.

We may need a way to properly notify about important fixes / enhancements in order for the user to take action. What do you think?

Thanks

[jherr]

That's an interesting question. How does shadcn do it? Although, that being said, the shadcn component files are way smaller than makeRoute. We could put a version number at the top of the makeRoute file.

[jherr]

Another option would be to move a lot of the logic of makeRoute into this package and publish it as a more traditional library as well. Add that as a dependency as part of the init process. Then reduce the size of makeRoute substantially and have it be more like a configurator. For example, it could be a two line change to go from <ProductDetail.Link ... > to <ProductDetail ... > and to move the URL creator from ProductDetail() to ProductDetail.url() or something like that. Which is the kind of stuff I see as the primary reason to alter makeRoute in the first place.

[xela92]

That's an interesting question. How does shadcn do it? Although, that being said, the shadcn component files are way smaller than makeRoute. We could put a version number at the top of the makeRoute file.

I can see they offer a command to manually diff

The coolest option I see without shifting the approach is:

• a "check" command, that prints a message (like npm does) if a new version is available
• a "diff" command
• a "apply" command to merge it (if possible)

The user may then decide to add the check command to the dev script in order to get notified of new changes it may take advantage of.

Another option would be to move a lot of the logic of makeRoute into this package and publish it as a more traditional library as well. Add that as a dependency as part of the init process. Then reduce the size of makeRoute substantially and have it be more like a configurator. For example, it could be a two line change to go from <ProductDetail.Link ... > to <ProductDetail ... > and to move the URL creator from ProductDetail() to ProductDetail.url() or something like that. Which is the kind of stuff I see as the primary reason to alter makeRoute in the first place.

In my view, it depends on the customization trade-offs; the coolest part of a customizable, user-owned routing management is that the effort to move away from the routing system should be very low (speaking for the "react mode" of course).
I would need to update the components used in makeRoutes.tsx and bind the new routing system to my app and I should be good to go; moving away from the copy-paste approach would mean to create a super factory, fully customizable for the user needs, and that's great until freedom is granted and UX stays awesome.

Also, it would be a nice future improvement to support the hot plug of any validation library, and right now it's not so hard to make the necessary changes to do this; so I think it should be taken in account if the lib changes approach in this direction.

Let me know what you think 👍

[jherr]

The check command seems like a good compromise. Though, given that apparently it's now incompatible with RSCs in 14.2 and needs major refactoring to get there, the "check" would be a big diff.

There is an issue for hot-swapping Zod if you want to +1 that. Or take it on. :)