graphprotocol / docs Goto Github PK

          I agree, if you find a way to make it pass `pnpm lint`, let's put it back!

Originally posted by @benface in #319 (comment)

The functions in the store module (get, set, remove) are a bit confusing right now when subgraph use Bytes as their id; the host interface still requires that the id is passed as a string, for Bytes it needs to be id.toHexString(). For get and set, the difference is hidden by the code that graph-cli generates, so that subgraph authors can say Thing.get(id) no matter whether Thing uses String or Bytes for its ids.

But for remove, users need to use the 'raw' interface and write store.remove(id.toHexString()) which can be confusing.

I don't think we should actually change the calling convention for the store functions; instead, we should document this more clearly and explain how to work with these functions when id has type Bytes.

This was first reported as part of graphprotocol/graph-node#3476

https://thegraph.com/docs/en/release-notes/assemblyscript-migration-guide/

Bytes being case insensitive is a really helpful info for subgraph clients. Couldn't find a mention of this in the docs, and had to gather from Discord

Would be helpful to have a mention of this in the docs, maybe here: https://thegraph.com/docs/en/developing/creating-a-subgraph/#optional-and-required-fields

Although that section looks misplaced. Might be more appropriate to have that as a separate section with a separate heading

sometimes we put, sometimes not - we can add lint rule to always avoid

https://github.com/graphprotocol/docs/blob/main/pages/en/network-transition-faq.mdx#the-graph-network-integration-status-tracker

And maybe in other places too?

In the docs, it says BigInt has the dividedBy() method. It seems this has been updated to div()
Same with BigDecimal. It was renamed to div()
I'm on versions:
"@graphprotocol/graph-cli": "^0.22.3",
"@graphprotocol/graph-ts": "^0.22.1"

          We should add a redirect from `/en/firehose/` to `/en/firehose/README/`. This should ideally be done in 2 places:

• In nginx.conf, for staging and production
• In next.config.js, for local dev with pnpm dev

Originally posted by @benface in #379 (comment)

the “Next” link at the bottom of this page goes to the wrong page (“Dependency installation”; it skips “Overview”, which is the actual next page).

Huh, and on the Dependency installation page, the “Previous” link goes to… the current page. And the “Next” link skips another page, too. (edited)

Clicking on
this page https://thegraph.com/docs/en/substreams/concepts-and-fundamentals/modules/

should take to https://substreams.streamingfast.io/developers-guide/modules

but shows a 403

reported: https://discord.com/channels/438038660412342282/989236488560607262/1113846308067881053

Add * in beta in pages/en/network-transition-faq.mdx
Move to The Graph Network & Hosted Service and add * on `Get Started

It seems the order of pushing event parameters should be the same as the defined event parameters for it to properly work. This would be great to be mentioned in the docs

https://github.com/the-guild-org/docs/tree/main/packages/og-image

Follow up from graphprotocol/contracts#587, the documentation needs to be updated with the new network and contract information.

If I hit "edit page" on the docs landing page (https://thegraph.com/docs/en/) I get a Github 404

parse markdown code-blocks with mine graphql-eslint parser :)

There is some information on this page that is misleading:

Also, I'm not 100% if full-text-search is not supported. I think I heard once that it works.

Small unrelated notes, the link here to the graphman documentation and here does not have the .md extension, and therefore is broken, and is also shown as markdown instead of being parsed as an anchor tag
From @YassinEldeeb

use cspell?

UPDATE:

dapp is not typo here, but anyway spell checker will be nice improvement where dapp could be add as exception

Same design as "subgraphs".

Having

• Operating Graph Node
• Substreams
• Firehose

in there.

Plus moving "Cookbook" under "subgraphs"

Something like this?

  eventHandlers:
    - event: NewEvent(address,address,struct)
      handler: handleNewEvent

I could not find anything related in the docs. Could admin give me some education. thanks.

In https://thegraph.com/docs/en/ the link to "query from an application" is not working.

After fixing an issue we had with the prettier formatting in the `AssemblyScript Migration Guide) I realized some code snippets in translations were incorrect.

The issues I've found are listed below:

• Incorrect compiler messages (eg: quotes on the wrong place)
• Replacing special characters such as ? to ؟ in code (I couldn't find in the current main branch, perhaps this got fixed in the last batch of Crowdin updates? 🤔 )
• Missing code and comments from the original snippet (eg: incomplete line)

It seems dataSources.mapping.entities is not strictly validated with the defined schema and would still work without issues as long as they're not empty in the manifest.

It would be nice to have some more info on how exactly this config is being used, and also of the fact that its not validated with the schema

          This whole thing seems pretty hacky. 😅

Originally posted by @benface in #336 (comment)

https://thegraph.com/docs/en/developing/assemblyscript-api/#type-conversions-reference

The documentation on Debug Forking should have a cautionary remark about its inability to detect Dynamic Data Sources before the fork.

Encoding / decoding ABI - Links to here

User reported that they would like more complex & detailed examples

https://thegraph.com/docs/en/developing/creating-a-subgraph/#recommended-i-ds-for-creating-new-entities

At the moment, the examples in the documentation don't show all the possible values for the network property in data sources. The only way of checking this is by running graph init and seeing the options, and even then you don't have a guarantee that the values in the list are exactly the ones that will end up on the manifest

Might be a useful info to know that changes made in a handler are cached in memory and applied to the store at the end, making them atomic in effect

without blockquote

with

Also check if other available chains are not listed there and if there are other places where chain support is incomplete.

Chains according to hosted service config:

[chains.matic]

[chains.mumbai]

[chains.optimism]

[chains.optimism-goerli]

[chains.fantom]

[chains.bsc]

[chains.clover]

[chains.fuse]

[chains.chapel]

[chains.avalanche]

[chains.fuji]

[chains.celo]

[chains.celo-alfajores]

[chains.mbase]

[chains.moonriver]

[chains.arbitrum-one]

[chains.near-mainnet]

[chains.near-testnet]

[chains.mainnet]

[chains.goerli]

[chains.poa-sokol]

[chains.xdai]

[chains.gnosis]

[chains.aurora-testnet]

[chains.aurora]

[chains.fantom-testnet]

[chains.moonbeam]

[chains.boba]

[chains.zkSync2-testnet]

[chains.harmony]

[chains.arbitrum-goerli]

[chains.cosmoshub-4]

[chains.theta-testnet-001]

[chains.arweave-mainnet]

[chains.osmosis-1]

see graphprotocol/graph-tooling#1296

see graphprotocol/graph-tooling#1340

use rehype-pretty-code with copy code button with The Graph docs theme

more info #314 (comment)

I am learning how to build subgraphs and reading through the docs, and quite confusing the second paragraph on the one-to-many reverse lookups topic which is

"For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived."

Should it be the other way around? As the given example below, a Token can have many TokenBalances, while a TokenBalance can belong to a single Token, so the 'one' side (Token) is "derived", and the 'many' side (TokenBalance) stores the relationship.

type Token @entity(immutable: true) {
  id: Bytes!
  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
}

type TokenBalance @entity {
  id: Bytes!
  amount: Int!
  token: Token!
}

Please support light theme, my eyes are struggling to read dark websites. Thanks!

Last year in feb there was talk about solana support. I was looking for docs but I can't find any?

I searched for hours to no avail, until I had to clone the CLI repo to understand what the flag did. Considering "migrations" is a very loaded term, this should be well documented IMO

In the Developing Page under the sub-heading of Querying and Application Development, in the last line of 2nd paragraph the spelling of time is wrong, check it here . We need to correct it because it could be difficult to understand for some people at first.

I would like to work on the issue to fix the error.

as mentioned when I first try to install it with yarn and checked using graph -v it was giving an error but when I use npm it worked

yarn global add @graphprotocol/graph-cli 
is not working 

npm install -g @graphprotocol/graph-cli
is working