Introduces new web components <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.
Description
hanko-elementswork with the new flow API<hanko-login>and<hanko-registration>Implementation
The
AppProvidernow 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
AppProviderso 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