feat: Hanko elements with flow api #1443
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
hanko-elements
work with the new flow API<hanko-login>
and<hanko-registration>
Implementation
The
AppProvider
now contains the state handlers used by the SDK to dispatch the flow api states. A state handler either handles the respective state itself and performs another request to the flow API, or leads to rendering of a page. Each page corresponds to a state in the flow and includes the logic to collect user input and perform a flow action.Because flow states cannot be mapped 1:1 to a page, the difficultly arises that on one hand, when a new state occurs, the page should not change, and on the other hand, the page may need to change even though the state has not changed and no further request to the flow API has been made yet.
An example of the first case would be that the flow API jumps into the passkey-onboarding sub-flow, but the login-init page should still be displayed. However, this page can only be generated with the response of the login-init state. An example of the second case would be that you are currently in the profile state, and when clicking "delete account", you should land on a different page, although this is not represented by a state.
To enable these cases, including error handling and controlling other states in the UI (currently enabled/disabled form fields and links, or the loading spinner on the corresponding UI element, etc.), some useState hooks have been moved to the
AppProvider
so that certain states can be established at a higher level. Also, some pages use a hook to cache the state object, so that a re-rendering of the respective page, which refers to a specific state, is possible even though the flow is currently in a different state. Other changes include generating the forms and input fields based on the information from the flow API response.Todos