Added middleware examples for modifying responses#177
Added middleware examples for modifying responses#177
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
@ggomaeng is attempting to deploy a commit to the wevm Team on Vercel. A member of the Team first needs to authorize it. |
|
|
||
| app.use(async (c, next) => { // [!code focus] | ||
| await next(); // [!code focus] | ||
| const isFrame = c.res.headers.get('content-type')?.includes('html'); // [!code focus] |
There was a problem hiding this comment.
If there is a better way to check if response is a frame, please update this 🙏
There was a problem hiding this comment.
Maybe extracting meta tags from head and checking if fc: or frog: are present?
There was a problem hiding this comment.
True, but it would also require an additional conditional statement to check if content-type is not application/json in case of transaction responses when used as a global middleware.
There was a problem hiding this comment.
true, but for extending meta tags responses maybe it would make sense to add such to FrameResponse itself?
for such middlewares lots of checks have to be performed carefully which is not really dx friendly.
|
Raising this PR again, because another issue came up regarding
0xGets from wevm discord was trying to send ETH to a contract address, however the simulation kept showing that the contract would get reverted since attribution data was added as in the call data. I initially thought that this problem only existed in combination of Even if Metamask merges MetaMask/metamask-extension#23527, this problem would still exist when sending ETH to contract addresses using Frog. Maybe internally frog should omit the attribution flag when using ETH to a contract address in a Warpcast Simulation parameters transaction": {
"method": "eth_sendTransaction",
"params": {
"to": "0xeac856237a85b70338a32b55bf44b13ef1a7811d",
"data": "0xfc000023c0",
"value": "5000000000000000",
"chainId": "8453",
"from": "0x130946d8dF113e45f44e13575012D0cFF1E53e37"
}
},Related discord Conversation: https://discord.com/channels/1156791276818157609/1221669227182821406 |
I believe those are a bit different problems. |
| async (c, next) => { // [!code focus] | ||
| await next(); // [!code focus] | ||
| const txParams = await c.res.json(); // [!code focus] | ||
| txParams.attribution = false; // [!code focus] | ||
| c.res = new Response(JSON.stringify(txParams), { // [!code focus] | ||
| headers: { // [!code focus] | ||
| 'Content-Type': 'application/json', // [!code focus] | ||
| }, // [!code focus] | ||
| }); // [!code focus] | ||
| }, // [!code focus] | ||
| (c) => {/* ... */} // [!code focus] | ||
| ); // [!code focus] |
There was a problem hiding this comment.
the provided example is indeed generic but probably not very DX friendly.
I'd rather see attribution flag added (#172), as this looks as more like a feature frog should support internally.
You're absolutely right. Sounds good and will create a separate PR continuing #172. |
|
Continuing this in #187. Closing this because provided examples hurt the DX. |
2 participants
An extension PR of #172
related - #51
Instead of adding something that might be deprecated in the future, I updated the docs so users can create their own middleware to customize the response to fit their needs.