Feature Request Filtered Route list by parameter names

[DellanX]

Hi,

I just started experimenting with adding data-loaders, and I have to say that they are amazing!
I now have 2 composables that I can put in 90% of my views to simplify the initial data queries. Combine that with pinia-colada, and my page loading is atleast twice as fast (so fast... the overhead in my stress test is the majority of my test time).

A nice to have would be a way to get a RouteMap or similar type, that only contains the subset or routes that provide the specified parameter.

Here is my default fetch composable:

    type IdentifierKeyType<M extends Identifiable> = {
        [I in keyof M]: I extends string | IdType ? I : undefined;
    }[keyof M];
    function fetchOneLoader<M extends Identifiable, Name extends keyof RouteMap>(config: {
        name: Name,
        type: new () => M,
        include?: (RelatedCollectionKeys<M> | RelatedKeys<M>)[],
        key?: IdentifierKeyType<M>,
    }) {
        const typeName = getType(config.type);
        config.key ??= 'id';
        return defineColadaLoader(config.name, {
            key: (to) => [typeName, to.params[config.key]],
            query: (to) => fetchOneAsync({
                type: config.type,
                id: to.params[config.key],
                include: config.include
            }),
            staleTime: 10000,
        })()
    }

Right now, my code throws some IDE errors, as there isn't any definitions stating that config.key would be present in the to.params object. While I could do some null checks, my ideal setup would be to have a type mapping such that if I specify that config.key is slug, only routes with [slug] are compatible with name. Furthermore, if I specify that config.key is id, then only routes with [id] are compatible with name.

I'll do some experimentation on my end, and see what I can make. If I come up with a strong alternative solution I'll post it on my side.

Rationale

The reasoning behind my composable above is that most of my data fetching is the same exact call, with just a few variations. These variations are either the resource type, the resource id, or the related resources to load with the resource.

// user page
const { data: user } = useData().fetchOneLoader({ name: '/users/[id]', type: User });
// chat page
const { data: user } = useData().fetchOneLoader({ name: '/chats/[id]', type: Chat });
// documents page
const { data: user } = useData().fetchOneLoader({ name: '/documents/[slug]', type: Document, key: 'slug' });

I already thing I am going to restructure my arguments to be something such as:

// user page
const { data: user } = useData().fetchOneLoader(User, 'id', '/user/[id]', { include: ['chats'] });

Final notes

This issue isn't critical to me, I just figure it may be a nice to have, especially in conjunction with data loaders. In the past I was fine because the query was tied to the same context as the page setup. As for now, I will probably just ignore the IDE errors. If I do get some type definitions running well, I can add them to this issue (even if closed).

[PindaPixel]

Sounds like what you're looking for is a type utility that narrows RouteMap to only contain routes that contain a parameter called slug:

type RouteNamesWhereParams<Params extends RouteParamsRawGeneric> = {
    [Name in keyof RouteMap]: RouteMap[Name] extends RouteRecordInfo<string, string, Params> ? Name : never;
}[keyof RouteMap];

type RoutesWithSlug = RouteNamesWhereParams<{ slug: any }>;

[DellanX]

That's close to what I was targeting. More of a narrow to where I could do

RouteNamesWhereParams<'slug'> and let my user defined method do the type conversion.

I've made a few successful type utilities, but they weren't playing well with informing the loader that the to.params.slug property exists.

[DellanX]

I modified your type utility some more to give kindof what I am looking for:
  

type IdentifierKeyType<M extends Identifiable> = {
    [I in keyof M]: I extends string | IdType ? I : never;
}[keyof M];

type RouteNamesWhereParams<Params extends RouteParamsRawGeneric> = {
    [Name in keyof RouteNamedMap]: RouteMap[Name] extends RouteRecordInfo<string, string, Params> ? Name : never;
}[keyof RouteNamedMap];

type RoutesWithKey<T extends string> = RouteNamesWhereParams<{ [P in T]: any }>;
const test: RoutesWithKey<'id'> = '/users/[id]';
const test2: RoutesWithKey<'slug'> = '/documents/[slug]';

Unfortunately, I still see some IDE type errors with my composable:

    function readOneLoader<M extends Identifiable, K extends IdentifierKeyType<M>>(
        type: new () => M,
        key: K,
        name: RoutesWithKey<K>,
        config: {
            include?: (RelatedCollectionKeys<M> | RelatedKeys<M>)[],
            onSuccess?: (data: Nullable<M>) => Nullable<M>,
            onError?: (data: Error) => Nullable<M>,
        }) {
        const typeName = getType(type);
        return defineColadaLoader(name, {
            key: (to) => [typeName, to.params[key]],
            query: (to) => fetchOneAsync({
                type,
                id: to.params[key],
                include: config.include
            }),
            staleTime: 10000,
        })()
    }

The issue is:

Type 'K' cannot be used to index type 'RouteNamedMap[RouteRecordInfo<"/", "/", Record<never, never>, Record<never, never>, RouteMeta> extends RouteRecordInfo<...> ? "/" : never]["params"] | ... 65 more ... | RouteNamedMap[RouteRecordInfo<...> extends RouteRecordInfo<...> ? "/verify-email" : never]["params"]

[DellanX]

I actually got a working example, which I have to swap my structure a bit:

    type ValidKeyForRoute<R extends keyof RouteNamedMap> = keyof RouteNamedMap[R]['params'];
    function readOneLoader<
        R extends keyof RouteNamedMap,
        K extends ValidKeyForRoute<R>,
        M extends { [P in K]?: Nullable<string> } & Identifiable,
    >(
        name: R,
        key: K,
        type: new () => M,
        config?: {
            include?: (RelatedCollectionKeys<M> | RelatedKeys<M>)[],
            onSuccess?: (data: Nullable<M>) => Nullable<M>,
            onError?: (data: Error) => Nullable<M>,
        }) {
        const typeName = getType(type);
        return defineColadaLoader(name, {
            key: (to) => [typeName, to.params[key] as string],
            query: (to) => fetchOneAsync({
                type,
                id: to.params[key] as string,
                include: config.include
            }),
            staleTime: 10000,
        })()
    }

this allows me to quickly define a loader for a document as:

readOneLoader('/documents/[slug]', 'slug', Document);

Should I accidentally try and load a User, I'll see a type hint error:

readOneLoader('/documents/[slug]', 'slug', User); // throws an error, as 'slug' does not exist in User

For me, this above works just fine and resolves my needs. Every page has type checking to ensure that the resource can be loaded from the specified route. And I have a generic loader that can be used for all of my models.

• Now for me to make a page where I load a specified instance, I can use readOneLoader for example /document/[slug]
• If I want to load every instance (of the specified model, I can use readManyLoader for example /documents
• If I want to load a related instance, I can use readOneRelatedLoader for example /friend-requests/[id]/user
• If I want to load all related instances, I can use readManyRelatedLoader for example /users/[id]/chats

This way, I don't need to repeat define these functions for each model and can configure a page on the fly.

[posva]

I now have 2 composables that I can put in 90% of my views to simplify the initial data queries. Combine that with pinia-colada, and my page loading is atleast twice as fast (so fast... the overhead in my stress test is the majority of my test time).

That's pretty cool! 🙌

It seems to me that you need a type narrowing, like the one @PindaPixel posted.

BTW, you are supposed to call defineLoader() only once. It looks like the way you are doing it right now, it creates a new loader each time. While it might work in some cases, it will most definitely break in others. In your specific scenario, you should be able to hoist the definition. Also, make sure to export them from page components so they are integrated into the navigation flow!

[DellanX]

I think you're correct, that's the kind of functionality I am looking for

And as to what this is for, I create helpers to quickly create type specific methods for data interactions. My application has a lot of data models, and they can get convoluted. The idea is that instead of creating a composable each type by hand, I can instead use the a function to create a composable for the specific type needed.

So in a page, defineLoader() is only called once. I don't use useUserData() I'd use useData(User) instead. (Or, more accurately, I'd use useData().fetchOneLoader(User, 'id', '/users/[id]')).

I guess, the feature I was trying to see about, would be a way to define generic data loaders, so that the implementation details don't need to be duplicated. And I do think that this could be resolved by a type utility such as in the other post.

[DellanX]

I have my solution, but it is kindof an inverse of this discussion title though:

I actually got a working example, which I have to swap my structure a bit:

    type ValidKeyForRoute<R extends keyof RouteNamedMap> = keyof RouteNamedMap[R]['params'];
    function readOneLoader<
        R extends keyof RouteNamedMap,
        K extends ValidKeyForRoute<R>,
        M extends { [P in K]?: Nullable<string> } & Identifiable,
    >(
        name: R,
        key: K,
        type: new () => M,
        config?: {
            include?: (RelatedCollectionKeys<M> | RelatedKeys<M>)[],
            onSuccess?: (data: Nullable<M>) => Nullable<M>,
            onError?: (data: Error) => Nullable<M>,
        }) {
        const typeName = getType(type);
        return defineColadaLoader(name, {
            key: (to) => [typeName, to.params[key] as string],
            query: (to) => fetchOneAsync({
                type,
                id: to.params[key] as string,
                include: config.include
            }),
            staleTime: 10000,
        })()
    }

I don't know if this would be a recommended approach, if this should be documented somewhere, or what any other next steps should be. As is, the code meets my needs. Let me know if there's something I can do to help. These dataLoaders are exceptional, and I'd love to give back in any way.

To which, again, these loaders are very fast and very flexible. It didn't seem to matter at all that I have a lot of different tools being used. Implementing a functional system only took me a few hours of effort. (Getting the types was a pain, but mainly due to me trying to force it to work a different way).

I look forward to when the feature is stable, because again, it is an amazing feaure.