Extensions

We offer different extension points at various different layers. This is an overview of how you can use them and the articles in this section will go into more detail.

Our main integration in the backend layer is decorators for all the API integrations we provide. An example of such a decorator would be adding additional information to products when they're loaded, perform price calculations or verify and modify what's put into the cart (for example, to calculate custom discounts not supported by your commerce backend).

In the frontend layer, you'll primarily write new Frontastic components and patterns, but you can also hook into our Redux stack by writing your own reducers and action producers. Additionally, we provide a ComponentInjector, which allows you to exchange some Frontastic core components, see the Injecting custom components and reducers article for more info.

By configuration

The following topics are already set up by configuration but there's no interface for this yet:

• Configure APIs (content, product, search, account, cart, wish list, media, payment)
• Content security policies
• Project locales
• Breakpoints

Frontend

The following extension points already exist for the frontend:

• Frontastic components – see this article for more information
• Custom CSS – entry point through any Frontastic components or <my_project>/src/scss/app.scss
• Custom JavaScript – entry point through any Frontastic components or <my_project>/src/js/injection.js
• Custom pattern library – entry point through any Frontastic components plus optionally package.json
• Reducers – see [this article(doc:injecting-custom-components-and-reducers)

Developing these extension points doesn't require a Frontastic sandbox but can be done using our Frontastic CLI, see the Frontastic CLI article for more information.

Backend

The following extension points already exist but require you to write PHP code that's run in the same Frontastic sandbox as our code:

• Custom data sources
• API decorators
• Custom proxy request
• Custom API
• Payment Service Provider integrations
• Special functions, determined from current customer projects
  • Locale determination
  • Custom object routers (custom URLs for product, content, and so on)
  • Order ID generation

We'll go through each of these points below.

Backend extension points

The image below shows how the different extension points behave. Blue is the Frontastic code while red is custom code.

TasticFieldHandler

The TasticFieldHandler lets you connect arbitrary data and services to Frontastic components. You can create a custom field {type: 'stream', streamType: 'my-stream-type'} and for every Frontastic component, the TasticFieldHandler is evaluated, which means that depending on the context of the Frontastic component, current user, project, and page, additional data can be computed or fetched. An example could be fetching recommendations from a custom (micro)service.

📘

A custom tastic field is local to a tastic configuration. This means it's loaded $n times if the same custom tastic field is used multiple times on the same page.

A TasticFieldHandler is a single PHP class. In most cases, this class is used to perform an HTTP request and might include some pre-processing of request data or some post-processing of the returned data. See the project specific data article and the TasticFieldHandler article for more information.

API decorators

API decorators allow you to modify and enrich the requests and responses from our core APIs (content, product, search, account, cart, wish list). So you could, for example, add an additional filter parameter to product searches ( stock > 5) and/or add information from a Content Management System to the product when enriching the response.

Such decorators are registered as PHP classes, as shown in the API decorators article. These decorators can be defined before and after handlers for all API methods.

Custom controllers

Custom controllers, allow you to basically perform any action in the backend. But they're mostly used to store data in external services or trigger actions on external services (use a store finder API, trigger sending a newsletter, and so on). An example could be recording visits in a custom tracking service.

This can be implemented by registering a controller in Symfony (see this article for more info) and even provides access to the API abstractions in Frontastic. These controllers actually provide access to the full system and are also used to implement custom Payment Service Providers.

Custom API

Frontastic provides default integrations with multiple vendors (commercetools, Shopify Plus, Contentful, GraphCMS, and Adyen) but if your vendor isn't integrated yet or you're using a custom API backend, you'll need a custom API integration.

You can do this by implementing the API against our test suite in PHP (see this article).

Generic HTTP API

To enable integrations with custom API endpoints we'll have a native HTTP API which maps our PHP API to sensible HTTP calls against a configured endpoint. This allows our customers to either implement additional API endpoints in their existing HTTP API matching the requirements of Frontastic or implementing an HTTP middleware layer that responds to the API requests executed by Frontastic and talking to a third system to fetch the actual data.

Frontastic will provide Swagger files for this API and document the endpoints a customer has to implement. Frontastic will also provide a test suite to make sure the API behaves correctly.

Payment Service Provider integrations

Payment Service Providers (PSP) are responsible for integrating payment mechanisms in the checkout. Frontastic has readily available integrations for Adyen. To integrate your own PSP, you'll need to use a custom controller (see this article).

Special functions

Besides the default integration patterns described earlier and things that can just be configured, there are several domain-specific customization needs that can't be easily abstracted into the configuration. For all these topics we provide sensible default behavior which can be overwritten by registering functions for this. Some of these extension points may require talking with external APIs.

An incomplete list of these extension points are:

• Locale determination: While locale is usually determined by the user's accepted HTTP headers, you may prefer a domain-based customer locale determination, for example.
• Custom object routers: You can generate the URLs for products and categories yourself if you have special constraints for how these URLs are supposed to look.
• Order ID generation: There are always special constraints for how order IDs should be generated and some eCommerce backend systems don't allow you to fully configure this. In these cases, we generate those order IDs inside Frontastic.

This list should give you a general idea but it'll extend over time.