Update the composites guide #37
Conversation
|
|
||
| // Replace by the path to the encoded composite file | ||
| await writeEncodedComposite(composite, './my-composite.json') | ||
| await writeEncodedComposite(composite, './__generated__/definition.json') |
There was a problem hiding this comment.
calling this json file definition might cause confusion with the definition file resulting after running writeEncodedCompositeRuntime, I think it would be a good idea to leave it as my-composite.json
| @@ -33,7 +33,7 @@ Let’s say you have a model written in a `my-schema.graphql` file. To convert t | |||
| <TabItem value="cli"> | |||
|
|
|||
| ```bash | |||
| composedb composite:create my-schema.graphql --output=my-composite.json --did-private-key=your-private-key | |||
| composedb composite:create my-schema.graphql --output=./__generated__/definition.json --did-private-key=your-private-key | |||
There was a problem hiding this comment.
This command does return a simple json file instead of a file inside the __generated__ subdirectory, I mean it will create the output where the users specifies, but then they might confuse this with the definition json file used in the runtime when using the composedb server that is autogenerated by the writeEncodedCompositeRuntime function
| ``` | ||
|
|
||
| </TabItem> | ||
| </Tabs> | ||
|
|
||
| This will create a file called `my-composite.json` which contains the composite in JSON. | ||
| This will create a file called `definition.json` which contains the composite definition in JSON. |
There was a problem hiding this comment.
This was correct as it was before.
|
I think there's some confusion here between the encoded composite definition, which is a JSON file representing the composite that can be shared by developers to make their composite reusable by other developers, and the runtime definition which is needed by the ComposeDB runtime package to generate the GraphQL schema. |
Linear Issue
The problem:
Our composites guide has been missing a few steps (e.g. how to compile the composite and produce the .js runtime definition that is used in JavaScript configuration example).
On top of that, the file names haven't been consistent with the names used in other guides as well as CLI vs JavaScript examples on the page.
Proposed solution