Problem/Motivation
This one will be a little exploratory, and possibly a series of features. I think the first thing we need to do is make it easier to work with image data in default JSON:API responses. Considering default articles from Drupal core, I'd want to be able to do something like:
await client.getCollection("node--article", {
queryString: "include=field_image",
});
const { alt, title, width, height, langcode, filename, url } = getImageData({resource: article, field: field_image});
(Naming can change, didn't put much thought into it.) To get this data we need to resolve the relationship between field_image and the file--file entity in the included array. Things like alt, title, width and height are on the field_image relationship, and things like langcode and url are on the included file. This potentially has overlap with the
getRelationship Utility issue →
as a result.
This needs to work with the default image field (a file entity) and media images which are a field that references a media entity, that references a file.
Some other things we could do:
* The URL is relative. Since we know the baseUrl of the Drupal site we're sourcing from we could make that absolute. Or we could offer a small utility that makes relative URLs absolute based on the baseUrl of the client.
* Almost certainly another issue, but this could open the door for us to create an image component. Pass image data as props, render as an image. If image styles are included in the data (via jsonapi_image_styles) it could also render as a responsive image.
Original comment:
From @d34dman on Slack:
> I was wondering if we along with a “Drupal Client” provide a “Decoupled Media Browser” as well. This could resolve problems where Media browser appears un-styled in custom frontend theme. The Media Browser project would consume* Drupal Client and develop it as well, as it covers a lot of commonly required integration challenges like authentication and authorization, files/static assets, data, pagination, filtering etc..
My response:
> While the actual implementation of a decoupled media browser is something I'd consider out of scope for the API client project, utilities that make it easier to work with media data seem in line with the long term goals of the project.