v8 ideas 💡

[anymaniax]

I am already thinking about version 7 for a moment and wanted a place to talk about it.

1. Split the lib into multiple packages to have a core and a package by template/client. Like that we can have multiple advantages. Versioning for the template and be able to use an older version of a template if your project is on an older version of react-query for example. Also having a core will help people that want to create their own template and then use it with other features of orval.

2. Rethink the config file since I started this lib a lot of stuff has been added and I think we can improve some points. For example, the generation could be more custom. I think for example that having a mix of this and some of Orval features could be great

3. move to esm?

if you have any other ideas throw them here so that we can discuss it

[melloware]

I definitely like the idea of breaking the lib up so its easier to find and make changes to the different libs. Changing the config file though might be a big and painful change. However it may be worth it but I am not sure.

[anymaniax]

I was also thinking about having a migrate command to do it easily for users

[paolotiu]

Another feature that would be handy is to add a zod schema generator

[stijnvanhulle]

#347 MSW controllers to a separate index file) This one should be great to have :)

[anymaniax]

What do you think of this for query keys

[melloware]

What do you think of this for query keys

I LOVE this idea. I find myself doing this a lot in my code...

const QUERY_LIST = "list-cars";
 const queryList = useGetEntityCars(
        { request: JSON.stringify(lazyParams) },
        {
            query: {
                queryKey: [QUERY_LIST, lazyParams],
                refetchOnWindowFocus: false,
                retry: false,
                cacheTime: 0
            }
        }
    );

So then later I can do this...
queryClient.invalidateQueries([QUERY_LIST]);

So that library looks like what I wanted to do all along!

[melloware]

Although I do hate tying myself to another runtime library written by just one guy. it would be cool if you could just copy his code and include it in the generated code?

[DominicBach]

I've been playing with the codebase for a bit and have been experimenting with using the Typescript AST factory to generate code as opposed to plain string manipulation. I've used it to encapsulate mock generation logic into separate type classes, which I could then compose together to build more complex representations.

It could also solve your idea for additional customization by allowing users to hook into the AST generation process to change the code at generation time.

I've committed the code to my fork if it's something that might interest you, I'd be happy to put more work into this.

[la55u]

have been experimenting with using the Typescript AST factory to generate code

I also think that this is the way going forward as the string manipulation approach is quite unmaintainable. A cleaner approach can be seen for example here however it's quite opinionated and orval has much more configuratoin options. I think orval could attract a lot more contributors in the long run if it were rewritten with TS generators.

Edit: Can you pin this issue?

[maapteh]

Now with react-query v5 and breaking contracts it would be very handy to choose which major your client is using. Maybe support up to 1 major back?

[Will-Mann-16]

Maybe have zod be an includable separate layer (i.e. request/response validation on top of axios on top of react-query). Or just splitting things into layers, like having the request engine layer be between axios or native fetch, then an optional validation layer with zod, then the caching control/hooks/query library layer for tanstack query or swr.

[bojanbass]

@Will-Mann-16 yes, this would be perfect, I'm searching for this solution.