-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve SDK documentation #415
Conversation
No New Or Fixed Issues Found |
Deploying contributing-docs with Cloudflare Pages
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice LGTM just a small typo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few tweaks, up to you.
Co-authored-by: Matt Bishop <[email protected]>
`Client` struct. Below is an example of a generator extension for the `Client` struct. | ||
|
||
```rust | ||
pub struct ClientGenerator<'a> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought: I know this is an established format but to me ClientGenerator
sounds weird, like it's something that generates clients. It's the same thing with the other client extensions, e.g. ClientVault
which sounds like there are multiple vaults and this one belongs to the Client
.
On the other hand ClientGeneratorExt
sounds very reasonable, it's a Generator Extension
for the Client
.
I don't think I would've reacted to this if we would've just passed around the Client
struct and simply applied Extensions
to it, i.e. Client.password(...)
, but as it is now, we are actually creating secondary "sub-clientswhich themself have a reference to the
Clientinstance.
Client.generator()` actively constructs a new type of "Client"
Maybe I'm just nitpicking I don't know, but I think we'll have problems referring to things in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open for alternative name schemas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Hinton
Well my suggestion is to flip the name from ClientGenerator to GeneratorClient, not that big change considering how big my previous message was xD
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me. Mind creating a jira issue and tackling this mountain of a task :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎟️ Tracking
📔 Objective
Add further SDK documentation.
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:
) or similar for great changes:memo:
) or ℹ️ (:information_source:
) for notes or general info:question:
) for questions:thinking:
) or 💭 (:thought_balloon:
) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:
) for suggestions / improvements:x:
) or:warning:
) for more significant problems or concerns needing attention:seedling:
) or ♻️ (:recycle:
) for future improvements or indications of technical debt:pick:
) for minor or nitpick changes