Deprecate defining an image in .frame handler.

[dalechyn]

Here's the deal.

App clients (such as warpcast) fetch a frame in a two-step process:

• fetch the frame (and retrieve image url)
• fetch the image

For a long time, images have been defined in the c.res of app.frame(...) handler (a.k.a in FrameResponse).
It made it easy to work with as images were generated in the same place where the business logic for the actual frame resided, and it served a good purpose for the time being when frames have not been heavily loaded with UI elements.

The way it works is that image is being compressed and placed in the query parameter.

Now, with time, frames became more UI-heavy and FrogUI was one of the reasons to add more "weight" to the image.
On top of that, it was not possible to create "refreshing" initial frames at all.

It made the compressed image string so long that now it doesn't fit in the actual limits, leading to the "Image failed to load" issues.
We've added Image Handler as a way to mitigate that.

Proposal

I propose to deprecate defining an image in .frame handler and have developers to always explicitly define a separate .image handler.
With #419 implemented, it should not be a huge hassle to do that.

[christopherwxyz]

i support this. image generation should be separate from the application logic and state. frames will get heavier and heavier with more utility.

[Complexlity]

Just to add, currently, unlike the frame handler, the image handler does not accept strings i.e external urls.
One other model would be, the frame handler would only accept strings and not jsx components.
Then the image handler would accept those components.

I think you can't really "remove" the image handler from .frame?
i.e you still have to fetch the frame options first then use the image url to fetch the image but this time it goes to the image route (or an external server).

[dalechyn]

One other model would be, the frame handler would only accept strings and not jsx components.

That's exactly the route that I look to implement.

i.e you still have to fetch the frame options first then use the image url to fetch the image but this time it goes to the image route (or an external server).

Not sure what options are you referring to, but currently if the passed image in frame handler is a string, adding imageOptions is disallowed.
The only "related" option from frame handler that image handler could use is imageAspectRatio (for changing default frame dimensions), but that would require many other changes to be implemented and seems to be irrelevant to do so.
I might be missing something, if I do please add some!