You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I work on a web app that is a rollups explorer to support users who are developing with Cartesi technology. That said, I am working on a UI to support the developers in defining a JSON abi using the human-readable format that they can use to decode standard abi-encoded data through our App.
Expected
As a user defining my function signatures and structs, if I have a struct as a function return or input parameter and come to change it (e.g. types, param-name or remove a parameter), I expect the generated JSON ABI to reflect these changes.
What is actually happening
It does not consider the change in the struct. It only reflects the update if I change something in the function signature, but if I come back to the same signature, let's say the original function param is Baz baz. After changes to the struct, nothing happens, so changing to Baz baz2 will reflect the change immediately, but then coming back to Baz baz will reflect the old component definitions in the generated ABI.
I checked there isn't already an issue for the bug I encountered.
Anything else?
After ruling out ui-libraries being responsible for any caching, I started looking into the parseAbi(). There is a seeded cache (Map()) that also adds information. However, it does not consider a change in the struct, so the cached data could be marked as stale and skipped to be overridden.
I believe these functions were not designed for prototyping and generating on-demand JSON abi through user input (my case) but rather statically defined in the application itself. So I have a couple of suggestions for a solution.
In the uppermost layer, externalize a not-required Options object-like type for the parseAbi() just like parseAbiParameter. So, that becomes an opt-in situation that does not cause trouble for existing users. e.g. ts type Options = {noCache: boolean} that internally would bypass the caching as I notice some concern comments in the seeding for performance problems with increasing that map.
Do not change the external API. Internally, recognise that important pieces of the cached data have changed and skip the cache read so it is overridden in the process. However, the nature of prototyping and generating on the fly may grow that cache Map.
The text was updated successfully, but these errors were encountered:
Describe the bug
Context
I work on a web app that is a rollups explorer to support users who are developing with Cartesi technology. That said, I am working on a UI to support the developers in defining a JSON abi using the human-readable format that they can use to decode standard abi-encoded data through our App.
Expected
As a user defining my function signatures and structs, if I have a struct as a function return or input parameter and come to change it (e.g. types, param-name or remove a parameter), I expect the generated JSON ABI to reflect these changes.
What is actually happening
It does not consider the change in the
struct
. It only reflects the update if I change something in the function signature, but if I come back to the same signature, let's say the original function param isBaz baz
. After changes to the struct, nothing happens, so changing toBaz baz2
will reflect the change immediately, but then coming back toBaz baz
will reflect the old component definitions in the generated ABI.Link to Minimal Reproducible Example
https://rollups-explorer-sepolia-git-feature-165-add-dec-dd1128-cartesi.vercel.app/specifications/new
Steps To Reproduce
I added a link to the running application.
ABI
Textarea input and check the accordions below, i.e. ABI Signatures and JSON ABI Generated.amount
toprice
and check the JSON ABI Generated accordion; nothing will have changed there.balanceOf
parameter name frombaz
tobaz2
, then check the accordion; it should now change.baz
and check the accordion. The outdated tuple definition should be back.Input data example:
Package Version
1.0.5 (through [email protected])
TypeScript Version
5.3.2
Check existing issues
Anything else?
After ruling out ui-libraries being responsible for any caching, I started looking into the
parseAbi()
. There is a seeded cache (Map()
) that also adds information. However, it does not consider a change in thestruct
, so the cached data could be marked asstale
and skipped to be overridden.List of calls:
I believe these functions were not designed for prototyping and generating on-demand JSON abi through user input (my case) but rather statically defined in the application itself. So I have a couple of suggestions for a solution.
Options
object-like type for theparseAbi()
just likeparseAbiParameter
. So, that becomes an opt-in situation that does not cause trouble for existing users. e.g.ts type Options = {noCache: boolean}
that internally would bypass the caching as I notice some concern comments in the seeding for performance problems with increasing that map.The text was updated successfully, but these errors were encountered: