Frontend: Routing & Custom components - Into Foundation Spa React series, Part 5
With the fifth installment of the "Into Foundation-Spa-React" series, the focus shifts from the backend and high-level frontend implementation towards one of the key capabilities the SPA offers to enable you to not only provide content from within Content Cloud but from any source.
The content and logic from other sources can be exposed through specific components, which may be placed through Content Cloud or fixed within the layout. However, when you want to create "pages" which are not managed by Content Cloud, you need to access the routing - which you have.
Take this example:
You're building a site for a company in the leisure sector, most of the content will be taken and managed by Content Cloud, yet booking will be handled through an industry-specific booking platform. In this case, there'll be some widgets on some pages that will take input from that booking platform (e.g. date selection, availability, current booking, etc..) and some specific functional pages (e.g. current booking, checkout). Also, the "My Account" section will most likely show data from multiple sources.
The routing within the library is based upon the React-Router solution, which enables a high level of control over the routing within a SPA. By default, there's only one route, the "catch-all" (or "*") route, which gives the URL to Content Cloud to resolve to a content item. All routes you configure will be pre-pended to this catch-all route and thus take priority over URL managed within Content Cloud.
The configuration itself is pretty straightforward:
{
...,
routes: RouteProps[]
}
Here RouteProps, are the properties given to the Route component of React Router (docs here). As this is put in the configuration, all components you reference will be included in the initial bundle. This is something to avoid as there's no way to predict if the visitor will visit that route and thus bloat the initial download. To resolve this there're two options:
- Use the instruction from React to roll your own solution: Code-Splitting – React (reactjs.org)
- Use the LazyComponent from the Components namespace, which uses the same extendable component loading logic and spinners as the other parts of the SPA.
Component resolution and loading
By default the SPA can resolve all components, using their default export, as long as the component path starts with "app/Components". As you might want to alter this logic you can inject your own component loaders. The default component loader can be found here.
To register your loaders, add them to the configuration:
{
...,
componentLoaders: []
}
You can provide either a fully instantiated object, or a class (implementing IComponentLoader). However, if you provide a class it will be instantiated without any constructor arguments.
To summarize, you have the ability to create your own components within the SPA, which can take data and logic from any system you choose to integrate it with. For those parts where you need to expose pages, the SPA allows you to configure these routes, including the components used to handle these routes.
A final remark: When running the SPA within Content Cloud, such as Foundation-Spa-React, be aware that these "extra routes" can neither be resolved by Content Cloud, nor easily be server-side rendered and - if you don't change anything to Content Cloud - they will yield a 404 response when accessed directly, or the visitor hits "Reload".
Comments