I. Design Concept

Interface, editor, player

The interface is a tree of components.

The interface editor is the tool for editing and persisting this component tree.

Editor to maintain the tree data, open to the public add, delete, change, check, undo redo interface.

Interface player input component tree, you can get the interface display

In the future it will even be possible to adapt different players to different platforms.

component

Each component in the tree determines its own through input properties

  • show
  • interaction

Components can know if they are being edited through the interface of the component editor. In the edit state, a component can provide interactive editing of its own input properties.

There are two advantages to this

  • The editor is always focused on the component tree, the properties of the component, not how to edit the properties of the component
  • Components can edit properties with the most appropriate interaction tailored to their business needs

Example: Design a Text component logic that displays the cursor while in the editable state and makes the Text editable

When not in the edit state, text content is displayed

Original products of this philosophy [www.sxl.cn]

The view components

Further, we can take advantage of the fact that components can provide their own interactive logic to edit their properties in the edit state, and we can design a special component – the View component.

View components are components by nature. It’s just that the view component’s property is the component list. We gain the ability to orchestrate components by visually adding, removing, and reordering components in view components. The interaction of view components largely determines what the visual editor ultimately looks like and how it is used.

Such as:

  • We can put an input box in the view component and add components by typing the component name and hitting Press Enter, or we can add components in a more user-friendly way by sensing the components that are being dragged in.
  • The view component can be a default block, and the components added are based on the default streaming layout. It can also be an extended area with a specific length and width. You can drag components to any location in the area to obtain coordinate positions and become an absolutely positioned container.

Different view components can be designed depending on the specific goal, or even multiple view components can coexist.

View injection point

With view components, we can start to “inject” components into view components and find the components we need to customize our interface. Many interface editors may not be as flexible underneath, but they appear to do just that. At this point, you have a good enough interface editor to use. Unheard, structor, etc.

[https://github.com/ipselon/structor] Structor – React UI editor This is a very common idea: tell the component editor responsible for where it should be, the user selects a kind of personalized solutions. It’s up to the component library to decide what can be implemented. This poses a huge challenge for component design: the editor gives you a field, and you have to be flexible enough to fulfill as many of your users’ needs as possible.

Here comes a question that I think is very representative: how to design a Nav Bar flexibly.

Using the previous design idea, we can design the following attribute data structure: {logo, [{icon, name}]}

Menu text can freely choose whether there is icon, if there is, it will be displayed. It provides some flexibility up front. Next, consider how clicking on the menu triggers the corresponding interface change.

It’s too hard. Let’s not consider it.

Unheard did nothing of the sort. In the original templates, the entire template is a complete program, and the menus are also a part of the program, so the page linkage effect of menu clicks can be easily realized. However, if you want to keep this menu, but change the page content section to something else. Well, Unheard doesn’t offer that.

At the end of the day, it’s hard enough for me, as a component, to be able to satisfy the user’s needs on my own site, and now I have to worry about how to display it elsewhere. — It’s too hard.

So, why don’t you just give me the land I’m in charge of. When the user clicks on menu 1, I make a big block under menu 1 show plot 1, click on menu 2 show plot 2… And then what if I don’t know exactly what’s going to be shown at site 1 and site 2? Let the editor assign new components to manage.

With a lot of talk, we finally get to the point of view injection.

Any component can provide an injection point for the view by displaying the view component, leaving it to the user to further orchestrate the component.

In the Nav Bar example above, the Nav Bar component fills up the entire screen. The large white space left below the Bar is a view component that users can fill with other components using the layout component capabilities of the view component. So the Nav Bar is just going to control whether the white space shows view component 1 or view component 2, and it doesn’t really care what view component 1 and 2 show.

Another detail on the Nav Bar: the location of the display menu can also be handled by placing a view component. The user adds a Text to the view component to display Text, and an Icon to the view component to display Text. You can also swap text and icon positions, becoming unusual left text and right ICONS, or even left and right ICONS with text in the middle. Follow your heart.

conclusion

  • Visual editing can be divided into two parts: editor and player
  • The interface is a tree of components, and what the editor does is edit the tree and persist the data
  • Components use input properties to determine how they display and interact. Does the same apply to the editing process
  • The editor needs at least one component of the orchestration component, the view component, which can be replaced, thus achieving the extensibility of the editor.
  • Any component can achieve greater flexibility through embedded view components.