Third-Party Integrations

On this page:

Generally, there are four ways of integrating third-parties or data into Styla Frontend

Include Scripts

• Ability to load a given external script front-wide or on a given page

HTML Module

Ability to add HTML markup and JavaScript to a module which can be placed on a page or a Base to be loaded on all pages that inherit from that base

• Rudimentary but low-effort variant of a custom module

Custom Module

A custom module consists of a Handlebars template for server-side rendering, a JavaScript file for client-side execution and a JSON schema for the configuration options for end users.

• Handlebars: you can only provide a Handlebars template and cannot execute JavaScript code on the server-side.

• JS: The JavaScript file will only be embedded on pages where the module is used, it should be able to handle multiple instances of the module on one page and should be kept minimal to avoid impact on page speed.

• JSON Schema: The schema allows configuring the settings for a module, but as well to define which data a module can take like text, rich text, image, product.

External Data Fetching

Ability to fetch data from external APIs for server-side rendering

• Modules can pass context information (like the current category or product-id) to external API’s and fetch JSON or HTML content from there to inject it into Modules. Sample use-cases:

  • Fetch BigCommerce navigation tree to not have to type 200 menu items manually

  • Fetch Contentful category content (since it was already there)

  • Fetch related products on a per-product-basis and have it server-side rendered for page speed

  • Fetch a complex HTML structure (pass the product-id or other relevant information from the context) since you are lacking certain handlebars helpers for more complex server-side logic.

Limitations for server-side rendering

• Third Parties cannot trigger hooks to re-generate pages that are using a given API. It’s one directional integration only.

  • Possible solutions to be decided:

    • Option A: We implement a headless CMS similar to Contentful where you can define data structures, which can be used within our custom modules. Once you write to a given data structure, similar to product updates we could trigger updates. <- high effort on Styla side

    • Option B: Third parties could implement it on their side by passing the page path on a render to their API when fetching data, storing with the requested entity or query which path was requested. When they update their entities, they call a Styla hook and pass on the paths that need to be updated <- high effort on the third party side

      • Drawback: clean deregistration from pages would need to be handled over a more complex system of registering / deregistering hooks for modules.