Initialization

Import members from @edx/frontend-platform

The initialization module provides a function for managing an application's initialization lifecycle. It also provides constants and default handler implementations.

import {
  initialize,
  APP_INIT_ERROR,
  APP_READY,
  subscribe,
} from '@edx/frontend-platform';
import { AppProvider, ErrorPage, PageWrap } from '@edx/frontend-platform/react';
import React from 'react';
import ReactDOM from 'react-dom';
import { Routes, Route } from 'react-router-dom';

subscribe(APP_READY, () => {
  ReactDOM.render(
    <AppProvider store={configureStore()}>
      <Header />
      <main>
        <Routes>
          <Route path="/" element={<PageWrap><PaymentPage /></PageWrap>} />
        </Routes>
      </main>
      <Footer />
    </AppProvider>,
    document.getElementById('root'),
  );
});

subscribe(APP_INIT_ERROR, (error) => {
  ReactDOM.render(<ErrorPage message={error.message} />, document.getElementById('root'));
});

initialize({
  messages: [appMessages],
  requireAuthenticatedUser: true,
  hydrateAuthenticatedUser: true,
});
Source:

Members

(inner, constant) basename

The string basename that is the root directory of this MFE.

In devstack, this should always just return "/", because each MFE is in its own server/domain.

In Tutor, all MFEs are deployed to a common server, each under a different top-level directory. The basename is the root path for a given MFE, e.g. "/library-authoring". It is set by tutor-mfe as an ENV variable in the Docker file, and we read it here from that configuration so that it can be passed into a Router later.

Source:

(inner, constant) history

A browser history or memory history object created by the history package. Applications are encouraged to use this history object, rather than creating their own, as behavior may be undefined when managing history via multiple mechanisms/instances. Note that in environments where browser history may be inaccessible due to window being undefined, this falls back to memory history.

Source:

Methods

(async, inner) analytics()

The default handler for the initialization lifecycle's analytics phase.

The handler is responsible for identifying authenticated and anonymous users with the analytics service. This is a pre-requisite for sending analytics events, thus, we do it during the initialization sequence so that analytics is ready once the application's UI code starts to load.

Source:

(async, inner) auth(requireUser, hydrateUser)

The default handler for the initialization lifecycle's auth phase.

The handler has several responsibilities:

  • Determining the user's authentication state (authenticated or anonymous)
  • Optionally redirecting to login if the application requires an authenticated user.
  • Optionally loading additional user information via the application's user account data endpoint.
Parameters:
Name Type Description
requireUser boolean

Whether or not we should redirect to login if a user is not authenticated.
hydrateUser boolean

Whether or not we should fetch additional user account data.
Source:

(async, inner) initError(error)

The default handler for the initialization lifecycle's initError phase. Logs the error to the LoggingService using logError

Parameters:
Name Type Description
error *
Source:
See:
  • {@link module:frontend-platform/logging~logError}

(async, inner) initialize(optionsopt)

Invokes the application initialization sequence.

The sequence proceeds through a number of lifecycle phases, during which pertinent services are configured.

Using the handlers option, lifecycle phase handlers can be overridden to perform custom functionality. Note that while these override handlers do replace the default handler functionality for analytics, auth, and initError (the other phases have no default functionality), they do not override the configuration of the actual services that those handlers leverage.

Some services can be overridden via the loggingService and analyticsService options. The other services (auth and i18n) cannot currently be overridden.

The following lifecycle phases exist:

  • pubSub: A no-op by default.
  • config: A no-op by default.
  • logging: A no-op by default.
  • auth: Uses the 'auth' handler defined above.
  • analytics: Uses the 'analytics' handler defined above.
  • i18n: A no-op by default.
  • ready: A no-op by default.
  • initError: Uses the 'initError' handler defined above.
Parameters:
Name Type Attributes Description
options Object <optional>
Properties
Name Type Attributes Default Description
loggingService * <optional>
 NewRelicLoggingService

The LoggingService implementation to use.
analyticsService * <optional>
 SegmentAnalyticsService

The AnalyticsService implementation to use.
authMiddleware * <optional>
 []

An array of middleware to apply to http clients in the auth service.
externalScripts * <optional>
 [GoogleAnalyticsLoader]

An array of externalScripts. By default added GoogleAnalyticsLoader.
requireAuthenticatedUser * <optional>
 false

If true, turns on automatic login redirection for unauthenticated users. Defaults to false, meaning that by default the application will allow anonymous/unauthenticated sessions.
hydrateAuthenticatedUser * <optional>
 false

If true, makes an API call to the user account endpoint (${App.config.LMS_BASE_URL}/api/user/v1/accounts/${username}) to fetch detailed account information for the authenticated user. This data is merged into the return value of getAuthenticatedUser, overriding any duplicate keys that already exist. Defaults to false, meaning that no additional account information will be loaded.
messages * <optional>

A i18n-compatible messages object, or an array of such objects. If an array is provided, duplicate keys are resolved with the last-one-in winning.
handlers * <optional>
 {}

An optional object of handlers which can be used to replace the default behavior of any part of the startup sequence. It can also be used to add additional initialization behavior before or after the rest of the sequence.
Source:

(async, inner) jsFileConfig()

Set or overrides configuration via an env.config.js file in the consuming application. This env.config.js is loaded at runtime and must export one of two things:

  • An object which will be merged into the application config via mergeConfig.
  • A function which returns an object which will be merged into the application config via mergeConfig. This function can return a promise.
Source: