V2 #975
Replies: 9 comments 10 replies
-
In addition to the migration from classes to the more compositional/function approach, could we ensure consistent naming of all the user-facing APIs? When a timeline for v2 is more clear we could take stock and compile a list of user-facing APIs for renaming. |
Beta Was this translation helpful? Give feedback.
-
It's something I saw on X/Twitter a few months back and a variation of which I saw today. It's about the idea of utilizing JSDocs for giving the user documentation right in their code editor. Approach 1For an easy option, we could do what Tanstack Table did, and add links to the JSDoc comments on each property which would direct the user to the individual headings on the Documentation site. This would be rather a quick task and has a significantly reduced buy-in compared to approach 2. Approach 2We could ship the entire Reference docs to the user through JSDocs by setting them on the properties. It gives the user the benefit of not having to even visit the reference site, whilst retaining the exact version of documentation needed for the package version they are on. However, this approach would require investigation into how we could extract the comments from JSDocs into usable static documentation, as well as the CI steps that would come with it. Also, on how this would affect bundle sizes. |
Beta Was this translation helpful? Give feedback.
-
Adding a helper function similar to Use case I'm looking at: // /postId
const Route = new Route({
...,
loader: async ({ params: { postId } }) => {
const post = await getPost(postId);
if (!post) throw notFound();
return postl
}
}) The behaviour of this helper during the |
Beta Was this translation helpful? Give feedback.
-
I updated this with the work I just did in v1. All of it should be non-breaking. |
Beta Was this translation helpful? Give feedback.
-
I'm thinking about decorate LOL, like .NET |
Beta Was this translation helpful? Give feedback.
-
One more things, I'm adapting to TanStack Router (previously .NextJs), But I still no see a document about routing with Markdown file |
Beta Was this translation helpful? Give feedback.
-
Hey @tannerlinsley, Excited about the upcoming "Render" and "Viewport Visibility" preloading strategies! Considering their importance, I'd like to request early implementation if possible. While I understand there might not be many requests for additional strategies, having more options would offer developers greater flexibility. Could we discuss the possibility of including them in the current version of Router or perhaps the next release? Thanks for your attention to this! |
Beta Was this translation helpful? Give feedback.
-
Exploring the possibility of making the router-plugin compatible with more than just vite. Following up on this comment in a discussion thread, it seems like could be feasible to open up the router-plugin to other build tools. unplugin.unjs.io would be the dependency for the compatibility layer, letting us write the plugin once, and get the adapters for vite, rollup, webpack, etc. The unplugin team, also have an example plugin using Babel for AST traversal, which would let us bring the automatic code-splitting feature to the other build tools as well. |
Beta Was this translation helpful? Give feedback.
-
Moving away from classes
Classes are great for defining types and functionality in one go, but they're not very friendly to destructuring and compositional/functional APIs. The following changes would unify the router API to be less class-y and more function-y.
new Router
in favor ofcreateRouter
new RootRoute
in favor ofcreateRootRoute
new Route
in favor ofcreateRoute
new FileRoute(path).createRoute(options)
in favor ofcreateFileRoute(path)(options)
new RouteApi
in favor ofgetRouteAPI
FileRouteLoader
in favor of the newcreateLazyFileRoute
andRoute.lazy
functionsJSDoc Annotations
Code Splitting
component
,errorComponent
andpendingComponent
in favor ofcreateLazyFileRoute
andRoute.lazy()
Code-Generation
Server
escapeJSON
in favorjsec
.dehydrateData
in favor ofinjectHtml
.hydrateData
in favor ofinjectHtml
.General
notFoundComponent
. See migration guide here.global
onNotFoundError
in favor ofrouteId
.href
inredirect()
in favor ofstatusCode
.ErrorRouteProps
in favor ofErrorComponentProps
.navigate
function as an argument in the beforeLoad and loader callbacks, in favor of usingthrow redirect(...)
andthrow notFound(...)
.Beta Was this translation helpful? Give feedback.
All reactions