Frontastic for developers

We remove the complexity when building eCommerce websites in a headless world.

Documentation    

What is a Tastic?

Before a Frontend Manager can use a Tastic on your pages, as a Developer, you'll need to create these for them.

In this example, we're implementing a simple Tastic that displays a list of products. We use the ProductList Tastic that's shipped with Frontastic as the basis but stripped the HTML code down a bit for better illustration. If you want to copy this tutorial, please don't hesitate to copy the following files as a starting point:

  • paas/catwalk/src/js/tastic/productList/schema.json
  • paas/catwalk/src/js/tastic/productList/tastic.jsx

File placement

Custom Tastics need to be placed in the project directory they belong to. By convention, the path project/src/js/tastic/ holds all custom Tastics. Each Tastic requires its own sub-directory which is the camelCased Tastic name.

The Tastic schema specification should always be named schema.json for easier lookup.

So if you start with the example from above, have a project named fall2018 and your Customer ID is year, you should copy the files to:

  • year_fall2018/src/js/tastic/productList/schema.json
  • year_fall2018/catwalk/src/js/tastic/productList/productListTastic.jsx

Tastic specification

The Frontastic Editor needs to know how the Tastic requires to be initialized and what parameters it expects to be available. This comes in the form of a JSON file that follows a JSON schema that can be found in:
paas/libraries/common/src/json/tasticSchema.json with the common definitions from paas/libraries/common/src/json/library/common.json.

On the top level, this file contains meta-information about the Tastic:

{
  "tasticType": "year-productList",
    "name": "Product List",
    "icon": "list",
    "schema": [
    ...
  ]
}

The tasticType defines a name of how the Tastic can be looked up in code. This must be prefixed by (at least) your customer ID or another unique identifier.

The name provides a readable name, in contrast to that. You should provide an icon for your Tastic which can be selected from the Material Design Icons. The schema key then contains the parameter list for the Tastic:

{
  ...
  "schema": [
    {
      "name": "Stream Selection",
      "fields": [
        {
          "label": "Stream",
          "field": "stream",
          "type": "stream",
          "streamType": "product-list",
          "default": null
        },
        ...
        {
          "label": "Show strike price",
          "field": "showStrikePrice",
          "type": "boolean",
          "default": true
        }
      ]
    }
  ]
}

The schema is presented to the Frontend Manager as a configuration dialog. For this reason, structure your schema into meaningful blocks that cover related fields (here, the block is named Stream Selection).

Each field specifies one parameter that'll be provided to your Tastic under the name provided as field. The label is used in the UI for the Frontend Manager (for example, stream). The type determines what kind of information you require. Frontastic supports typical programming data types like string, integer, or boolean. But also advanced types like node, tree, media, or group.

The latter types provide advanced UI elements for the Frontend Manager and resulting objects to submit the information to your Tastic. For example, a media field provides image selection from the media library + configuration for cropping and more.

In the shown case, the Product List Tastic requires a stream of type product-list and a boolean flag which determines if strike prices are shown.

The specification for your Tastic should be stored in the source code repository together with the Tastic code. To make the Tastic known by the Frontastic Editor, you need to upload the schema to the Development area in the Editor once. In addition, you need to re-upload the specification every time you change the required parameters or any metadata. We'll go through how to do this in the next article.

Tastic React code

The Tastic itself is basically a ReactJS component that receives some pre-defined props from Catwalk. If you're not familiar with ReactJS, component, and props, please refer to the React Component documentation first.

The stub of the tastic.jsx file looks like this:

import React, { Component } from 'react'
import PropTypes from 'prop-types'
import _ from 'lodash'

...

class ProductListTastic extends Component {
  render () {
    // ...
  }
}

ProductListTastic.propTypes = {
  data: PropTypes.object.isRequired,
  tastic: PropTypes.object.isRequired,
}

ProductListTastic.defaultProps = {
}

export default ProductListTastic

While the remaining boilerplate is pretty standard for a React component, the important part here is the ProductListTastic.propTypes declaration.

Every Tastic receives the prop tastic which contains all information that is available about the Tastic itself. This includes the schema.

The data prop contains all collected data the Tastic required if this data is available yet. You can directly access the values by their name. If your specification schema contains a field campaignProductStream you can access the corresponding stream via this.props.data.campaignProductStream.

How this works can be seen in the following example which reveals the first part of the render() method:

class ProductListTastic extends Component {
  render () {
    let productList = this.props.data.stream
    if (!productList) {
      return null
    }

    let showPercent = this.props.data.showPercent || true
    let showStrikePrice = this.props.data.showStrikePrice || true

    // ...
  }
}

📘

You can't be sure that data is filled every time. For example, during an update of stream filters or view change, it might be empty. So, the code needs to take care of resilience and simply returns null if it misses data (no rendering at all). If you can display something meaningful instead, feel free to do that.

For convenience, the 2 other settings (of which we saw one in the specification) are extracted and filled with defaults for resilience. The remaining code in render() is again straight forward React:

class ProductListTastic extends Component {
  render () {
    // ...
    
    return (<div className='o-layout'>
      {_.map(productList.items, (product) => {
          return (<div key={product.productId} className='...'>
            <Product
                product={product}
                      showPercent={showPercent}
                      showStrikePrice={showStrikePrice}
            />
          </div>)
      })}
      </div>)
  }
}

The component wraps all HTML into a div with o-layout class, iterates all items from the product-list stream, and presents the product itself using another React component: <Product>. The latter isn't a Tastic, but a simple React component.

Register the Tastic

By now you still need to register your Tastic in the code base of Catwalk. Do this by editing <project>/src/js/tastic/tastics.js, import the ReactJS class of your Tastic and add it to the list that maps Tastic types to classes, for example:

//
... import ProductList from './productList/tastic.jsx'
//

...  export default (() => {
     return {
    // ...
    'year-productList': ProductList,
    // ...
     }
})()

🚧

The class must be the same name as that's tasticType in your schema.json, otherwise, it won't work.

Now that you implemented a very first Tastic, it's time to preview it in your local machine, for that you'll need to create your Tastic in the Frontastic Editor. We'll show you how to do this in the next article.

Updated about a month ago


Tastics


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.