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.

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

feat: add experimental responsive images config option #12378

Merged
merged 5 commits into from
Nov 6, 2024

Conversation

ascorbic
Copy link
Contributor

@ascorbic ascorbic commented Nov 5, 2024

Changes

Just creates the config option

Testing

Docs

Copy link

changeset-bot bot commented Nov 5, 2024

⚠️ No Changeset found

Latest commit: 1e3d9fa

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@github-actions github-actions bot added pkg: astro Related to the core `astro` package (scope) docs pr labels Nov 5, 2024
*
*/

responsiveImages?:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be under image instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean as experimental.image, or at the top level?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the normal top level image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that something we do for experimental features?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We kinda have two philosophies, some people put it under experimental, some others don't. I personally think it makes the upgrading smoother when it's already where it will be, as you then don't need to move anything, but it's up to you really. It just felt a bit jarring to have both image and responsiveImages as two different options!

image in fact was top level while experimental, for instance

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That works perfectly for me!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sarah11918 what are your thoughts on this? Should the config options for the feature go inside experimental.responsiveImages, or shoudl that just be a boolean, with the config sitting in the top-level image object? I'm conflicted!

Copy link
Member

@sarah11918 sarah11918 Nov 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw this discussion and was happy to let it play out. 😅

We have precedence for both! experimental.env kept all its config within the experimental config and there was a time where astro:i18n had an option outside of the experimental config.

I don't have a strong opinion -- people are going to have to update their config either way in the cases you've described: either they move layout to the image option directly OR they update image.experimentalLayout to just layout. It sort of to me makes more sense in that case to keep all the config together?

The other option is also a bit wonky: just use image.layout BUT it only does anything with the experimental flag set. THIS is the option that means people don't have to update their config when it comes out of experimental (other than remove the flag). It's also not necessarily pretty to document something in the main config that is essentially no op without the flag, and, it means sending the user to two different places in order to configure the experimental feature. BUT it's the only thing that has the true advantage of needing less updating on behalf of the user.

So, I won't fight any of these options. I can make them all work and there's no clear and obvious winner here. I won't make the final call unless someone specifically wants me to.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the absence of any strong opinions on either side, I'll leave it as-is

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed my mind again! I've gone for the second option

Copy link
Member

@sarah11918 sarah11918 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SO EXCITED for this @ascorbic ! Just some super quick initial comments on the docs here, as they're getting worked out!

packages/astro/src/types/public/config.ts Outdated Show resolved Hide resolved
packages/astro/src/types/public/config.ts Show resolved Hide resolved
packages/astro/src/types/public/config.ts Outdated Show resolved Hide resolved
z.boolean(),
z.object({
layout: z
.union([
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can use z.enum

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah duh!

packages/astro/src/core/config/schema.ts Show resolved Hide resolved
@@ -525,6 +526,22 @@ export const AstroConfigSchema = z.object({
.boolean()
.optional()
.default(ASTRO_CONFIG_DEFAULTS.experimental.contentIntellisense),
responsiveImages: z
.union([
z.boolean(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder how updateConfig() will behave if the user sets it as a boolean, and an integration sets layout

Comment on lines +158 to +160
fit?: 'fill' | 'contain' | 'cover' | 'none' | 'scale-down' | (string & {});

position?: string;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've gone with the shorter names for the HTML attributes for ease of use and avoidance of confusion of camel vs kebab

* {
* experimental: {
* responsiveImages: {
* layout: 'responsive',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This now changes in that you only set this to true and now you go to regular image config to configure the properties, right?

And, since we now have multiple properties (acknowledging there may still even be more to come!), when you do add the regular image config for this example, I would set at least a couple of them.

(Not meaning to overly edit while stuff is still happening, just didn't want us to forget!)

@ascorbic ascorbic merged commit 84492b0 into responsive-images Nov 6, 2024
12 of 14 checks passed
@ascorbic ascorbic deleted the resp-img-config branch November 6, 2024 06:58
ascorbic added a commit that referenced this pull request Nov 15, 2024
* chore: changeset

* feat: add experimental responsive images config option (#12378)

* feat: add experimental responsive images config option

* Apply suggestions from code review

Co-authored-by: Sarah Rainsberger <[email protected]>

* Update config types

* Move config into `images`

* Move jsdocs

---------

Co-authored-by: Sarah Rainsberger <[email protected]>

* feat: add responsive image component (#12381)

* feat: add experimental responsive images config option

* Apply suggestions from code review

Co-authored-by: Sarah Rainsberger <[email protected]>

* Update config types

* Move config into `images`

* Move jsdocs

* wip: responsive image component

* Improve srcset logic

* Improve fixture

* Lock

* Update styling

* Fix style prop handling

* Update test (there's an extra style for images now)

* Safely access the src props

* Remove unused export

* Handle priority images

* Consolidate styles

* Update tests

* Comment

* Refactor srcset

* Avoid dupes of original image

* Calculate missing dimensions

* Bugfixes

* Add tests

* Fix test

* Correct order

* Lint

* Fix fspath

* Update test

* Fix test

* Conditional component per flag

* Fix class concatenation

* Remove logger

* Rename helper

* Add comments

* Format

* Fix markdoc tests

* Add test for style tag

---------

Co-authored-by: Sarah Rainsberger <[email protected]>

* feat: add crop support to image services (#12414)

* wip: add crop support to image services

* Add tests

* Strip crop attributes

* Don't upscale

* Format

* Get build working properly

* Changes from review

* Fix jsdoc

* feat: add responsive support to picture component (#12423)

* feat: add responsive support to picture component

* Add picture tests

* Fix test

* Implement own define vars

* Share logic

* Prevent extra astro-* class

* Use dataset scoping

* Revert unit test

* Revert "Fix test"

This reverts commit f9ec6e2.

* Changes from review

* docs: add docs for responsive images (#12429)

* docs: add responsive images flag docs

* docs: adds jsdoc for image components

* chore: updates from review

* Fix jsdoc

* Changes from review

* Add breakpoints option

* typo

---------

Co-authored-by: Sarah Rainsberger <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs pr pkg: astro Related to the core `astro` package (scope)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants