Sign in guards & dialog usage

[joepio]

Currently, the sign-up and sign-in UX in the browser isn't optimal:

• We don't have a register button (#245)
• When the uses sees an invite, and presses sign in, the page does not redirect to where the invite was pointing
• The existing behavior (for checking if a user is present) is inconsistent:
  • Chatrooms have no guard, they just throw errors if a guest tries to send a message
  • Edit pages show a warning message at the top
  • New buttons redirect to sign in + toast notification

What I want, is an easy to use and coherent UX.

Sign in Guards

I think we could have some sort of wrapping component that functions as a guard. If you press any actions inside it, a modal opens that asks you to sign in. This could also show the same register logic for #245.

I think its API is simply an invisible component that wraps other components:

<SignInGuard>
  some form or button or whatever that requires an Agent
</SignInGuard>

@Polleps thoughts?

Modal for instructions for dealing with secret

• When creating a new agent, instruct user to save their secret somewhere safe. Copy to clipboard. Tell about password managers.
• This should probably use the Dialog component

[Polleps]

This sounds like a good idea. Maybe something like:

enum Permission {
  Read,
  Write,
  ReadWrite,
}

interface GuardProps {
  /** Subject to check for permissions, if not specified Guard will only check if an agent is present. */
  subject?: string;
  /** When the agent does not have the required permission this fallback will be rendered instead. If not specified it defaults to basic error message with login link */
  fallback?: React.ReactNode;
  /** If true don't render anything if check fails */
  noFallback?: boolean;
  /** Check these specific permissions (Only needed if subject is set.) */
  permission?: Permission;
}

The component would have a basic fallback component that renders an error message when there's no sufficient permissions and a sign-in link if no agent is set. We should also provide these as building blocks for custom fallbacks in cases where these are needed (e.g. a card that has a greyed out silhouette with a message). It should also provide the option to not render a fallback at all since there are times when not showing a button is enough.