What about Image/media libraries #7491
Replies: 7 comments 2 replies
-
|
Thanks for this @skeary, this is something we're interrogating as part of our roadmap if you have any additional thoughts on how this should work, please feel free to add them here 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @gwyneplaine for the feedback. That's great that there's some consideration around this. I'll think about this some more and if I can come up with any other aspects that I think might be worth mentioning I'll add them. |
Beta Was this translation helpful? Give feedback.
-
|
@skeary to add a bit more nuance to the conversation... Our current efforts around images and files are primarily focused on the Developer Experience – making Keystone as easy to configure as possible without compromising the principles of flexibility and modularity that Keystone is built upon (in order to make it an effective tool for all manner of use cases). However, we have discussed a more "opinionated" solution along the lines of what you’re suggesting, and acknowledge that the Editor Experience would benefit from such a feature. There are others in the community who feel the same way as you, and we’re capturing these signals as they arise. We're confident that #7070 will open more doors to developers without closing Keystone off to what you're after. That kind of EX was an influencing factor on this PR. Hope this helps! |
Beta Was this translation helpful? Give feedback.
-
|
@skeary would you be willing to add this to https://github.com/keystonejs-contrib/k6-contrib ? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the info @raveling. Yes, I think there's a tricky balance the benefits and drawbacks of a more batteries-included approach and not wanting to lock into a inflexible approach. I really appreciated that I could achieve what I needed but there were definitely some pain points. Implementing more complex fields is not easy due to having to understand the role of ListTypeInfo, defining the GQL input/output types, and the field controller setup for the editing aspect. Say you have a media library list (containing an image field) then within other lists you want an image picker field. The obvious data to store in the DB for the picker is the ID of the image list item containing the image. However at GQL query time you want to access the properties of the image list and contained image field. So the image picker field in many ways should mimic what the relationship field does - and this is probably one of the most complicated fields in the core! If you're a developer wanting to add this functionality that's a really big ask to implement. In that sense, if this is a relatively common need, I see this as much as a DX experience issue - if you're a developer wanting to implement this yourself then it's not going to be a great experience! This is also before you consider wanting to do some more elaborate functionality such as a component block that allows you to use an image picker to add/link images to document fields. For the app I've been working on I ended up cutting a few corners to make things work rather than replicate the whole relationship field. For example since I know and control the schema of my image list type, I've hardcoded the GQL definition/logic for my image picker field. @gautamsi - Partly as a consequence of this hard coding, unfortunately I don't think my solution is generic enough to be something standalone that other people can use directly. I'm also nervous that core changes may cause future maintenance issues even if I could make it generic. I suspect a similar thing will happen with your S3 image field (which I've really appreciated having!) as the core team pull similar functionality into the core. Perhaps another potential path forward is to provide significantly more customisation around the relationship field? What I'm thinking is essentially being able to implement an image picker as a relationship field, but with a completely customised UI and editor logic? Similarly, if this can be integrated into the document fields relationships, then you could also have the benefit of being able to use the hydrateRelationships feature of document fields to pull in the related image data when querying the document. Right now I've resorted to having a "content" field (of type document) and then a virtual "populatedContent" field that queries the document JSON, finds the images I need to populate, queries the related list, then returns an updated version of the document with the extra data I need stored in the component block data. The specific support for relationships in document fields I think also highlights that you can currently only go so far with custom component blocks, and it's not really practical at the moment to implement this outside of KS. I haven't looked into the relationship field implementation to see how feasible it would be to support this level of customisation. Has this been something considered by the team? |
Beta Was this translation helpful? Give feedback.
-
|
@skeary Could elaborate on how you made the image document field? I'm trying to do something similar but can't figure out how to use the context (and the db interface on it) from a component-block document field since it isn't passed into the |
Beta Was this translation helpful? Give feedback.
-
|
Hello everybody I am very glad to see that there is a discussion around this topic. I don't see, how offering a solution for this would make it too "opinionated". If you do not need it, just don't use it and implement images as a list just as you have to do now. If you want an idea of which features should be included, just take a look at Strapi.io, they have just recently improved their media management capabilities. An incomprehensive feature list:
In addition it would be very good to also be able to filter by relation, as @skeary has implemented in his solution, which by the way is something that would be way above my skill level to develop myself. I think media management be a decent addition to Keystone and make it a more viable solution for many projects. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I was wondering if there had been any movement on media libraries in keystone? Or alternatively if there were any examples/documentation which outline an approach to implementing something like what is shown in the original post of this thread? |
Beta Was this translation helpful? Give feedback.
-
|
I'm looking for the same info or updates. As others have stated, using these features would be optional, so no trade-off to DX. If we could upload images in bulk with drag and drop interface or just an input to select a folder, it would be a great improvement |
Beta Was this translation helpful? Give feedback.
-
Hi,
I can see there some potential upcoming improvements to image support in K6 which is great:
#7474
#7070
One thing I don't see covered in these is considering is potentially supporting the concept of a image/media library like some other CMSs, such as Wordpress, Contentful and Prismic do. Has this been given consideration? Rather than the current approach of creating an image field for a list, which then "owns" the image assets, image fields could then become references to the images in the media library. The primary advantage of this is that you can associate images with more than one field or record of other list type(s). So when you're editing an image field you then have the option to choose an existing image (via an image chooser widget), or upload a new one. Ideally you could also go to the image library independently and upload new images and curate what's there.
In my case I'm reusing images in several places and I've had to mimic the image library approach by creating my own list called "images" which then contains an image field. While this might seem like it's a reasonable substitute, I've found it not that usable without creating custom fields which is a lot of effort. For example if you have "post" list type and want to have a "main image" field then refer to an instance of the "image" list type you can't really use the provided relationship field. Although it technically works you can't see the image when editing or viewing the post in the admin area. In my case I resorted to creating my own custom field type for a linked image and then I implemented all the necessary UI and logic (e.g. image chooser dialog). Fortunately this has all been possible due to the great extension capabilities but it has been quite a bit of work. An example of what it looks like is below:
Similarly, I've added the ability to link to these images within documents as well as via two other custom field types. Again this is doable with enough effort, but I do wonder if it would make sense for Keystone to have an inbuilt media library?
Assuming a media library/list approach made sense, I think it may also be worth implementing this as a list that could be extended with other fields. This can then allow other information to be stored with the images. For example, in the image list I've created I have a dominant color field that stores the dominant color for the image. This is calculated and stored automatically using the existing hooks functionality which examines the image data in the image field when created/edited.
Thoughts?
Cheers,
Simon
Beta Was this translation helpful? Give feedback.
All reactions