I have 2 hanlders in a event trait. The first hanlder sets a value. The second handler alert this value.
The expectation is to alert the latest value. But actually, it will alert the old value.
This is because there is no eval process between 2 hanlders, so the second hanlder can only use last evaled value not the new value.

• fetch data in the trait
• set loading, error, data to the store
• required props:
  • url
  • method
• optional props:
  • lazy
  • headers
  • querys
  • body
• callback:
  • onSuccess
  • onFailure
• trigger method

What should be copied when copy a component?

• properties
• trait(except slot trait)
• children

https://github.com/sinclairzx81/typebox

In the previous discussion, the team agreed with the new branding: sunmao-ui(Chinese '榫卯' in PinYin).

Re-branding checklist

• rename the repo
• rename packages
• refactoring code

• can drag component into stack or grid to create component
• can drag component to move component

@sunmao-ui/runtime should not be dependent on chakra-ui

Use cases

• You build a complicated form by meta-ui and want to reuse it in multiple meta-ui application.
• You build a fancy listItemView and want to use it in list.

module vs component

Module is made up of meta-ui component. Component is created in react.

Features of module

Basicly, module can be used like a component. Module can receive properties and expose state & events.

Tasks

• define spec and schema
• render module as item of table td and listItem
• render module individually
• create module in editor
• edit module in editor

https://github.com/react-grid-layout/react-grid-layout

Places need to be modify after component id changes

• slot trait
• event trait
• expressions used this component Id

• readme
• introduction article
• online editor demo

When evaling number string, we automatically convert it to real number.
But sometimes, we need it to be number string. For example, in chakra radio, chakra will change number to string number.
Is it nessesary to keep this logic?

• select @chenenpei
• stack @chenenpei
• checkbox @chenenpei
• input
• box @chenenpei
• tabs @Yuyz0112
• table @Yuyz0112

Although we are making a GUI editor, a text editor may be also very useful in some use cases.

In most cases, the response of api cannot be used directly. So a transformer function is needed to do some convert job.

define a better API spec for all the events

Sometime I need to use some custom dependecies or functions in expression. So a mechanism is needed to inject dependency to eval scope. It may work like registry.

The design of expression evaluation

Status Quo

Expression is a core feature of sunmao-ui. For example, when a user defines an expression like this:

{{ btn_1.value.toUpperCase() }}

sunmao-ui will:

1. Look up the state store and find the state of the component with id btn_1.
2. Get the state of btn_1 and evaluate .value.toUpperCase(), which will access the key value and call toUpperCase to the value.

Beyond this, we still have another two design goals to accomplish:

1. Reactive. The UI uses the result of this expression should re-render when btn_1.value changed.
2. Performant. Other changes in the state store should not trigger this UI re-render, for example, btn_2.value and btn_1.other_key.

So in the first version of expression evaluation, we use zustand under the hood, but this implementation soon encountered some problems.

non-transparent usage
Currently, components need to use the useExpression hook to get the reactive result from the state store.
There are two main drawbacks:

1. It costs more time to 'wrap' an existing UI component to a sunmao-ui one. Especially for those who have many props and all of them want to support expression.
2. It breaks the type system of sunmao-ui. For example, props with type 'array of numbers' in the runtime need to declare it also accepts a string.

performance
Zustand builds its reactive model with the broadcasting approach. We will dive into a comparison of different designs of reactive models later. For now, the conclusion is it's hard to optimize performance with broadcasting-based implementations.

Reactive model

There are two kinds of implementations of the JS reactive model.

Broadcasting

In this implementation, all the consumers will subscribe to the state store. And whenever the state store was modified, it will broadcast to all the subscribers with the latest state.

This makes all the subscribers 'reactive' but is not performant because they may get notified of the changes they do not need.

Two common patterns to solve the performance issue of broadcasting are equality-checking and partition.

equality-checking
The reactive model will check whether the current value is equal to the previous value. If they are the same, the broadcasting will be skipped.

But equality-checking also has an overhead with itself. So most reactive models are using 'strict equality' or 'shadow equality' for checking. Both of them lose effectiveness when the values have 'deep equality' but have different references, like [{ v: 1 }] !== [{ v: 2 }].

partition
Partition means to split the state store into many small state stores. After partition, the range of broadcasting will be limited by one store.

But partition is not friendly to the expression usage. Because it's hard to extract which store has been used from a raw expression.

Dependency Tracking

Dependency tracking means collecting the dependencies during consumption. So it constructs an accurate dependency map between consumers and states in the store.

But tracking is not a simple thing in JS, so we'd better using some battle-tested library instead of building one from the scratch.

build time tracking
Svelte uses this approach by statically analyze code and tracking dependencies by 'assign statements'.

runtime tracking
Vue uses this approach by wrapping values into JS Proxy and hijacked all the accesses.

Since Vue3 provides a standalone library @vue/reactivity just do what we want without introducing build time work, we decided to implement the new expression evaluation with it.

Evaluation scope

Previously, we copy store states to the global scope before evaluation and tear down after it.

But the copy process will access all the states which lets the dependency tracker think this evaluation depends on all the states. So we need to change the scope evaluation to a custom scope without shadow copy.

A solution with the with keyword looks like this:

function maskedEval(expression, mask) {
  return new Function(`with(this) { return ${expression} }`).call(mask);
}

maskedEval('console.log(a)', { a: 1 }) // 1

• can edit component id
• can edit properties(include nested properties)
• ignore some special fields(like layout in grid, columns in table...)
• use input

Component Spec

1. remove acceptTrait
2. add styleSlots and events. Both of them are simple string array.

 type Component = {
  version: string;
  kind: 'Component';
  metadata: Metadata;
  spec: ComponentSpec;
};

type ComponentSpec = {
  properties: JSONSchema;
  state: JSONSchema;
  methods: MethodSchema[];
  styleSlots: string[];
  slots: string[];
  events: string[]
};

Trait Spec

1. add returnProps. returnProps are keys of the object returned by trait. For now, there are only 2 keys: styles and callbackMap. Component can only deal with these 2 props.

 type Trait = {
  version: string;
  kind: 'Trait';
  metadata: Metadata;
  spec: TraitSpec;
};

type TraitSpec = {
  properties: JSONSchema;
  state: JSONSchema;
  methods: MethodSchema[];
  returnProps: string[]// styles, callbackMap...
};

This results in some bugs, like events triggered in editor will effect previewModal.

• support custom listItem template
• support access itemRow data in expression
• support pagination
• enhance expression to support both {{ }} and itemRow

Chinese Version: https://thoughts.teambition.com/share/6124b6fdf1962900423f2e5e

• New Trait Implementation
• Refactor Validation Trait
• Refactor Event Trait
• Refactor State Trait
• Refactor Hidden Trait
• Global Event Handler
• Adaptor between Component & Trait

Why we need new implementation

1. Trait is now implemented based on executing hooks in a loop, which is not the correct usage of hooks.
2. Dynamic creating component in Trait hook will cause unnecessary mount & unmount. see demo on branch validation-bug

New implementation

1. Components will received props from Traits. Components should implement some defined capabilities of components (such as how to deal with style, data, etc.)

2. Trait is an ordinary function, not a Hook.

3. Trait accepts the parameters from the Schema, and then returns an object. This object is implemented in accordance with defined capabilities of component.

4. Merge all the objects returned by Trait and pass them to the component.

1. Each component must implement some interface to interact with traits

2. Hook cannot be used in Trait (or the number of Trait cannot be changed dynamically?)

3. Cannot use HOC in Trait

How to implement the existing Trait?

1. Hidden

   1. Return style, use display: none

2. State

   1. Return data, and the component calls mergeState to bind it to the store

3. event

   1. Return the callback function. The timing of unsubscribe is controlled by the component.

• support undo/redo
• add/remove/edit component/trait
• move component

The types are too complicated and chaos in runtime project. See in RuntimeSchema.ts

Because every time '{{[]}}' is evaled, a new [] will generate, so that watch function treat is as a different value then trigger callback.

By the way, '{{{}}}' cannot be parsed correctly.

Before saving schema, we need validate in advance. If the broken schema is saved, sunmao-ui editor cannot render it any more.

Because ComponentWrapper wraps component with a div, the style may broke in some cases. For example, components in HStack will not auto stretch to fill the width of HStack.
And also because of this, applications may look different in editor and runtime.

Currently, we supported trait pass props to the component to which it attached.

To extend the usage scenario of trait, we will let the trait return a HOC as the wrapper of the component. With this feature, we can implement traits like hidden.

When using module as template in list, we may write something like this {{ moduleName{{$listItem.id}}.stateValue }}. This expression cannot be parsed correctly now.

• can update schema when resize grid

current implementation with multiple expression:

expression: `"constantA"+{{ variableA }} + "constantB" + {{ variableB }}`

expected:

expression: `constantA{{ variableA }}constantB{{  variableB }}`

• can display components structure
• can remove component
• can select component
• can reorder component(use button)
• can add new component in slot

• can automatically generate form from Schema
• support array field
• support boolean, number...
• ...

Now we can move node in the same level. But sometime we need move node across level.
I guess it will not be difficult since we just need modify slot name. The difficult part may be the UI.