search

nuxt / image

Plug-and-play image optimization for Nuxt applications.
https://image.nuxt.com
MIT License
1.33k stars 272 forks source link

Providers could use more control #36

Open jaubourg opened 4 years ago

jaubourg commented 4 years ago

Hi there !

For now, providers only generate URLs but it may prove problematic for some providers and transformations. For instance, TwicPics does not (and probably never will) pad images when doing a contain transformation. It could be nice if a provider was able to specify the object-fit that should be applied to the underlying img element. Letting a provider return an Object with a url and fit property as an alternative to a bare string would suffice. If a provider returns a bare string just use the default object-fit.

Another area that could be buffed up too is regarding placeholders. At TwicPics, we're currently working on implementing different kinds of placeholders. It would be nice if a provider could expose a method that would be separate from generateURL (say generatePlaceholderURL). If a Provider does not provide a generatePlaceholderURL method, just call generateURL using the default transformation currently computed by nuxt-image.

Finally, but it may be out of scope for nuxt-image, we have a script at TwicPics that takes care of API calls generation based on the context of the page (users put the URL of the master image in data-src and size their image using CSS, we generate the src attribute on the fly and dynamically, plus we handle lazy loading to boot). To support such a feature would require a lot more control over the generated HTML but, as I said, it may be out of scope here.

Please let me know if this all makes sense.

pi0 commented 4 years ago

Hi @jaubourg Thanks for feedback :green_heart: Adding more control to providers by getting meta from generateURL (will be refactored to getImage) seems a nice idea!

Providers can internally utilize a SDK but changing image component behavior globally is not preferred since goal of image module is to keep usage abstract enough by providers for consistent usage. Other features can be implemented in a separate module (similar to cloudinary) and users can choose between abstraction or provider specific usage.

Regardless, would be amazing if was free for a call in next weeks so we can discuss more ideas (/cc @farnabaz @Atinux)

jaubourg commented 4 years ago

Hi @jaubourg Thanks for feedback 💚 Adding more control to providers by getting meta from generateURL (will be refactored to getImage) seems a nice idea!

Awesome ! 💚

Providers can internally utilize a SDK but changing image component behavior globally is not preferred since goal of image module is to keep usage abstract enough by providers for consistent usage. Other features can be implemented in a separate module (similar to cloudinary) and users can choose between abstraction or provider specific usage.

That makes sense of course. Still, I wonder if it wouldn't be possible to do it cleanly by simply having getImage return an object with actual img element attributes ;) But, yeah, a TwicPics component would be more suited anyway.

Regardless, would be amazing if was free for a call in next weeks so we can discuss more ideas (/cc @farnabaz @Atinux)

With pleasure, just gimme a date and time and I'll try and manage. Which time zone are you guys in ?