Don't run base64 calculation when demanding tracedSVG

[oorestisime]

This is a follow-up on #11981 which addresses the following issue:

when user asks for tracedSVG sharp also calculates base64 image. This leads to longer build times and when using gatsby-image the base64 gets loaded before the tracedSVG.

Updated the unit-test that now shows that base64 should be undefined. let me know if you think i could improve this.

[wardpeet]

Why shouldn't we calculate the base64? Is it because we won't use it anyway as tracedSVG is used as a placeholder image?

[oorestisime]

Yeah when user opts in for tracedSVG then he will want to use that as initial image.

I would guess this also happens in the gatsby-transformer-sharp but i haven't really checked. There's an option base64: false which i think most people use when using tracedSVG. here's some more context oorestisime/gatsby-remark-rehype-images#2 (comment)

[wardpeet]

Well, this means that this would be a breaking change. Couldn't we just introduce base64: false for fluid and fixed and document it. Also, add a TODO that we want to remove this behaviour in gatsby V3 and by default set base64 to false when tracedSVG is used.

[oorestisime]

What do you mean a breaking change? Generating tracedSVG placeholders in plugin-sharp during fixed and fluid processing was added like two days ago.
I mean ok it is a breaking on the paper but i am not sure users opted in already and if they did they would have found the behavior problematic as well no? I am probably missing something here!

[wardpeet]

no no, the breaking change is removing base64 when tracedSVG is true. Now it generates base64 always even before your fix from 2 days ago.

[oorestisime]

But before the fix it wasn't generating tracedSVG at all during fluid or fixed processing :D any way we can discuss this on discord or somewhere more live? i am probably missing something!

[KyleAMathews]

I'm not sure I understand this change. Is the problem that base64 is being generated even when it's not needed?

[oorestisime]

Yes, and then in gatsby-image it gets loaded https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-image/src/index.js#L280-L288 even if we ask for tracedSVG.
this will not impact gatsby-transformer-sharp since it is generating tracedSVG by calling directly plugin-sharp and it does not pass the generateTracedSVG option

[KyleAMathews]

gatsby-image only renders what's passed into it. If a query doesn't ask for base64, it's not loaded.

Check our the tracedSVG fragments. They're not querying the base64 field https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-transformer-sharp/src/fragments.js

[oorestisime]

Yeah right but this happens when you can control the query arguments. When another plugin uses fluid or fixed and asks for tracedSVG then base64 would anyway be there since it is generated.

A solution would be to just delete base64 on the third party end but i find this hacky!
Here's the plugin in question https://github.com/oorestisime/gatsby-remark-rehype-images/blob/master/src/index.js it parses custom markdown tags and process the images. Combined with rehypeReact you can get the gatsby-image goodies in simple markdown format.

I am just not seeing any breaking change :/ When user asks fluid or fixed for tracedSVG doesn't it make sense not to generate base64? This will not impact gatsby-transformer-sharp. Unless i am really missing something here, which can totally be the case!

[oorestisime]

Discussed on discord. current implementation is confusing since i am changing options based on another option.
so i will add a new option base64: false and tracedSVG users will need to pass this as well.

In a breaking change we could add placeholderImageType: [tracedSvg, base64]. i guess this would need an issue tagged breaking change and should be done when v3 is on the works?

[wardpeet]

LGTM! thanks for updating this one!