Which UI do you use?

Custom UI

Pre built UI

Recipe Structure

To explain this, we will look at the emailpassword recipe structure.

The recipeImpl variable

This is an instance of a class that implements the RecipeInterface interface. This interface contains all the functions that drive this recipe - these functions as used by the UI components to run their logic.

The constructor

• It takes the config for this recipe
• This function normalises the recipe config and runs the override function that is provided by the user (or created by us) to initialise the recipeImpl variable.

The getFeatures function

A recipe is divided into features. The emailpassword recipe has three features:

• sign up and in
• reset password
• features of email verification recipe.

Each of these features have their UI which contains:

• feature components: logic and no UI components
• theme components: UI components that are used by the feature components.

The getFeatures functions returns a map of URL path to feature components. For example, the emailpassword returns:

• {websiteBasePath}/ => sign in / up feature component.
• {websiteBasePath}reset-password => reset password feature component
• • the email verification's getFeatures function's return.

The routing logic then renders the appropriate feature component based on the current URL.

Multiple recipes could have the same path, so we need to decide for a given path, which recipe's feature components to show. This can be done via the matches function:

• The simplest strategy to match is to see the rid query params of the page and based on that, we will load that recipe's feature components.
• Sometimes, the rid is not there (for example in case of OAuth callback page). In that case, we use the another strategy.

Recipe interface & implementation

The recipe interface is a set of functions that dectate how this recipe's logic behave. For emailpassword, the recipe interface is here. These functions are used by the UI components.

A recipe implementation is the default implementation of the recipe interface. For emailpassword, here is the recipe implementation. As seen in the implementation, most of the implementations are simply calls to the backend as per the FDI spec. However, some recipes like the session recipe can be far more complicated.

One important aspect of this is that recipe implementation can be overrided by the user - they can pass their own instance of a class that implements the recipe interface (using the override config) and then their logic would run.

Components

Feature components

These are components that have no UI. Instead, they do two things:

• Modify the recipe implementation to perform actions such as set state or redirect the user based on the return type of the recipe implementation functions.
• Prepare props for and render the theme components.

You can see the sign in / up feature component for emailpassword here.

Theme components

These are UI only components that accept props from the feature components and use them to drive the UI logic. You can find the various them components for emailpassword, for sign in / up here.

Unlike the feature components, the theme components can be overrided by the user using the override config. This happens using the componentOverride higher order component.