https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36369
Michał <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |om --- Comment #17 from Michał <[email protected]> --- Imho if you want to re-do an API client, it would make a lot of sense to do it in the most modern/universal and proper way possible. So something that could be used standalone also outside of the Koha UIs, maybe even on a separate repo and published on NPM (both to allow external JS programs to interact with Koha, but to also ensure it's written in an objective manner, with no hacks or short-circuits that'd unnecessarily bind it inherently to the Koha UI?). Then it also begs to finally use TypeScript, as type-safe API client is a very good thing, and you have OpenAPI specs that define everything about the APIs. So not doing that would be a big waste. The only problem is that a project like https://openapi-ts.dev/ for automatically translating OpenAPI specs to TypeScript types requires OpenAPI 3.x in current versions, but Koha still didn't migrate from 2.x (would be a good opportunity to do it). Of course the JS parts could still use it after building and not be too concerned about it. But in a proper setup, even then, a proper IDE setup could still give developers the type hints in their IntelliSense, which'd still be an easy win. So we should use something like that. Another win of using automated OpenAPI->TypeScript type generation would be that new endpoints defined in the schema could already be available for usage without manually needing to define them in yet another place. And without needing to manually type out all the code to handle the new endpoints (which would be pretty nice if we want to accelerate the API development and phase out the old one and classic Perl scripting) There's two projects: 1. https://openapi-ts.dev/ 2. https://heyapi.dev/ It seems that #1 focuses on more "bare" but usable schema generation, which can be used with their openapi-fetch client to access APIs in a type-safe but close to the original specs manner. For example (mind you that TS detects the exact path used by strings and type-checks the parameters!!): const { data, error } = await client.GET("/blogposts/{post_id}", { params: { path: { post_id: "my-post" }, query: { version: 2 }, }, }); It seems that #2 generates more of "prettier" SDKs already and focuses on direct integrations with plugins and middlewares etc. Their example is more like: const { data, error } = await getPetById({ path: { // random id 1-10 petId: BigInt(Math.floor(Math.random() * (10 - 1 + 1) + 1)), }, }); Not sure which approach seems nicer. Also technically it could be that simply generated types lived on a separate repo generated for all versions (including point-releases or major version tags), with clients being more responsible with how they'd directly pull/integrate them? I think everything really depends whether people would prefer using something like in #1 and maybe writing some more functional simpler wrappers around some of them (such as `blogposts.getPostById(id: number)`, or directly use something as in #2 which is something in between. Also the #2 having integrations with something like Zod or TanStack Query could prove quite useful in the future developments with Vue components (validating and auto-fetching of stuff etc.). I mean just look at the example here: https://tanstack.com/query/latest/docs/framework/vue/quick-start It would remain to be checked which one would work better with paginated endpoints though. It seems the #2's TanStack Query's integration has some support for infinite queries there in that regard. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
