Is there a way to extract typescript types to be used in a separate frontend?

[ahmad_alghanam]

I’m using typescript nextjs app to communicate with strapi.
I have for example a “project” content type that has several fields (text and media fields)
My question is: is there a way to get the type of the data returned from calling the “projects” rest endpoint from my nextjs app so I can use it rather than defining the types manually in my nextjs app?

[mancku]

I’m working on a plugin for that. Hope I can get it ready soon. I’ll let you know in this post

[Andrei_Wilkens]

You can use Tools liek “orval” for this. You just need to exclude some types in the orval config - but you can just generate the types with it from the OpenAPI Documentation that Strapi generates

[Andrei_Wilkens]

Sharing Strapi schema with other projects (e.g. front-ends)

Hey dude, So as answer 1 said, if You’re using typescript You can ts generate types This will create a file “schemas,d.ts” or sth like that In that file You should have almost all the content types, only that You have to access their “attributes” attribute (so You import the type, but the fields of the content types are like: import type ApiOrder type Order = ApiOrder[“attributes”] What You can do is then add the strapi repo to Your nuxt repo as a submodule, You can then import those types…

Here you can see another Thread about it , where i described it a bit more detailed

[d17e]

I recently ran into the same problem and noticed that the documentation plugin generates an openapi json spec. I tried some codegenerators to get my typescript types & client generated but didn’t get this to work well. The strapi types and openapi spec contain a lot of abstractions and details that aren’t exactly relevant for the frontend which I think are related to the issues I faced.

As this didn’t exactly work out and I didn’t want to roll everything by hand, I decided to try out the graphql endpoint plugin. turns out this comes with a graphql playground (little UI to play with the api) and let’s you configure the location where it generates the graphql schema. So now my Strapi server regenerates the schema every time the model changes and then this is consumed in my client app with the @graphql-codegen package. I had to learn how to write graphql queries though, but all in all this is working great for me now.

Note that I’m still hand-rolling simplified view models and mappers as I don’t want to deal with all the intermediary types of the strapi abstractions in my client application.

I would however have rather seen a cleaner and more straightforward solution to all this and might give the orval.dev generator a try if I find some time. Or the new plugin that’s coming soon.

Let me know if anyone wants more details on the graphql setup I’m currently using

[gokeez]

Is there at least one working plugin for this right now?

[mancku]

@gokeez, @d17e, @ahmad_alghanam @Andrei_Wilkens

I finally uploaded the plugin to NPM and I got it working just fin in 3 different projects: strapi-plugin-schemas-to-ts - npm and hope it helps.
The documentation needs improvements, because Strapi generates so many different versions of the same interface that it’s difficult to comprehend at first glance. I’ll keep working on it. Any feedback is welcome.

[Marci_T]

Perfect plugin, works just fine.

[Alissa_Verkhovsky]

hi, I found 3 different ways to create api types for the frontend project.
all of them have some drawbacks:

1. use the openAPI documentation plugin and generate types with the help of some library (orval / openapi-ts or any other).
   pros: you get all the types including errors.
   And it enables you to autogenerate the api code as well.
   cons:

• the docs plugin doesn’t flag most properties as required. so data, attributes, id and many others are optional and your code looks like res?.data?.attributes?.title which is annoying and wasteful.
• you need to run the script with each build

2. use the strapi-plugin-schemas-to-ts plugin by @mancku mentioned above (grate plugin, thank you )
   pros: it generated the types by itself in the strapi project, and you just import them if you have a monorepo or copy otherwise
   cons: many of the properties are required which is annoying if you are mocking the data and a bit dangerous cause they could be empty in reality.

3. use the method described in strapi blog. the idea there is that you add types to your frontend project that use the auto generated contentTypes.d.ts to create the api types.
   pros: no new generated types, and it is based on types that strapi generates and hopefully uses itself.
   also the types are quite accurate optional / required wise
   cons: currently it is a piece of code you add to your project, so you have to maintain it. and I already found some minor mistakes in the code.

I hope it helps
** I can put only 2 links in the post… so some links are missing

[mancku]

@Alissa_Verkhovsky

perties are required which is annoying if you are mocking the data and a bit dangerous cause they could be empty in reality.

Hi @Alissa_Verkhovsky thanks for pointing that out about that cons. I’m trying to fix it, but any information about real use cases and/or help would be welcome. Please, don’t hesitate to open issues or PRs on the project repo if you want GitHub - mancku/strapi-plugin-schemas-to-ts: Strapi Plugin Schemas to TS is a plugin for Strapi v4 that automatically converts your Strapi schemas into Typescript interfaces.