Skip to main content

User

Reads the currently signed-in user: id, username, email, custom properties, and an authenticated boolean, kept live across session changes.

User mirrors the current session's user. Its value outputs — id, username, email (strings) and one output per custom property on the User class — always reflect the signed-in user, and authenticated (boolean) is true exactly while a user is signed in. The node tracks the app-wide user service: it updates when Log In or Sign Up succeeds, when a stored session is restored, and when Log Out runs or the session is lost, so a single connection from authenticated can gate an entire logged-in UI. changed (signal) fires when the user's data changes. Triggering fetch (signal) re-reads the user from the server, firing fetched and then done on completion, or failure with error (string value) set; completed follows either way. fetched is the value-level announcement — the twin Record node fires it on binding too — and done is this invocation's outcome. It also works inside cloud functions, where it reflects the calling user's session.

When to use it​

The one node to read who is logged in and their properties, anywhere in the app. It performs no actions — pair it with Log In, Sign Up, Log Out and Set User Properties for those.

At a glance​

CategoryCloud Services
Type namenet.noodl.user.User
Available inbrowser, cloud
SSR compatibilitypartial — Sessions live in browser storage; a server render always sees a logged-out user.
Provided bynoodl-runtime

Inputs​

Values​

NameTypeDefaultDescription
runOnChange-userBooleantrueWhether a new value on User properties re-runs this node. On by default; untick to make this input passive so only the control signal runs it

Signals​

NameTypeDefaultDescription
fetchSignal—Re-reads the signed-in user from the backend, which is also how an expired session is discovered

Outputs​

Values​

NameTypeDefaultDescription
authenticatedBoolean—True while somebody is signed in on this device; a server render always sees false
emailString—Email address of the signed-in user; empty while nobody is signed in
idString—Id of the signed-in user record; empty while nobody is signed in
rolesArray—Roles the signed-in user is in, resolved by the server on each session read; empty while nobody is signed in, and not set on backends that do not track roles
usernameString—Username of the signed-in user; empty while nobody is signed in

Signals​

NameTypeDefaultDescription
changedSignal—Fires when a property of the signed-in user changes, including a change another node made
completedSignal—Fires after every invocation, whatever the outcome — wire this to carry on regardless. Failure still fires and still carries its reason, so this cannot hide an error
doneSignal—Fires when a Fetch finished and the outputs below are up to date
fetchedSignal—Fires once the user record has been re-read and the outputs below are up to date

Failure outputs​

NameTypeDefaultDescription
errorString—Why the last read failed; empty until one does
failureSignal—Fires when the user record could not be read, after the reason has been reported on the error channel

Dynamic ports​

This node's port list changes at runtime (runtime-discovered); the tables above may be incomplete for a given instance.

Property outputs include one port per custom user property in addition to the built-in ones.

Ports at runtime​

Beyond the static ports, the editor generates one value output per custom property in the User class schema (stored as prop-<name>, typed from the schema) plus a changed-<name> signal per property (built-ins authData/password/username/email are excluded — username and email have static outputs). In the browser it additionally registers the signal outputs loggedIn (Logged In), loggedOut (Logged Out) and sessionLost (Session Lost), which fire on the corresponding session transitions; these do not exist in the cloud runtime.

Patterns​

  • authenticated → a Group's visible (and through an inverter to the login form): one boolean drives both faces of the UI.
  • loggedOut/sessionLost signal outputs → navigation to the login page: handle forced sign-outs globally.

Watch out for​

  • Storing the user id in your own variable at login time — read id from this node instead so restored and switched sessions stay correct.

Examples​

Log in, show the user, log out

The authentication triangle: Log In takes username/password values and a login signal, firing success or failure (+error). The User node is the session's single source of truth — its authenticated boolean and profile outputs update on login/logout, so UI binds to it rather than to the action nodes. Log Out ends the session from anywhere. Gate visible areas on authenticated, not on the login node's success pulse.

Log In, Log Out, Sign Up, Set User Properties, Condition

Generated

This page is generated from node-catalog-enriched.json. Do not edit it by hand — run npm run docs:nodes to regenerate, and fix the source enrichment instead.