Tanstack Router

[JuicyBenjamin]

I am only minimally familiar with tanstack router and have not used it myself in any project, yet. However I am very aware of all the benefits having a type safe router. In fact in a way Refine attempted to solve this by having a predetermined for how to structure routes, with :id params for example that should always represent the current resource item. While this pattern is extremely useful, and arguably one of the things that make useful, it is at times a bit naive.

I've previously opened a request for having nested routes and resources and in this scenario this naive pattern falls apart, as you can't as you will overwrite all params with the same name, in this case :id .

However not solely relying on :id as param puts on into very unsafe, type wise, territory. And we now have to eject from refine as a result. Now for refine to support this sort of pattern, type safety is required.

Introducing Tanstack router, the type safe option.

Only problem is, in spite of a lot of core functionality in refine is built on top of tanstack libraries, I think the router is fundamentally at odds with the refine approach. Which I'm guessing is why there are no official integration yet, and the refine team has opted to ask for a community implementation. While I'm very much for that, I think a lot of hooks needs to be rewritten for this to work properly.

Problems:
Here are a few of the problems that I think stand in the way of this fantastic integration

1. the hooks from refine rely on ts generics, where as tanstack router has inferred types
2. for tanstack router to work, each route needs the variable of route exported, refine expects to have it handed to it before hand.
3. the obvious choice for data fetching in tanstack router would be via the loader, how would this work with the hooks from refine
4. the refine hooks in a way both declare the routes on the frontend as well as where to fetch data, how would this even look like in an integration

Benefits:

1. nested routing, as we get inferred typesafety, meaning the router will always know what is possible based on the current route
2. type safe query parameters, avoid issues with spelling or changing query params
3. type safe filters, sorters etc. right now you can pass them in refine, but with tanstack router, we can determine which endpoints and resources has which options, allowing our editor to tell us if we're trying to pass something that isn't possible.

Now this of course isn't an exhaustive list of neither the problems nor the benefits associated with a tanstack router integration, but these were the ones off the top of my head.

I am very open to contribute, but am not familiar enough with neither tanstack router nor refine internals, but I think that's just a matter of time. I intend on rewriting a small side project I have in react router to get more familiar with tanstack router and then I'm thinking of making a dummy project with refine to see if I can somehow built a shell on top of refine to make it somewhat integrate seemlessly. But I think the ladder would be very helpful if I got some pointers, I've looked at the source code for some of the other routers, but I just don't think that approach makes sense for tanstack router, but I guess I can get back to you on that.

Any and all help appreciated, I think the refine community would benefit tremendously from this.

[BatuhanW]

Hello @JuicyBenjamin thanks for bringing up this discussion. IIRC, we had an issue earlier about Tanstack Router but at the time it wasn't stable yet, so we wanted to wait for it to be stable before integrating it into Refine.

As you mentioned, Refine's headless architecture focuses on client-side only, and that part of the integration can be done relatively easier.

You can see the relevant docs here: https://refine.dev/docs/routing/router-provider/

If we oversimplify things, you'd need to implement 4 methods that binds to Tanstack Router to make it work at minimum level. Typesafe query params and all other things would needs to be thought. But also, Refine already handles query params internally, so unless you have a specific use-case, you shouldn't need to deal with them too much.

[JuicyBenjamin]

The refine default of :id for example is super great, when there's only one :id, but the second you need to change it, because the route need to contain more than one. For a example a user that has bookings, now it's a list view inside of a show route. Then if we want to navigate to a specific booking we need to differentiate between the id of the user and the id of the booking. So the if of the user now makes more sense to be :userId and we can maybe keep the :id from the booking. This is what I'd like refine to handle for me with type safety.

Imagine for example in the declaration of a resource I say that the route can be found at /user/:userId/bookings/show/:id it would be nice if refine could simply orchestrate it all based on that. Then know that when i want the resource id of a user, it knows to look for :userId instead of :id.

For more context I did write some of this back in december in discord: https://discord.com/channels/837692625737613362/1312893930408509450/1343869359285866496

I think yes, you can mold tanstack router to match to the current implementation of refine, but my theory is that it's not utilizing the full benefits and functionality of tanstack router. Which why I think the hooks of refine might need to be updated alongside the integration for it to be fully beneficial. It could also enable new patterns like loaders.

For sure we can make a relatively "easy" integration into the current system, and maybe that's a good starting off point, but I honestly see a new better paradigm. I'll try and tinker around with it a bit and see if I can make a prototype of sorts to maybe upgrade the refine approach.