Integration Concepts
Introduction
One of the strengths of Makeswift as a composable tool is the ability to integrate with any other system as best fits your application’s requirements. Built into Catalyst, for example, is an integration with catalog data from your BigCommerce store.
An external CMS is another common use case for data integration. While using Makeswift as your CMS is a viable strategy for web applications heavy in rich content, enterprise-level sites may often source their content from a separate system. A headless CMS such as Contentful or Contentstack is a good example.
With the ability to make your Makeswift implementation your own, you can marry the full power of the visual editor with the data sources your application needs.
Typically, data integration needs fall into two major conceptual requirements:
- Data-aware components- Makeswift-enabled components can draw their content from external data sources. For example, a product carousel component that exposes a prop to choose a category from the BigCommerce back-end, which will provide the needed product data. Such components can be available for use on any static page.
- Buildable dynamic pages - Support for visual editing can be implemented not only for static Makeswift pages, but for any dynamic pages of your frontend - as product detail pages are in Catalyst, for example. This requires a strategy to load appropriate page or component snapshots based on the dynamic URL, and this scenario might also involve data-aware components.
Integration Techniques
Just as general React concepts are fully applicable to your custom Makeswift components, the built-in capabilities of React and Next.js provide the building blocks you need to create your own integrations.
While every application is unique and integration strategies can vary widely, the following are some major pillars that are likely valuable.
Click each row to expand.
Specialized Routes
You’ve seen that full editable static pages involve use of a “catch-all” Next.js route to handle all pages based on their URL path. When you need visual builder support for dynamic pages powered by a separate back-end system, you likely need to diversify your route patterns (for example, to accommodate URL paths like /blog/{slug}).
The strategy for how URL patterns of dynamic pages translate to the Makeswift content that is loaded and rendered will usually involve use of MakeswiftComponent combined with a unique snapshot identifier from the dynamic data. The editable regions you expose with the component snapshot can be as narrow or broad as you want.
React Context Providers
React Context is a technique for providing data to all components within a tree, regardless of how deeply nested, for situations where it’s impractical to pass it explicitly via props.
This fits well with the case of visual editor components, since only Makeswift controls provide data for their props. Depending on how and where you load your data, context providers might be a good strategy for providing that data to your components.
We’ve seen examples of context provider strategy used with MakeswiftComponent in Catalyst.
API Routes
One option for accessing external data from within a component is to allow it to load the content directly in a client-side context. Exposing API routes in your application is an appropriate strategy for allowing such client-side fetches while keeping your integration details within server-side code.
The Combobox Control
The Combobox is a Makeswift control similar to a Select but allows you to implement a custom function for providing the values that are available for the prop. With this available tool, you can integrate external data not only with the rendered content of your components, but also with the options authors have for configuring their props.
