Update readme for client and other packages#1457
Conversation
pileks
left a comment
There was a problem hiding this comment.
Overall LGTM! Comment is non-blocking.
| resolvers: [ | ||
| new RecursiveResolver( | ||
| new PackageToWrapperCacheResolver(wrapperCache, [ | ||
| new ExtendableUriResolver(), |
There was a problem hiding this comment.
Do we have any docs that explain the various resolvers, at least the ones that come with Polywrap by default?
This might help developers set up their own resolution logic.
I'm thinking we could add this to packages/js/uri-resolver-extensions/README.md and reference it here? @nerfZael thoughts?
There was a problem hiding this comment.
Imo that's a good idea. I can work on it soon. I was also thinking to write more detailed reference documentation (in the readme) for the client config builder since it's becoming so important.
It would be cool to create good reference docs (as readmes) for wasm-js and plugin-js, and really every package.
There was a problem hiding this comment.
Ideally we'd have the package creators also write up documentation, or at least a basic outline of it (with functional details), and have someone else (e.g. me, you, any volunteer) fix it up to spec.
…ption of polywrap client in readme to core client; replaced "queries" word with "invocations"
…tion to client config builder README.md
… elsewhere for interface types
…e pulled into readme by doc-snippets
|
Should we consider merging this and opening documentation issues for the remaining packages? |
…eadme # Conflicts: # packages/js/client-config-builder/src/bundles/getDefaultConfig.ts # packages/js/core-client/src/PolywrapCoreClient.ts # packages/js/core/src/interfaces/uri-resolver.ts # packages/js/test-env/src/index.ts
Yeah, I think that's a good idea. It will prevent later work fixing merge conflicts. |
…eadme # Conflicts: # packages/js/client-config-builder/package.json # packages/js/client/package.json # packages/js/core-client/package.json
dOrgJelli
left a comment
There was a problem hiding this comment.
This all looks great! Just a few improvements I think are needed before merging.
|
|
||
| ### Constructor | ||
| ```ts | ||
| * Instantiate a ClientConfigBuilder |
There was a problem hiding this comment.
This section doesn't appear to be rendering correctly, it's missing the starting /*
| ``` | ||
|
|
||
| ## Methods | ||
| ## Types |
There was a problem hiding this comment.
Above this line, in the introduction section, I think it could use some work. A few thoughts:
- I don't think "DSL" is properly used here.
- Ideally all code snippets should be from-source so that they remain up-to-date, so this one that's not a snippet worries me as it can become out-of-date.
- I think should start with introducing the main concepts a user must understand to get started. We can introduce the intended usage pattern of
init -> configure -> build, and we can point to sub-sections for each. "Initialization" shows the constructor signature. "Configure" shows the different "add..." methods. etc - Lastly, in this intro section, having an e2e example snippet (taken from a buildable source file) would be great to have.
So in summary:
- Brief Description
- Intro Concepts (linking to reference sections further down)
- E2E Example Snippet
Apologies if this is overly verbose :P
There was a problem hiding this comment.
i reworked this intro and used snippets as suggested in your other comment
| } | ||
| ``` | ||
|
|
||
| ## ClientConfigBuilder |
There was a problem hiding this comment.
Can we group the ClientConfigBuilder and ClientConfig sections underneath a Reference section?
| "inline": false | ||
| }, | ||
| { | ||
| "pattern": "/* $: {SNIPPET_NAME} */", |
There was a problem hiding this comment.
Why do we have {SNIPPET_NAME} here, but not in the above start token?
There was a problem hiding this comment.
Oh nvm, I think I figured it out, it's because this one is "inline" so it can't know where to extract the snippet name from like it can in the pattern above. Is that correct?
There was a problem hiding this comment.
right, that's correct. The {SNIPPET_NAME} helps define a regex pattern.
| ### Invoke a wrapper | ||
|
|
||
| ```ts | ||
| await client.invoke({ |
There was a problem hiding this comment.
We should convert this to a code snippet so we make sure it runs. Maybe extract it from the tests folder or something.
There was a problem hiding this comment.
Also it seems like we have this problem with the other READMEs I'm seeing here, all the example code snippets aren't being extracted from source. Might I suggest us adding an examples/ folder next to the src/ folder where we keep these examples? They would be built so we can make sure they are correct, but their artifacts will not make it into the build/ folder so they do not get published with the built src/ files.
There was a problem hiding this comment.
Another option is to create a src/__snippets__ folder, that lives alongside the src/__tests__ folder.
There was a problem hiding this comment.
I added examples/ folders and set up snippets in client, core-client, client-config-builder, and test-env.
…dded "build:readme" to build scripts and added "build:fast" options; added "Reference" section headers to readmes
…tract snippets from examples
|
@dOrgJelli Your suggestions were really good. Thanks for looking at this! I think I addressed all of your comments: I updated the client config builder readme. All code examples now use snippets that build with I think it's in much better shape and ready for a new review! |
…eadme # Conflicts: # packages/js/client-config-builder/src/ClientConfigBuilder.ts # packages/js/core/src/uri-resolution/UriResolutionContext.ts # packages/js/test-env/src/index.ts # yarn.lock
This is a draft PR for the purpose of preparing readme documents for the 0.10.0 release. The readme docs will be used for reference documentation on our docs site.
Steps to update a typical readme with reference documentation:
doc-snippetstokens around the comments and types or method signatures.doc-snippetsCLI tool to inject the snippets into the readme doc.You can copy the
doc-snippetssetup and configuration from repos where this has been done.The aforementioned steps won't make sense for every package. Feel free to adapt as necessary!
TODO: