-
Notifications
You must be signed in to change notification settings - Fork 205
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
Support getting started guide on Daml Hub #12878
Conversation
5d24bd0
to
a0c5a0b
Compare
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.
Approach looks solid to me
// Locally we infer it from the token. | ||
export type PublicParty = { | ||
usePublicParty: () => string | undefined; | ||
setup: () => any, |
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.
could setup
be typed as () => void
?
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.
good point, thanks! changed!
This is annoyingly complex so let me try to provide an explanation for the changes: 1. On Daml hub, we need to use a separate token for the public party and the user party. 2. This means that we need separate contexts. I cannot get access to the default context (not exposed) so annoyingly even for the user context we need to use a custom context 3. The way to get access to the public party in Daml hub is via a hook that reads it from the context. However, we cannot call that within the login callback so the way things work now that we login immediately show a "Logging in..." loading screen while we run the background query. This is actually kinda nice since it means something happens immediately after clicking login. I’m sure there are better ways of handling this, my react foo is very weak but this is what I managed to get to work. Tested locally as well as on Daml hub and both work fine. changelog_begin changelog_end . . . . . . .
43318a8
to
73d6897
Compare
This is annoyingly complex so let me try to provide an explanation for
the changes:
and the user party.
the default context (not exposed) so annoyingly even for the user context we need to
use a custom context
hook that reads it from the context. However, we cannot call that
within the login callback so the way things work now that we login
immediately show a "Logging in..." loading screen while we run the
background query. This is actually kinda nice since it means
something happens immediately after clicking login.
I’m sure there are better ways of handling this, my react foo is very
weak but this is what I managed to get to work.
Tested locally as well as on Daml hub and both work fine.
changelog_begin
changelog_end
Pull Request Checklist
CHANGELOG_BEGIN
andCHANGELOG_END
tagsNOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with
/AzurePipelines run
totrigger the build.