[WIP] index data on The Graph using subgraph #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When building UI out of arrays, I expect it to work a bit like React
Unfortunately, that's not how JavaScript works. When using a template
literal, when JavaScript encounters an array, it calls `toString()` on
it. The default `Array.prototype.toString()` joins the elements with
a comma, `this.join(',')`.
When a bunch of commas get inserted in between the elements we're trying
to add to the page, things look ugly. So we need to use `join('')` every
time we want to render an array.
Unless! We override the default `Array.prototype.toString`, and make it
join with empty string by default.
An alternative approach would be to use a tagged template, such as:
html`<h1>stuff here</h1> ${myArray.map(...)}`
While I might reach for a tagged template in a larger app where globally
changing Array's default join behavior might cause frustration, this
app is small enough that I think think using the global override seems
more useful.
We want to find all _failed_ DAO creations, in addition to successful DAO creations. As far as our research has determined, the only way to do this is to literally walk every single block from the creation block of our contracts, checking transactions for ones against our contract. 😟 😨 😱 400,000 blocks to scan through. NBD. This does not work, probably because of Infura rate limitations. Where do we go from here? It's probably time to try out The Graph, to see if we can aggregate these stats with their backend, so this frontend can just grab the info it needs over GraphQL.
Rather than parse 400,000 blocks in the user's browser and break Infura's rate limiting, this was an attempt to move this championship-level block parsing to a subgraph on thegraph.com Unfortunately, The Graph's Ethereum API does not currently provide a way to find failed transactions. I've requested such support here: graphprotocol/support#51 If we're going to only show successful DAO creations and info about each of these, we may still want to go with The Graph, rather than process all of this data on the user's machine. If we go that direction, we can use `eventHandlers`, rather than `blockHandlers` or `callHandlers`. * `callHandlers` seems cool, but does not work on Rinkeby, and we want Rinkeby stats * `blockHandlers` seems to pretty limited, currently * `eventHandlers` seems like the most common way to use The Graph, from looking through some example subgraphs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rather than parse 400,000 blocks in the user's browser and break Infura's rate limiting (see #3), this attempts to move this championship-level block parsing to a subgraph on thegraph.com
Unfortunately, The Graph's Ethereum API does not currently provide a way to find failed transactions. I've requested such support here: graphprotocol/support#51
If we're going to only show successful DAO creations and info about each of these, we may still want to go with The Graph, rather than process all of this data on the user's machine. If we go that direction, we can use
eventHandlers, rather thanblockHandlersorcallHandlers.callHandlersseems cool, but does not work on Rinkeby, and we want Rinkeby statsblockHandlersseems to pretty limited, currentlyeventHandlersseems like the most common way to use The Graph, from looking through some example subgraphs