Open thedavidmeister opened 6 months ago
@thedavidmeister should we just allow for optional entrypoint to be defined for a scenario - so it doesn't have to be #chart-data
?
then we can disallow deployments
that use a scenario with a custom entrypoint.
@thedavidmeister should we just allow for optional entrypoint to be defined for a scenario - so it doesn't have to be
#chart-data
?then we can disallow
deployments
that use a scenario with a custom entrypoint.
yeah that makes sense to me
problem
we have an awkward situation where we want to plot things that aren't necessarily relevant to the final prod output
for example, we might want to plot some derived value like x/y that is helpful to visualise but doesn't feed into the final amount/ratio
another example would be wanting to plot things against block timestamp, where the timestamp doesn't actually change the outputs
adding a bunch of extra calculations to the strat just for visualisations makes things complex and fragile because it means we're messing with the core strat logic every time we want to visualise some data, and it also adds gas to the final onchain deployment
https://github.com/rainlanguage/rain.dex.pubstrats/pull/54/files#diff-7e652b6de7bb90e6db187e5017c972873c2d1920750b9791e5f65aff81e787b6R555 is an example of this happening, we have to jump through quote rebinding hoops just to build a basic dashboard
solution
allow for a new
#chart-data
binding convention that is used as a third entrypoint alongside#calculate-io
and#handle-io
while simulating, but is not included in the rainlang upon deployment onchainif the chart data binding wants to plot things from
calculate-io
orhandle-io
it can by using e.g.call<'calculate-io>()
and pulling as many items off the stack as it wantsthis basically inverts the pattern of having the chart data need to be called from inside calculate-io, and rather makes the charting data into a wrapper that calls into calculate/handle as needed and then derives additional chartable information