Let’s imagine that we design clean Component Model, like this:
<**Application**>
<**Tree**/>
<**Grid**>
<**Combo**/>
<**button**>*Add*</button>
<**button**>*Delete*</button>
</Grid>
</Application>
After adding application logic, the render will look like:
Pretty simple, isn’t it?
But finally, after applying UI mockup, it will turn out to be the something like this:
We need to extract application logic bindings fromrender()
method of our
application/component to the separated entity — let it beProperty Sheet.
First, start with basic Application Layout:
Then add State Management bindings by the Property Sheet:
Next, extend Application Layout by creating Bootstrap Layout:
Now, as you can see, we have separated application logic in Application Layout , and all UI-related code in Bootstrap Layout. So, we can easily switch layouts: theoretically we can make mobileReact Native app, that will reuse application logic code!
This is the variation of Container Components pattern, where many small Presentation Components can be replaced by one–two Presentation Layout(s ). In HTML/CSS people use markup for data and CSS for styling.
CPS concept is the opposite: we should use markup for styling,
and** **Cascading Sheets to transfer the data. applyPropsSheet( this || this.propsSheet, React =>
)
-
applyPropsSheet()
temporary substitute jsx pragma by setting customReact.createElement
(that’s purpose ofReact =>
callback) -
build tree of arrays
[type, props, ...childs]
(args for jsx pragma):[Application, null,
[Tree],
[Grid, null,
[ Combo ],
['button', null, 'Add'],
['button', null, 'Delete']
]
] -
add properties from PropsSheet to that tree
-
call real
React.createElement
on each node of the tree,
and return root react element