Schema
Schema is the most important property of a No-Code Component definition. It defines visually editable properties and subcomponents of a No-Code Component.
In our SimpleBanner
example the schema looks like this:
The first 5 properties are "basic properties" (backgroundColor
, hasBorder
, padding
, gap
and buttonsGap
) whereas the Title
and Buttons
are subcomponents.
Basic properties
Basic properties are displayed in the sidebar when the component is selected (it's a default behaviour but it can be overridden via editing function).
In this example we use built-in space
, color
and boolean
properties. The full list of properties can be found in the Reference section below.
Responsiveness
The great thing about Easyblocks is built-in responsiveness. The space
and color
properties are responsive by default whereas for boolean
property (hasBorder
) we enabled it with responsive: true
flag. Thanks to this each property can be overridden on mobile:
Subcomponents (children components)
The Title
and Buttons
schema properties are respectively of component
and component-collection
types. The subcomponents allow for nested selection in the editor. Important notes:
accepts
property defines what kind of components are allowed as children for a specific subcomponent schema property. It's a very powerful property that allows for adding constraints to your visual builder and making sure non-technical users will always produce a correct output.Title
has a flagrequired: true
which means that it's always defined.Buttons
is acomponent-collection
which means an array of components of typeButton
.placeholderAppearance
determines the appearance of the placeholder shown in the layout when the list is empty.
In the video below you can see children components in action with nested selection and drag&drop:
Passing to React component
Each schema property will be passed as a prop to your React component. You can override this behaviour by setting buildOnly: true
for your schema property:
When buildOnly
is set to true
the property will be passed as a parameter to styles
and editing
functions but it won't be passed to the React component. It's often good to set this flag for properties used only in styles
function (read this section to learn more).
No-Code Entry
Under the hood each No-Code Component instance added to the canvas is represented by a JSON called No-Code Entry
. In this case our component JSON representation for selected element looks like this:
Each time makes changes to the fields, the underlying No-Code Entry changes.
No-Code Entry is the most important data format used in Easyblocks. It's a full JSON representation of what is visually built in the Easyblocks Editor. It's a tree structure so if a No-Code Component has children components (component
or component-collection
fields) then the children are represented by nested No-Code Entries (look at Title
field in example above).
Schema properties reference
Basic types
Boolean
Boolean type can be either true
or false
.
This type can optionally be responsive.
Select
Select type allows to choose a single value from predefined list of options. It holds a string
value.
Select type requires options
parameter to be set to know what options are available. Options can be simple array of strings or each option can be an object of type { value: string; label: string }
which allows for better control how options are shown on the list.
This type can optionally be responsive.
String
String type holds a string
value that's not localizable.
This type can optionally be responsive.
Text
Text type is similiar to type String, but the value can vary between locales - it's localizable.
Value of field of type text
is stored in No-Code Entry in the following way:
Easyblocks offers a built-in component @easyblocks/text
utilising text
type.
Responsiveness
Most of the types can be responsive. It means that the user in the editor will be able to set different values for different breakpoints. boolean
, select
and string
types can be optionally responsive. You can enable responsiveness with responsive
flag.
The underlying data format of responsive fields in the No-Code Entry is different from non-reponsive fields. Here's an example for boolean
:
Token types
Easyblocks comes with handy built-in types that are based on design tokens you can specify in your config (Config.tokens
)
All built-in token fields are responsive by default and it can't be disabled.
Color
Color type allows to select single value from the list of values coming from Config.tokens.colors
. You can also set a custom HEX value.
Here's the representation in No-Code Entry:
As you can see token value it stored as an object that consists of tokenId
and value
:
tokenId
property which is the token identifier of selected colorvalue
property which is the actual string representation of selected color.
value
might seem redundant but it exists in the No-Code Entry only for the case when the token is removed from the configuration.
When the token value goes to the component as props, you don't get a full object, you only get the value
.
Font
Font type allows to select single value from the list of values based on the Config.tokens.fonts
.
In the No-Code Entry:
Space
Color type allows to select single value from the list of values based on the Config.tokens.space
. Easyblocks also supplies for each space
field type a set of predefined space values.
In the No-Code Entry:
Component types
Component based types are special kind of fields. Instead of extending the sidebar experience, they allow you to extend capabilities of your component by defining nested components that can also be selected and can have their own set of fields. Component fields can't be responsive.
Component
Component field creates a slot which can be filled with single component.
component
field, as other field types, is passed within props to your React component. The passed component prop is a React element, not a React component. It's super important to remember it. Below is the example how you can use passed Component
field:
accepts
accepts
In the code example above, we tell editor to only allow to add built-in Rich Text component to our Component
field by setting accepts
property. You can limit number of accepted components also to your own No-Code Components by specifying their id
property.
When defining No-Code component you can set its type
. You can think of this value as a tag or interface. It lets you gather multiple components under one name and then tell your component
field to accept all components of given type ex.:
Non-empty components
By default, each component
field is optional and can be left empty and it won't render anything (or a placeholder when in the editor). By setting required: true
, we mark the field as non removable.
It's great when your component should have a fixed element. Imagine a card component that always has to have heading, but subheading is optional. We could implement it like this:
Built-in components
Easyblocks is shipped with two built-in components that can be handy:
@easyblocks/rich-text
- rich text component for text editing values that's also localizable@easyblocks/text
- a simpler version component for text editing component that's also localizable, but without being rich (single font and color, no links).
Component Collection
Component collection field creates a slot which can be filled with any number of components.
Since the field represents a collection, it means that when the field is passed to your React component it's going to be an array of React elements. You can render it similarly to component
field:
Items adding direction
By default, when you use component-collection
field and start adding items on the canvas the buttons for adding items at the beginning or at the end of each item are rendered vertically. If your collection is oriented horizontally, you cen edit this behaviour by using editing
method of component definition and specifying direction
property for each item.
Item fields
It's a common practise for parent component to determine how it should render based on its children. Let's imagine you're building a Grid component for displaying your Card components. In the simplest case we could just render each item using CSS Grid using fixed number of rows and columns. Each card would occupy one row and column.
To put more emphasise on some cards we would like to make them occupy 2 columns and 1 row or even 2 columns and 2 rows. This behaviour would affect how the parent component should render the grid. This would require to have information about each size of card within the parent, but allow to configure it on each grid item separately. To make it possible you can use itemFields
property for your component-collection
field. This property allows you to declare additional fields that are stored within the component defining the collection field, but these fields are configurable from the fields of collection items.
Custom types
Easyblocks allows to add custom types. Read the Custom types guide to learn more.
Last updated