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!
View on GitHubLast Edited: June 28, 2021