Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Automatic generation of responsive images versions #5383

Closed
IlCallo opened this issue Oct 23, 2019 · 8 comments
Closed

Automatic generation of responsive images versions #5383

IlCallo opened this issue Oct 23, 2019 · 8 comments
Labels
kind/feature 💡

Comments

@IlCallo
Copy link
Member

IlCallo commented Oct 23, 2019 •
edited
Loading

Is your feature request related to a problem? Please describe.
art director and resolution switching problems, as seen here.

Some steps has been done with QImg component, but there's still a lot of stuff which could be automated.

Describe the solution you'd like
A webpack loader that process at build time all static images/multimedia referenced into HTML and automatically:

  • convert them into various and modern formats as needed (webp and jpeg for images I'd say);
  • produce multiple resolutions versions (based on defaults breakpoints or specified directly on the HTML tag/attribute) and automatically sets srcset attribute. This will resolve resolution switching problem;
  • provide a nice API over <picture> component for cropping images for different viewports. This would help to tackle art director problem;
  • is as much framework agnostic as possible.

Later on is possible to think about dynamic usage.

This follows more or less same principles behind Icon Genie: the task workflow is automatable, workflow is clear, best practices could be enforced by defaults and everything can work well out of the box.

I searched for this for a day and can't find something up-to-date and maintained.
I checked other UI libraries and framework, doesn't seem anyone implemented something like this in their build process.
Maybe I'm missing something for which it isn't a good idea to automate this stuff?

Describe alternatives you've considered
nuxt-image-loader:

  • Nuxt specific;
  • not at build time;
  • doesn't solve art director problem.

responsive-loader:

  • unmaintained;
  • doesn't solve art director problem;
  • webp not supported.

Cloudinary:

  • not at build time;
  • paid (and pricey) service if you want to self-host generated images, otherwise you should hit their CDN.

Responsive breakpoints service (related article, automatization):

  • must manually upload one image at a time or it needs a Cloudinary account to be set (as far as I understood)

Thumbor: this seems the one service I was searching, I'll study this one more in-depth.

Additional context
Related to #777 (comment)
@IlCallo
Copy link
Member Author

IlCallo commented Oct 30, 2019

I'm working on a Quasar-agnostic webpack loader to solve this (and maybe afterwards an app-extension to integrate it more easily).
I'll put a link here when it's ready and close the issue.

@rstoenescu
Copy link
Member

Looking forward to it <3

@IlCallo
Copy link
Member Author

IlCallo commented Dec 2, 2019

Still not ready for prime-time, but I'm gonna move the code to a public repository soon, even if I'm experiencing some weird behaviour with Quasar.
When I try to apply the loader on a Quasar project, it just doesn't run on Vue virtual files, unless I explicitly specify to look for Vue template tags instead of searching for any .html from any source, which should be officially supported by what I see on vue-loader website.

I think there is something conflicting with Quasar because the stack trace mention some sort of html minimalistic loader which auto-unload himself if at least another loader is defined.

Error: Error: Child compilation failed:
    Module parse failed: Unexpected token (1:0)
    File was processed with these loaders:
     * ./node_modules/@quasar/app/node_modules/html-webpack-plugin/lib/loader.js
     * ./dist/responsive-image-loader/responsive-image-loader.js
    You may need an additional loader to handle the result of these loaders.
    > <!DOCTYPE html>
    | <html>
    |   <head>:
    SyntaxError: Unexpected token (1:0)

Any hints on how can I fix this?

Examples

This won't work, but it should

cfg.module.rules.push({
  test: /\.html$/,
  loader: //...,
  options: {
    // ...
  }
});

This won't work either, but it should

cfg.module.rules.push({
  test: /\.html$/,
  resourceQuery: /^vue?/,
  loader: //...,
  options: {
    // ...
  }
});

Only this will work, but Vue core team told me I should not use this because it is considered technical implementations detail, not public API

cfg.module.rules.push({
  test: /\.vue$/,
  resourceQuery: /type=template/,
  loader: //...,
  options: {
    // ...
  }
});

@IlCallo
Copy link
Member Author

IlCallo commented Dec 17, 2019

I just released the alpha, if you wanna take a look: https://www.npmjs.com/package/@dreamonkey/responsive-image-loader/v/0.1.1

Configuration to use it on Quasar is directly on the readme.
I won't have time to do the app-extension (or work on package enhancements) until February, but it's really easy to integrate it.

It's my first webpack loader and I'd appreciate help to solve the webpack and Quasar known issues 👍

Shall I close the issue or do you want to be kept updated on this? @rstoenescu

@IlCallo
Copy link
Member Author

IlCallo commented Mar 5, 2020

Little update: it now supports background-images too.
Still have to make the setup easier and work on performances, adding a cache for example

@IlCallo
Copy link
Member Author

IlCallo commented Sep 14, 2020 •
edited
Loading

Update: latest version (0.4.1) added the thumbor-docker adapter in addition to the normal thumbor one.
This means the loader is now usable cross-platform and with a simplified thumbor setup. After you installed docker, it's just a matter of downloading the proper docker image and everything should work out of the box.

Performance are now the main pain-point

@hawkeye64
Copy link
Member

@IlCallo It's been over a year for activity. Can this ticket be closed?

@IlCallo
Copy link
Member Author

IlCallo commented Nov 29, 2021

Yes, whoever is interested into this can check out progresses into the referenced repo.
I don't see this becoming part of Quasar core anytime soon for now, current implementation need quite some setup and the package still have unresolved performance problems which can be solved only by leveraging Webpack 5 built-in caching mechanism

@IlCallo IlCallo closed this as completed Nov 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/feature 💡
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rstoenescu @IlCallo @hawkeye64