Existing URL parameters are removed

[angeloashmore]

Describe the bug

If a URL has existing URL parameters, such as rect for cropping, they are removed after the URL is transformed for url, fluid, fixed, and gatsbyImageData fields. Only parameters given to defaultImgixParams, the GraphQL field's arguments, and those produced by the library itself (such as during srcSet generation) are included.

To Reproduce

Provide a URL to the plugin with a rect parameter. Using buildFixedImageData as an example:

import { buildFixedImageData } from '@imgix/gatsby'

const url =
  'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?auto=compress,format&rect=0,1100,6091,1865&w=980&h=300'
const fixedImageData = buildFixedImageData(url, {
  w: 200,
  h: 100,
})

console.log(fixedImageData)

The following is logged:

{
  width: 200,
  height: 100,
  src: 'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined',
  srcSet: 'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&dpr=1&q=75 1x,\n' +
    'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&dpr=2&q=50 2x,\n' +
    'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&dpr=3&q=35 3x,\n' +
    'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&dpr=4&q=23 4x,\n' +
    'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&dpr=5&q=20 5x',
  srcWebp: 'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&fm=webp',
  srcSetWebp: 'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&fm=webp&dpr=1&q=75 1x,\n' +
    'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&fm=webp&dpr=2&q=50 2x,\n' +
    'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&fm=webp&dpr=3&q=35 3x,\n' +
    'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&fm=webp&dpr=4&q=23 4x,\n' +
    'https://images.prismic.io/gatsbygts-angelo/72d75488-437f-4e91-bb8a-4a03ef325714_patrick-robert-doyle-eb8dmXNOGP4-unsplash.jpg?ixlib=gatsbyTransformUrl-1.6.2&fit=crop&w=200&h=100&ar=undefined&fm=webp&dpr=5&q=20 5x'
}

Note the exclusion of ?auto=compress,format&rect=0,1100,6091,1865 in the URLs, which may be crucial to the image's representation.

Expected behaviour

The URL should include original parameters. Any parameters added by the plugin should be merged over the existing params.

Information:

• imgix/gatsby version: 1.6.3

Additional context

I believe this is the behavior of @imgix/js-core's buildURL method. If the core JS library is to be left as is, could the Gatsby plugin automatically read the URL parameters and merge them into the top of the final params?

For example, the URL field config could add ...existingUrlParams above defaultParams here:

gatsby/src/modules/gatsby-source-url/createImgixUrlFieldConfig.ts

Line 57 in 8f921b6

defaultParams ?? {},

See: https://github.com/imgix/js-core/blob/e168e5da6874591f657ce6de95257fe5414a361c/src/index.js#L47-L60

[frederickfogerty]

Hey there @angeloashmore, thanks for opening this issue. So this is a peculiar issue which we had already slated to discuss internally next week since it arose in one of our other libraries. Essentially this is not as simple as "just make the thing work" since there are some edge-cases here that we have to handle with regards to URL encoding. In short I don't have a resolution here for you yet, but I will update you once we have discussed with the team next week.

[angeloashmore]

Awesome, thank you!

[frederickfogerty]

Hey there @angeloashmore! We discussed this as a team and unfortunately we are not going to fix this due to how we handle URL encoding.

Essentially, the src or path parameters in our SDK libraries require an un-encoded value to be passed through, and then our contract with the user is to encode this and ensure it is decoded correctly on our (imgix's) servers. This is not a trivial task and there are lots of edge cases. Our encoding will also encode ?, so we can not use this to split out the query params reliably.

I hope this makes sense! We discussed this at length yesterday including some other options, including:

• allowing the user to pass an encoded path to our library, in which we could reliably use the ? as the start of the query params and implement this behaviour. Unfortunately URL encoding is so gnarly that this would cause way more pain than it would solve.
• requiring the user to pass the url/src/path un-encoded apart from ?, which they would have to encode. This seemed like a smell so we steered away from this.

In saying this, there are two bugs that we have seen in this issue, namely that a) the path should not be truncated at the ? and the whole path should be encoded, and b) that ar=undefined in all your URLs. We will fix both of these shortly.

I'm going to close this issue but please feel free to comment if you have any suggestions or ideas. I have to say we're pretty set on this decision but are always open to consider other legitimate ideas.

[angeloashmore]

Hey @frederickfogerty, thanks for the detailed update. Totally understandable, and I'm sure there are edge cases I can't imagine myself.

The specific issue I have is something that, I think, can be handled at the consumer level (in this case, gatsby-source-prismic and gatsby-plugin-prismic-previews). I'll post back here if it there are any major challenges.

Re: the ar=undefined bug, thanks for seeing that. I figured I'd leave it out of this issue since it's unrelated, but a fix would be appreciated. Thanks! 🙏

[frederickfogerty]

Glad that we could work this out and glad that it can hopefully be handled at the consumer level. Let me know if you'd like to brainstorm any ideas about it together, and please let me know what you come up with, as it's probably a problem that other users of this library will run into, so I'd love to add it to the README.

Re: the ar bug, we'll get onto that shortly. Have a good weekend!

[angeloashmore]

Hey @frederickfogerty, I was able to come up with something that seems to work in most cases. I'll explain why I say most later.

https://github.com/angeloashmore/gatsby-source-prismic/blob/124b054bbff5ac5b6ceba103e494b580fd37f6ce/packages/gatsby-source-prismic/src/builders/buildImageBaseFieldConfigMap.ts#L45-L89

This function takes in a field config created via imgixGatsby.createImgixGatsbyTypes (where imgixGatsby is @imgix/gatsby) and updates the imgixParams field argument with the existing parameters from the source image URL.

All tests are passing except for gatsbyImageData with existing w and h parameters.

Here is a failing test: https://github.com/angeloashmore/gatsby-source-prismic/blob/124b054bbff5ac5b6ceba103e494b580fd37f6ce/packages/gatsby-source-prismic/test/create-schema-customization-image.test.ts#L346-L349

Basically, if someone sets a w or h parameter in the imgixParams argument (which, with the approach I've taken above, also means if it already exists in the URL), then it overrides the w and h parameters set by the gatsbyImageData generator. Effectively, setting w and/or h means you lose automatic responsive optimizations.

This happens here:

gatsby/src/modules/gatsby-plugin/buildGatsbyImageDataBaseArgs.ts

Lines 18 to 20 in 32364af

	w: width,
	h: height,
	...(typeof opts.imgixParams === 'object' && opts.imgixParams),

Would you be open to swapping the order of the property spreading? It would become this:

const src = client.buildURL(imageName, {
  ...(typeof opts.imgixParams === 'object' && opts.imgixParams),
  w: width,
  h: height,
});

This matches the approach taken with the gatsby-image field config builders:

gatsby/src/modules/gatsby-plugin/objectBuilders.ts

Lines 158 to 164 in 32364af

	const imgixParams = {
	fit: 'crop',
	...defaultParams,
	...args.imgixParams,
	w: width,
	h: height,
	};

[angeloashmore]

Opened a PR so it can be merged in easily if this change is okay: #125

[frederickfogerty]

Thanks for the explanation @angeloashmore, this sounds like a good solution! I'll respond to the width and height override over on that PR.

[angeloashmore]

Great, thanks. With that PR, I think I'm all good with the Prismic integration.