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
{{ message }}
Repository navigation
Commit 50bd2bc
Browse filesBrowse the repository at this point in the historyBrowse files
> This package is **not** included in the main [`codama`](../library) package.
20
20
21
-
## Types
21
+
## Decoded nodes
22
22
23
-
### `ParsedData<TNode>`
24
-
25
-
This type represents the result of identifying and parsing a byte array from a given root node. It provides us with the full `NodePath` of the identified node, as well as the data deserialized from the provided bytes.
23
+
All parsers return the [decoded nodes](../dynamic-codecs/README.md#decoded-nodes) of `@codama/dynamic-codecs`: the `path` of the identified node, the decoded `value`, the `preOffset` and `postOffset` of the cursor, and the decoded nodes of its `data`, absent for instructions without data.
account?.data; // the decoded struct, with its `fields`
32
30
```
33
31
34
-
The `data` is decoded using [`getNodeValueCodec`](../dynamic-codecs) from `@codama/dynamic-codecs`, so it uses the same valueformat. For instance, integers are `bigint`s, struct keys are the raw field identifiers and enums are `{ __kind, __discriminator, data }` objects.
32
+
The `value` uses the value format of [`getNodeValueCodec`](../dynamic-codecs/README.md#value-format). For instance, integers are `bigint`s, struct keys are the raw field identifiers and enums are `{ __kind, __discriminator, data }` objects. The decoded nodes of the `data` keep the node of each value, e.g. to [format](../dynamic-codecs/README.md#formatting) it.
All parsers return `undefined` when the bytes are unparsable: either nothing is identified, or the identified node cannot decode them, e.g. truncated bytes whose discriminator matches.
40
35
41
36
## Functions
42
37
43
-
### `parseAccountData(rootNode, bytes)`
38
+
### `parseAccountData(rootNode, bytes, options?)`
44
39
45
-
Given a `RootNode` and a byte array, this function will attempt to identify the correct account node and use it to deserialize the provided bytes. Therefore, it returns a `ParsedData<AccountNode>` object if the parsing was successful, or `undefined` otherwise.
40
+
Identifies the account node of the provided bytes and decodes them with it.
Similarly to `parseAccountData`, this function will match the provided bytes to an event node and deserialize them accordingly. It returns a `ParsedData<EventNode>` object if the parsing was successful, or `undefined` otherwise.
49
+
Identifies the event node of the provided bytes and decodes them with it.
Similarly to `parseAccountData`, this function will match the provided bytes to an instruction node and deserialize them accordingly. It returns a `ParsedData<InstructionNode>` object if the parsing was successful, or `undefined` otherwise.
58
+
Identifies the instruction node of the provided bytes and decodes them with it.
This function accepts a `RootNode` and an `Instruction` type — as defined in `@solana/instructions` — in order to return a `ParsedData<InstructionNode>` object that also includes an `accounts` array that match each `AccountMeta` with its corresponding account name.
83
+
Parses an `Instruction`, as defined in `@solana/instructions`. It returns a `ParsedInstruction`: the decoded instruction node, plus its named `accounts`, each `AccountMeta` carrying the `identifier` of its instruction account, and the `remainingAccounts` beyond them, e.g. the signers of a multisig.
parsed.remainingAccounts; // [{ address, role }, ...]
95
93
}
96
94
```
97
95
98
-
Note that it uses the instruction's `programAddress` to restrict the search to the matching program — including any of the root node's `additionalPrograms`. When no program of the root matches that address, nothing is parsed: matching an unknown program against another program's candidates would confidently misattribute the data, which matters when the result is displayed to end users (e.g. clear signing).
96
+
It uses the instruction's `programAddress` to restrict the search to the matching program, including any of the root node's `additionalPrograms`. When no program of the root matches that address, nothing is parsed: matching an unknown program against another program's candidates would confidently misattribute the data, which matters when the result is displayed to end users (e.g. clear signing). It accepts the `bytesEncoding` option.
99
97
100
98
## Discriminators
101
99
@@ -110,7 +108,7 @@ Accounts, events and instructions are identified using their `discriminators`, w
110
108
All functions above search the root node's main program as well as its `additionalPrograms`, in that order. Additionally, they all accept an optional `programAddress` option that restricts the search to the programs matching that address. When no program matches, nothing is identified.
The single-non-discriminated-candidate fallback follows the same selection when a `programAddress` is provided. Without one, it stays conservative and only applies to the main program, since bytes alone cannot tell which program a discriminator-less candidate belongs to.
0 commit comments