A fully open-source headless CMS that supports Markdown and Visual Editing
This release includes some changes to the MediaStore API that could cause existing implementations to generate errors. If you're using one of our first-party implementations (such as GithubMediaStore or StrapiMediaStore), you shouldn't need to do anything other than upgrade those respective packages to the latest release. If you created your own MediaStore implementation, you will need to make some small changes.
The media library is switching to a different pagination format. The previous version used numbered pages, and had the list method pass a numerical limit and offset back-and-forth to the UI. This style of pagination is not compatible with certain Digital Asset Managers and other API-based data storage providers, which instead return a batch of results along with a "cursor" value that can be used to retrieve the next batch of results in sequence. This is a less-opinionated style of pagination, and any existing setups using the old approach should be easy to migrate by making some changes to their list method. Take a look at the GithubMediaStore commit that migrates it to the new API, and continue reading below for details on the how and why.
The only metadata (data in addition to the list of media items) that your list method needs to return is nextOffset. This will represent the cursor position that the next set of records should be retrieved from, and will be passed back into your list method as its offset value when a user clicks Next in the UI to browse further in. Assuming your current list method is API-accurate, you will have a few return values to remove:
return {
items: items.map(contentToMedia).slice(offset, offset + limit),
- offset,
- limit,
nextOffset: nextOffset(offset, limit, items.length),
- totalCount: items.length,
}
The offset value sent to your list function via the options object is now typed as string | number, as some APIs may use alphanumeric keys to represent your browsing position in the collection. If you're using TypeScript and performing arithmetic with the offset value, you should expect to see an error here. Because the offset value passed to your list method is going to be a value that was returned by your list method at some point, it is safe to coerce the offset value to number as long as your nextOffset return value is also a number.
- const offset = options?.offset ?? 0
+ const offset = (options?.offset as number) ?? 0
We could also solve this with generics, but felt that would be heavy-handed for this case. Let us know if you feel differently!