Tips & Best Practices
Best Practices Using SA5's User Info Library
Use the userInfoChanged
Callback Effectively
userInfoChanged
Callback EffectivelyIf you want to make special use of user data in your custom code, SA5's userInfoChanged
callback is the best place to obtain that data once it's loaded.
Note that this function will be called several times as the user information is assembled from multiple sources asynchronously. This is more robust and more performant as it allows you to use information as soon as it's available, rather than waiting for everything to load.
How to determine when the data you need is loaded
For convenience, the User object contains metadata describing what has already been loaded. This is stored in the user_data_loaded
sub-object, which contains 4 fields;
user_data_loaded.email
is true if the user's email address has been loadeduser_data_loaded.account_info
indicates whether basic account-info has been loaded, including the user's name and email-marketing preferences.user_data_loaded.custom_fields
is true if the user's custom fields have been loaded. These are any custom-defined fields you've defined in Webflow memberships.user_data_loaded.access_groups
is true if the user's access groups have been loaded ( not yet supported ).
To use that in your callback, just check for the kind of data you're needing, before you attempt to use it. This is how to determine if e.g. user.name
is blank, or just not loaded yet.
Site-wide v. Page-specific Callbacks
In some cases, you may want a site-wide handler that display information on all pages, such as the user's name in the nav. In other cases, you want special code to run only on a specific page.
SA5 was designed to support eventing at both levels. Simply repeat the code block pattern shown above site-wide or on any page, and both handlers will be called.
IMPORTANT: We use this feature regularly at Sygnal however it has not widely been tested by the BETA community. Use with caution.
DEPRECATED - SA4 Notes
SA5 Upgrade changes how callback events work, so the docs below are considered out of date.
Site-wide v. Page-specific Callbacks
Separate site-wide v. page-level user data processing.
A common need is to have special page-level user data processing to build a dashboard or other user-specific information- however those element only exist on one page.
On your specific page, your function might then look like this;
Keep in mind, in JS you can do anything you want with the user data. Modify tracking URLs, pre-populate form fields, customize user experiences and so on.
Last updated