Frontastic for developers

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


Business logic within Tastics

We often get the question, should business logic go within my Tastic or outside of it. And it actually depends on what you want to do.

In this article, we'll give you tips on where you should be putting your Business Logic for Tastics.

The most important thing to keep in mind when thinking about where to put certain parts of a Tastic is to make clear what kind of code exists.

When looking at the structure of your React components starting with tastic.jsx from top to bottom, the first thing that you have is the code that interacts with Frontastic itself. This is the tastic.jsx React component that receives the information from Frontastic that's requested (data prop) and then does things with it.

One step below (or multiple steps below) there's some displaying logic, this is also React components but they typically show certain kinds of information, style them by putting HTML tags around them, or putting them into micro-React components. But their only purpose is to display stuff on the screen and to collect user input.

If you look into these two levels, there's a lot of stuff in between, the bottom-most level should be as simple as possible. It should only do rendering that comes in a predefined way and direct certain actions to whatever higher-level components there are. For example, if you click on a button to achieve an action.

In between these two levels, is where your business logic should reside. And that's where, for example, there's a place for showing different things for a logged-in user versus a non-logged in user. So inside of the Tastic you could have one React component that then renders down a tree of multiple things which is there for logged in users and the other one which is there for non-logged in users. And then below that, you can divide again into something that either does an interaction displaying something or something that has logic like calculating things and so on. You should also distinguish sideways, like for displaying you use React components while you have some plain JavaScript objects or functions which perform logic and calculations.

Let's look at an example.

Say you have content that can only be displayed to users of a certain age. The first thing you'd have to do is determine the age of your user so this is also the first thing within your tastic.jsx. You'd get the data delivered from Frontastic and then you can convert it into a representation of the data that makes sense. The data could come back to you as a string which you could transform by using a dateObject which contained information like month, day, and year.

Given that you have a birthdate input, you now want to compare if the user's birthdate is older or younger than a given date. You need various things here: firstly, you need to be able to know if the user is logged in or not, otherwise you wouldn't know their birthdate. So here, you would have a choice between: we already know the birthdate, or we don't know the birthdate and we need to ask the user for the birthdate or ask them to register.

Once we have the birthday, there are 2 more branches: if they're older than the age needed you can display the content, or if they're younger, don't display it. This displaying is the bottom-most React component saying "show this information" or "don't show this information" and the logic of the comparison should be outside of the React stack. It should be a function where you say this is the birthdate which is the maximum, this the birthdate which I received from the user, no matter where it came from either from (the logged-in user where the data is stored in some kind of microservice or from entering it on the site) and then doing the calculation like, is this correct or is this not correct.

So you shouldn't have 1 huge JSX file for each Tastic with all the business logic within it, you should be using dedicated logic functions for reuse into plain JavaScript functions which are then very good for testing.

Another example is that a user wants to see their past purchases on their Orders Page of their account. This Tastic shouldn't be displayed to a user who isn't logged in so you have logic at the very top to check whether the user is logged in or not as that information is essential for what should be done. One branch shows the information and the other branch would ask the user to log in or create an account.

Below that, we have two React components that have the logic for each of the branches. So one React component shows the login form and does the triggering of the login request and redirecting afterward (if the user decides to log in afterward). While the other one is converting all the orders the user has into a sensible format because the design system wants to have a different representation than the one given by Frontastic.

The image below shows how to structure your business logic within your Tastic using this example:

Updated about a month ago

Business logic within Tastics

Suggested Edits are limited on API Reference Pages

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