TODO demo/pagination

[jaekwon]

TODO someone should try to complete this PR. The immediate todos are marked by XXX.
@moul can you please assign to someone who wants to work on gno programming?

[proggR]

See: #866, or for a deeper dive the README @ the package posed for review.

Literally just posted an issue (#869) + self-critique (largely that encapsulation is needed for most of the core structs) related to it. The issue I've framed largely revolves around an API "renderer" extended version of the supposed web package that supports not just MD/Gnoland supported responses, but instead various encoding types including HTML and JSON. The JSON/potential API oriented angle to the submitted v0 is especially of interest to me, since with this web/rendering angle already going on, Gnoland's "Render" hook isn't limited to just being a Markdown renderer, but could be its own Alchemy/Infura if it wanted to... which would be ridiculously potent IMO. Why should we as smart contract/dApp devs care about what some third party says about the state of the chain (or more commonly, and IMO annoyingly, its events), if the chain itself could be the source of event data via a self-referential API?

To that end, I feel like the resolve of #575 will be of consequence to determining how the API/JSON oriented rendering support would look (especially if a self-determined Alchemy/Infura-esque functionality is chased), so I'd love feedback on that, while also being more than happy to delve into pagination (which IMO will likely depend a lot on the underlying contract/package implementation and the datatypes used, but would be happy to discuss a version that's more implementation agnostic.... re-inventing the wheel in general form is about my favorite thing to do, since there's also nothing new under the sun so... that's realistically all we ever do :P)

Happy to discuss more :)

[thehowl]

Hi @proggR! Thank you for your comments, they are useful but I think they fall a bit out of scope here. If you still want to discuss them, I propose taking over the conversation to #866 and #869. (I know you have not received much feedback, we're trying our best to do good github issue/PR management but we're still largely improving). If you're still interested working on this mention me on either of them and I can give you my 2cs and help you drive this forward.

As for this PR, seeing as the work is being continued by @Doozers in #883, I am closing it for clarity in our PR lists; and proposing that PR be re-created to target master directly.