<> preface
The previous article explained logic and Runtime&DSL, Also mentioned the logic arrangement three board axe ： element + Choreographer +
Runtime, In this article, I will mainly talk about component design and YOHO Platformization of .
<> element
Components in our design , It is divided into basic components and business components , The business component is the warehouse we need to create , Write source code , Submit published components , It is an entity of a logical fragment ; All but it are basic components , We're in the process of designing an arrangement for Hollywood . Base component has only start component and end component , Just to reduce the use cost of non R & D personnel , As few components as possible .
Although it is divided into basic components and business components , But the business component is essentially a special type of basic component , Their relationship is similar to that of trees and graphs , Tree is also a kind of graph , But books are often divided into separate chapters , Because the tree system is big enough . Business components are also , It is the
Custom element , But its proportion in the component system is large enough , So we also take it out as a big category .
Component language
Several important attributes of business components are as follows ：
After initializing the service element , The file structure we defined ：
. |-- schema | |-- input.json | |-- output.json | `-- branch.json |-- index.js
|-- package.json
*
index.js: Component entry file , The source code is written in it , The source code in the file will be used as code Field to store
*
package.json: Component dependency Is to read from inside , Store as a dependency of a component , and code Field
*
input.json: To render attribute forms when configuring component orchestration JSON Schema, As a component input Field to store
*
output.json: Return value used to describe the component , Also JSON Schema, As a component output Field to store
*
branch.json: Description component has several branches , And what is the Chinese definition of each value
We have made a specification for the code of branch judgment in components , coordination branch.json
, Minimize the use cost of this branch business component , The complexity of use is transferred to the constraints of development . take 《 Determine whether to log in 》 Component example , It has two branches , Logged in And
Not logged in , The branch judgment of the code must be written in the following format ：
function foo() { if (isLogined) { return { branch: 0, data: { key: value } } }
else { return { branch: 1, data: { key: value } } } }
If logged in , return branch Value is 0 , If you are not logged in , return branch Value is 1. So the corresponding branch.json Must be so defined ：
[' Logged in ', ' Not logged in ']
Returned in component branch Value of , Will act as branch.json Index in , The actual judgment criteria for branches in components shall be the same as branch.json The arrays in are one-to-one on , such
runtime Will execute the logic according to the correct direction .
Component overall design
Foundation tool side , We provide the ability of template initialization , Provide corresponding component development scaffold , Ensure basic development capability of components , Under construction VSCode Plug ins are used to enhance the R & D experience , Component based
OpenApi Provided element SDK Can help components enter the component Market , At present, it only serves local R & D ,4 Monthly meeting to supplement the capability of online component development . Form configuration items for components
form-render Realize visual form construction , Very easy to use , give the thumbs-up .
Based on infrastructure , The upper layer realizes a unified component Market , According to the application , Labels, etc , Components of all services converge in the component Market , It is convenient to be unified into Youku material center in the future .
Lifetime of components
A component from being produced to being arranged , Last run on page , Through the whole process of logical arrangement , Also “ Logic is the core ” Argument of , Let's take a look at what has happened in the whole logic arrangement process from the perspective of components .
After the component is published , Enter the component Market , In the editing interface , Drag to generate component instance , Build complete business logic . In canvas ,branch.json Used to explain the various branches ,input.json
Medium json schema adopt form-render
Render as a configurable form . After the orchestration instance is created , And UI Orchestration for Association , stay UI Set up the pit created in the platform , The return value rendering after component execution is required UI,UI Building the platform will resolve the components
output.json , Tile all data . After the business module is set up , Follow the page to launch ,runtime after start-up --> DSL analysis --> Component loading & register
--> Component inspection --> Component execution Link execution service related actions , stay Component execution This step ,runtime Will proceed helper and payload
injection , Provides help functions and configuration data .
Two questions
Here are two issues that we debated during the landing , I also hope you can put forward your own opinions .
* First, business components still End component ?
* Component JSON Schema Can it be modified ?
<> Logical arrangement of front-end features
Currently, there are more service arrangements and business arrangements in the group , There are also logical arrangements on the server side , The logic arrangement on the front side is rare . If you're right about logic , Business arrangement , The service layout is not very clear , Recommend this article
—— 《 Business arrangement , Service Orchestration , Differences in logical arrangement 》. In the process of building the visual system on the ground , In combination with the construction technology, we have done a bit of front-end qualitative implementation .
Our module building system , Each module generates a corresponding CDN resources , When the page is assembled , The module resources used in the page will be spliced at the server —— JS
Combo. In the process of logic arrangement , We don't want to invade existing build services , Increase development adaptation , Second, I don't want the logical layout to increase the page size JS Bundle. So in runtime
of dslWillInterpret In the life cycle , We dynamically load the resources of logical elements on demand . The components are very small , Corresponding to a complete process JS Only a few resources
KB, This loading time can be ignored temporarily . Matching on loaded components JS Resources for cache reuse , The volume of resources to be loaded will be further reduced .
This solution helped us solve another problem , In the same business module , I will create multiple orchestration instances , Two orchestration instances may have different versions of the same component during maintenance , In this scenario , If we do not load dynamically on demand , Of the page
JS Bundle May expand uncontrollably . Look back now , Dynamically load logic elements on demand , Help us change the logic of the page from JS Bundle And pulled out , Replaced by a simple
DSL, Of the page JS Bundle And smaller , The performance can be improved .
<>YOHO platform
YOHO The structure of the platform is as follows .
On the far right of the graph , Yes, we do YOHO Positioning of , It is a platform . We don't want to be a completely centralized platform , We just want to bind the agreement , standard , Based on this arrangement protocol node
service , External provision
OpenApi; On the front interaction side , Do not expect a set of interactions to meet all businesses , The outer frame of the choreographer only implements the adapters of each plate based on the choreography protocol , You can choose to use or not use the panel or canvas provided by us , Or optional , The choreographer will also implement automatic checking based on this protocol , Ability to arrange snapshots .
Seeking common ground while reserving differences is our choice .
<> Future planning
FBP, The last kilometer of business logic arrangement
It needs to be mentioned that we did YOHO platform , The vision of building a platform for service marketing . Arrange business modules from easy to difficult , front 75% Modules of will be covered by logical orchestration . The rest 25% It contains our playing methods or highly customized modules , Their common features require high logic , Multiple internal states , Want to support , Can also support , But component commissioning release , It is very troublesome to arrange, debug and release , In our expectation , This part of complex modules is undertaken by R & D .
Is there any solution for the last kilometer of logic arrangement in visual construction ? Is solvable , Expand based on existing capabilities FBP ability , Enable R & D to program based on flow , Write online --> Online test -->
Process error correction , You can not only develop faster , And your code will be more secure .
<> summary
The value of logical arrangement ：
visualization ： Simplifies production of business logic
UI And logic decoupling ： Improve maintainability of business modules
Logical reuse ： Logic can produce different behaviors by connecting in many different ways , Better code reusability
Natural span , Cross container ： Because it's pure JS implement , Natural fit at each end , In each container . Its more profound significance is , If UI + Logic can cover all module development , about rax0.6 rise
1.0,Weex cut Kraken This scenario , Migration costs can be reduced 90+%
Online test , Automatic error correction ： Make your code more secure
YOHO Value of ：
Unified logic layout specification constraints within a large team
Convenient tools / The library facilitates the implementation of logical arrangement in business
Technology