feat(common): add automatic srcset feature to ngOptimizedImage#47547
feat(common): add automatic srcset feature to ngOptimizedImage#47547atcastle wants to merge 1 commit intoangular:mainfrom
Conversation
kara
left a comment
There was a problem hiding this comment.
Thanks for the PR! Great basis for discussion on srcset design - let's continue in the chat?
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
aio/content/guide/image-directive.md
Outdated
There was a problem hiding this comment.
How do ngSrcset and the generated srcset intersect? Is there any reason to keep ngSrcset around if you can define custom breakpoints anyway?
There was a problem hiding this comment.
Right now if you use ngSrcset the directive will just use that value, and won't use the automatic srcset. I'm not sure if we need to keep providing the ngSrcset convenience API or not. It could be useful for some people, but it also does complicate the API
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
How necessary do we feel this trimming is? It seems like more computation to do for every image, and I'm not sure it's worth saving a few bytes in the document.
There was a problem hiding this comment.
Also what happens if the "sizes" attribute contains a fancy query (e.g. "(max: 500px) 400w" type thing)? Do we want to support that? I guess we'd have to throw it contained a value that wasn't in our breakpoint list
There was a problem hiding this comment.
Yeah, I'd be ok with removing this logic. Especially in a CSR scenario, there's not that much benefit to trimming those extra URLs. Though, it could make some sort of a difference on a page with a lot of images doing SSR. A few of the smallest breakpoints (16, 32) tend get trimmed almost all the time.
As for the mixed queries--I don't think that's super common, and I also think they're a pretty good case for where someone would want to shut off the automated srcset entirely. If you're using sizes with that level of specificity, you probably also want to manually define your srcset.
There was a problem hiding this comment.
Let's remove this trimming logic for now? We can discuss and add it in a future PR if we think it's necessary
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
AndrewKushnir
left a comment
There was a problem hiding this comment.
@atcastle thanks for creating this PR! 👍 Just left a few comments.
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Should we make this input name more specific? Currently it may sound like it disables all optimizations. May be mimic the config property and call it disableAutoSrcset, WDYT?
There was a problem hiding this comment.
Hmm I like the idea of making it more specific, but I also want to make it clear that this pattern is not recommended. What about "unoptimizedSrcset"?
There was a problem hiding this comment.
To me, unoptimizedSrcset sort of implies that you get a srcset, but that it's not optimized. But with this attribute you actually get nothing, srcset-wise.
There was a problem hiding this comment.
Oh, that's a good point. I can see it being read that way 🤔. I'm good with "unoptimized"
There was a problem hiding this comment.
I think I'm still a bit concerned that we may be delivering a wrong message via an input name. The unoptimized sounds more like the entire optimization logic (including loaders, etc) is disabled. Can we chat about this during the next sync?
It'd be ok to proceed with the PR as is and update it later (before the feature freeze).
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Let's remove this trimming logic for now? We can discuss and add it in a future PR if we think it's necessary
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Question: do we want people to provide different breakpoint values in the different parts of the application? Or is the intention that one set of breakpoints applies to the entire application?
There was a problem hiding this comment.
I believe the main use case for doing this is to match a configuration on your CDN. Since it's possible to have different CDNs for different sections of an application (one for product images, another for static images, for instance) I think it makes sense to be able to set this differently for different parts.
2b3660b to
31155db
Compare
31155db to
99ad054
Compare
a2cc152 to
a44deda
Compare
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I think I'm still a bit concerned that we may be delivering a wrong message via an input name. The unoptimized sounds more like the entire optimization logic (including loaders, etc) is disabled. Can we chat about this during the next sync?
It'd be ok to proceed with the PR as is and update it later (before the feature freeze).
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Just curious why we need to add unoptimized here?
a44deda to
3876b41
Compare
|
Latest update to this PR changes |
packages/common/src/directives/ng_optimized_image/ng_optimized_image.ts
Outdated
Show resolved
Hide resolved
Add a feature to automatically generate the srcset attribute for images using the NgOptimizedImage directive. Uses the 'sizes' attribute to determine the appropriate srcset to generate.
3876b41 to
33dbbf5
Compare
AndrewKushnir
left a comment
There was a problem hiding this comment.
Reviewed-for: public-api
|
Merge-assistance (@jessicajaniuk): this PR is almost ready for merge, needs one more |
jessicajaniuk
left a comment
There was a problem hiding this comment.
reviewed-for: public-api
|
This PR was merged into the repository by commit 4fde292. |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This PR adds a feature for automatic srcset generation to the NgOptimizedImage directive. Srcsets are generated as density selectors (eg "1x", "2x") if there is no
sizesprop provided, or with responsive srcsets with a range of pixel values if asizesprop exists. These responsive breakpoints are user-configurable using a new provider called ImageConfig.The automatic srcset can be disabled with a new
unoptimizedattribute, or via the ImageConfig provider.Note: This PR only contains unit testing of this feature. End-to-end tests will be added shortly. Opening this now to begin discussion with @pkozlowski-opensource and @AndrewKushnir.
// CC: @kara
PR Type
What kind of change does this PR introduce?
Does this PR introduce a breaking change?