Update the Strapi guide to version 5 and use the official Strapi client library instead of a custom function

[Dovakeidy]

📚 Subject area/topic

Strapi CMS

📋 Page(s) affected (or suggested, for new content)

https://docs.astro.build/fr/guides/cms/strapi/

📋 Description of content that is out-of-date or incorrect

The Astro guide for Strapi is outdated regarding the data format returned by the Strapi API. Since Strapi v5, the response no longer includes the attributes field. Additionally, it now uses a documentId field.
👉 See the breaking change documentation for more details.

Additionally, Strapi now provides an official client library that simplifies API calls and should be preferred over writing custom fetch logic.
📚 Official client documentation: Strapi Client

It would be better for the guide to be updated to reflect these changes and leverage the official client.

🖥️ Reproduction in StackBlitz (if reporting incorrect content or code samples)

No response

[sarah11918]

Thank you for letting us know that Strapi has updated and our guide needs to update, too!

Absolutely we'd like this updated, so I'll add help wanted on this issue, and anyone is welcome to make a PR with the appropriate updates to the content! 🙌

No need to ask... if you don't see a PR already made, go for it!

[Dovakeidy]

@sarah11918

I’d be happy to open a PR, but I’d need a bit of guidance to do it properly. I have a couple of questions before moving forward:

1. The official Strapi client doesn’t support TypeScript yet (as discussed in this issue).
   I’ve made a Gist to address the problem, but it has some limitations: it only works in monorepo-like setups where the generated Strapi types are located near the project.
   Would it make sense to encourage Astro users to create a wrapper around the Strapi client to add type safety via generics (like the current Astro guide)?

2. Should we mention the key differences between Strapi v4 and v5 ? Especially the introduction of documentId and the attributes field?

[sarah11918]

hi, thanks for being willing to help!

I guess part of the answer depends on whether we expect people to still use Strapi 4 or expect everyone to update to v5. like, is this going to be a Tailwind situation where some people are deliberately staying on older versions, or do we expect that now going forward, people will use version 5?

It's not really our place to document the intricacies of Strapi, and we wouldn't document updates, differences, or changes from one version to the next. We should have one guide that focuses on making it work with Astro, and ideally that is only one version.

also, if version 5 isn't fully compatible with Astro and requires workarounds, it may be best to leave the guide at V4 until there's better support.

So, one quick fix could be simply to update the page right now and make it clear that these are instructions for version 4. That, we can do immediately so that at least people know.

[Dovakeidy]

Strapi 5 is fully compatible with Astro, the only downside of using the @strapi/client library is the lack of TypeScript typings.

Since this library is optional (it's simply an official helper for making API calls to a Strapi backend), we could build a small wrapper around it to add proper typings ( similar to what the current Astro guide suggests with the fetchApi util ).

Or maybe we should simply update the Astro docs to reflect the breaking changes in Strapi v5 — namely the introduction of the attributes and documentId fields (which replaces the previous id field) — and leave fetchApi as-is?

[sarah11918]

maybe we should simply update the Astro docs to reflect the breaking changes in Strapi v5

Yes, this is normally what we would do. The document should be correct for the current version of third-party services, and we do not document nor compare to past versions. If you'd like to update the document to correct inaccuracies and reflect how it is currently working, that would be helpful!

These guides are also not meant to be substitutions for following the documentation of these other services, but only to highlight integrating with Astro when/where we can. So, we're more concerned with very minimal, correct documentation so someone can get a sense of what using the CMS with Astro would be like (people are often using these guides as a way to evaluate when choosing a CMS). Or, in the event that someone is having a problem getting a service to work then they have a minimal example of something correct they can use as a starting point to ensure they have connected with Astro in the intended way. It is not necessarily a goal of these to showcase advanced usage, highly opinionated or best practices.