1. Brief introduction of SDR
SDR (server driven rendering) server-driven rendering, moving the custom rendering of components to the back end, the focus is to create components that can be completely controlled and changed from the back end, it can greatly help the company solve the following problems:
1. Micro front end
2. Target audience with different designs
3. A / B Test for targeted mobile applications
4. Component version control for different application versions
5. Edit components in production after release (dynamic update, codepush, webview)
6. Fixed some errors, but did not publish the new application version to the app store (dynamic update, codepush, webview)
Unlike Codepush, CodePush has a wide range of functions. The remote configuration is mainly used for the original value, and it can solve the problem that the view cannot be synchronized in time due to the hotter progress. At the same time, the implementation of SDR will also face the following problems:
1. Safely update our component definitions while maintaining backward compatibility.
2. Share the type definition of our components across platforms.
3. Respond to events at runtime, such as clicking a button or user input.
4. Rendering fully custom components without existing implementations at build time. (Try the Lona format)
5. The time taken to parse to the component generation process
The advantages and problems brought by SDR can basically meet our relatively lightweight construction of page components in daily development. How to build an SDR container to make it easy to use, easy to extend, and safe and robust becomes extremely important.
Second, SDR construction analysis
Before building an SDR container in RN, let's analyze how the components in RN are composed. Let's first look at a simple example
<View style={{ width: 100 }}>
<Text style={{ fontSize: 10 }}>
sdr
</Text>
</View>In the code, the basic View component is defined, the Text component is defined in the View component, and the style property is set separately. So the basic components roughly contain the following attributes:
1. Component name and type
2. Component properties (props, custom props, etc.)
3. Children of the component
So the premise of building SDR is that we need to define a set of "rules" to constrain how the front end creates components, attributes, and subcomponents. Therefore, the protocol to which the above components are mapped can be roughly defined as follows:
{
type: 'View',
props: {
style: {
width: 100,
}
},
children: [
{
type: 'Text',
props: {
style: {
fontSize: 10,
}
},
children: 'sdr'
}
]
}As you can see, we define the component as type, the property as props, and the child component as children. As the type mapping, we need to prompt to define it, for example, type: 'View', corresponding to the View component in RN, so the type protocol of sdr is as follows:
sdrTypes: {
Text: Text,
View: View,
Image: Image,
Button: TouchableOpacity,
},After the rules are defined, the next step is to traverse and analyze the props and children. During the parsing process, because the components are nested, you need to use a recursive algorithm to gradually complete the analysis of type, props, children, and finally call React The .createElement method can complete the creation of the component.
3. Dynamic control of attributes
In the protocol declaration, the attributes are basically defined. If the value of an attribute needs to be controlled by the front end, it needs to be defined with a placeholder. The front end uses the value to match the placeholder and replace it. Therefore, we can define the following rules for props, text, and function:
prop :: props structure
defined by the front end text :: value structure
defined by the front end function :: method structure defined by the front end
The above looks more abstract. Simply put is to define a placeholder prefix, mark the current type, and concatenate specific numeric values later. Let ’s look at an example. For example, we want to define the “sdr” displayed in the Text component through the front end, then the component The rendering rules are as follows:
{
type: 'Text',
props: {
style: {
fontSize: 10,
}
},
children: '${text::userInfo.userName}'
}As you can see, the children of the Text component are defined as "$ {text :: userInfo.userName}", and then in the process of parsing children, it will match whether it contains "text ::", if yes, it will get the front-end definition Data structure, and get the final value to replace, so the front end needs to define the structure of the data:
userInfo={{
userName: 'sdr',
}}In this way, in the process of parsing, the value of userName under userInfo will be taken, and the children will be replaced, and finally the children: 'sdr'. Similarly, the definition of props and function is the same.
Four, use
1. Configuration Statement
const ClientConfig = {
sdrTypes: {
Text: Text,
View: View,
Image: Image,
Button: TouchableOpacity,
},
loading: false,
error: false,
renderError: () => {},
renderLoading: () => {},
};(1) sdrTypes declares the mapping relationship between sdr templates and components
(2) loading, error, renderError, renderLoading declare the loading and failure status and the corresponding view display
2. Provider provides basic configuration, SDRView as a rendering component, and generates a corresponding component tree based on the provided sdr template. The placeholder data involved in the template needs to be passed in as props in SDRClient
<Provider config={ClientConfig}>
<SDRView
sdrTemplate={sdrTemplate}
test={testData}
item={{
info: {
buttonName: 'btn',
},
}}
/>
</Provider>
3. The sdrTemplate template can be pulled from the server side and set to SDRView
V. Summary
From an overview of the principle to a simple practice, the rendering method using SDR in React Native is basically realized. The current problems are as follows:
Support multiple style analysis, for example, the back-end template defines the default style and merges with the front-end
The source code can refer to https://github.com/songxiaoliang/rn-sdr
