feat: add initialImageMasking to mirror frog:image meta tag
#268
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
@dalechyn is attempting to deploy a commit to the wevm Team on Vercel. A member of the Team first needs to authorize it. |
dalechyn
force-pushed
the
fix/wrangler-self-request
branch
from
6f4e9d3
to
531092c
Compare
|
I've some more context about this: |
| context.status === 'initial' && this.initialImageMasking | ||
| ? `${context.url}/image` | ||
| : imageUrl |
There was a problem hiding this comment.
What was the motivation behind this behavior again? I wonder if we can avoid it altogether so we don't have to do these workarounds which don't function well in other environments.
There was a problem hiding this comment.
As far as I understand by the code, and this PR the reason was to make the first frame dynamic. Say you have the frame:image metatag pointing to myFrame.com/image which is cached by warpcast. You can't put a static image in that route, so the dynamic image must be somewhere else so that when warpcast calls the /image path a function returns the image from the dynamic attribute in the meta tag. Btw I'm not sure this is not a bug from the warpcast team. the cache-control thing they did doesn't seem to work intuitively. Probably the best is reach out to them and find a clean solution.
There was a problem hiding this comment.
What was the motivation behind this behavior again? I wonder if we can avoid it altogether so we don't have to do these workarounds which don't function well in other environments.
It was added to support refreshing of the first frame image.
There are basically two rules we have to comply to:
- image response must have a
Cache-Controlheader; - image url must be the same across "refreshes".
The latter was the focus, as before #222, the initial frame image url image always depended on the image itself (as it is compressed and put to query), which makes refreshing never possible.
frog:image was introduced to store the full url while fc:frame:image stays the same across updates.
seeing someone running on vercel edge having the same issue. not sure this is cloudflare related |
Thank you will check it with vercel template. |
Previously, `frog:image` meta tag was used as a workaround that held the full image URL which has an `image` query parameter that contains a compressed serialized image itself. However, initial frame image doesn't have `c.frameData`-based constraints as it is not present on the initial render. This change moves the initial image render responsibility to the `/image` handler itself, removing the request from an `/image` route one level up to get the full URL from `frog:image`, and removes this meta tag as well. Double request or a request within self has created issues with wrangler deployments (that I tried to fix in wevm#268 by opting out from `frog:image` tag and falling back to long initial frame image URL), and created issues within Vercel Edge deployments that treat such a request as an "Infinite" one. Supersedes wevm#268.
|
Closing in favor of a general solution that drops #271. |
Previously, `frog:image` meta tag was used as a workaround that held the full image URL which has an `image` query parameter that contains a compressed serialized image itself. However, initial frame image doesn't have `c.frameData`-based constraints as it is not present on the initial render. This change moves the initial image render responsibility to the `/image` handler itself, removing the request from an `/image` route one level up to get the full URL from `frog:image`, and removes this meta tag as well. Double request or a request within self has created issues with wrangler deployments (that I tried to fix in #268 by opting out from `frog:image` tag and falling back to long initial frame image URL), and created issues within Vercel Edge deployments that treat such a request as an "Infinite" one. Supersedes #268.
No description provided.