Stackblitz environment + instructions added to README's for solana examples #395
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
There was a problem hiding this comment.
comments on examples/email-auth-local-storage/README.md apply to the rest of the examples as well. let's make sure we update the READMEs and .env.local files within the individual stackblitzes.
also I recall there may have been inconsistencies with env var naming -- are there any changes to upstream back into this tkhq/sdk repo?
overall 👏👏👏
|
|
||
| #### Prerequisites | ||
|
|
||
| To use the example you need the following |
There was a problem hiding this comment.
Let's make sure to include these instructions in the stackblitz repo itself
There was a problem hiding this comment.
Sounds good - I'll keep them here too cause I suspects that folks will still want to use the readme from Github UI than figuring out how to render the one in stackblitz or following along the unrendered markdown file
| @@ -10,6 +10,8 @@ The overall flow for email auth is outlined below: | |||
|
|
|||
| This example contains an auth page as well and enables you to create wallets using an email auth credential. Unlike our other [email auth example](https://github.com/tkhq/sdk/tree/main/examples/email-auth), this does not use an iframe, which typically houses a target embedded key. Instead, a target embedded key is created within the application itself and stored in local storage. | |||
|
|
|||
| You can try this example quickly on Stackblitz -- follow the instructions below | |||
There was a problem hiding this comment.
we can suggest jumping to Step 4 here (and we should be able to add a link to it via markdown)
Summary & Motivation
How I Tested These Changes
Did you add a changeset?
If updating one of our packages, you'll likely need to add a changeset to your PR. To do so, run
pnpm changeset.pnpm changesetwill generate a file where you should write a human friendly message about the changes. Note how this (example) includes the package name (should be auto added by the command) along with the type of semver change (major.minor.patch) (which you should set).These changes will be used at release time to determine what packages to publish and how to bump their version. For more context see this comment.