You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Data management is an important piece of knowledge in frontend development. When there are too many component levels, passing through`props`becomes very difficult, so we usually use additional data management libraries for data management. Similarly, data management has gone through countless changes from the initial`flux`architecture to the latest`context`thinking, and there are many, many solutions in the industry. This chapter will explain how we perform data management in the`ssr`framework.
>Before reading this chapter, please ensure you have read and are familiar with these two chapters:[Directory Structure](/docs/features$structure) and[Data Fetching](/docs/features$fetch).
Data management solutions were proposed from the earliest`flux`architecture, which means`view layer components are not allowed to directly modify application state, they can only trigger actions. Application state must be separated and placed instorefor unified management, executing specific state operations by listening to actions`. This is the well-known`unidirectional data flow`. Of course, in real applications, we can't put all states in`store`, components can still own and directly modify their own`private state`.
10
10
11
-
实现`单向数据流` 又分为两大派系。
11
+
Implementing`unidirectional data flow` is divided into two major schools.
Some developers also think that`React+MobX` is a type-friendly clean version of`Vue`. Although the above solutions don't have absolute advantages or disadvantages, from the perspective of developer experience, solutions implemented based on`observer`thinking are superior in writing comfort.
Since data management doesn't have a single answer, in the`ssr`framework, we`may` provide multiple solutions at the framework level for users to choose from. But we always recommend using the framework's default supported solutions and not introducing external solutions on your own. We will also continuously improve this area.
In`Vue`scenarios, we provide multiple data management solutions, including the well-known[Vuex](https://vuex.vuejs.org/). Additionally, in`Vue3`scenarios, we provide an extra[Provide/Inject](https://v3.cn.vuejs.org/guide/composition-api-provide-inject.html#%E4%BF%AE%E6%94%B9%E5%93%8D%E5%BA%94%E5%BC%8F-property)solution to help simplify this functionality. If you still think the previous two solutions are too complex, we also provide the simplest`props`direct data output solution.
For specific usage of`Vuex`, developers can refer to its official documentation. We won't elaborate here. In the[Data Fetching](/docs/features$fetch) chapter, we proposed using`fetch.ts` for data fetching. In`fetch.ts`, we can get the`vuex` instance to perform related operations.
In`Vue3`, we provide another more lightweight way for cross-component data sharing, which is`Provide/Inject`. The main difference between`Vuex`and`Provide/Inject`is that every modification of global state in`Vuex`can be traced back, while variable modifications in`provide/inject`are uncontrollable. In other words, you don't know which component modified this global state.
In small to medium applications, if you completely don't consider using`Vuex`for data management, you can delete all the default example`Vuex`related code and the`store`definition folder.
During the rendering process, we will combine the`return data` from`layout fetch`and`page fetch`, then inject it into`layout/index.vue`and`layout/App.vue`in the form of`props`. Developers can`provide`in these files as shown below.
`Note: Vue2scenarios also provide this property, only used inlayoutcomponents to get merged fetch data throughprops.asyncDatafor some logical processing, not including data management functionality.`
Then you can get this data through`inject`in any component and can modify the data to automatically trigger updates. To prevent application data confusion, we recommend adding different`namespace`naming spaces for different components' return data. Similarly, when routes switch, we will automatically merge the data returned by`fetch.ts`into`asyncData`.
To prevent objects from losing reactivity, here wefollowthe rules of`refobjects`. We store the real data object in the`asyncData.value`field. And convert the entire`asyncData`to reactive. This way, we can later directly modify data through`asyncData.value = obj` or`asyncData.value.key = obj`and still keep the object`reactive`. When using this method, note that if used in`template`, you still need to add`.value`as the value won't automatically expand.
60
61
61
62
```html
62
63
// 任意组件
@@ -84,15 +85,15 @@ export default {
84
85
</script>
85
86
```
86
87
87
-
###props直出数据
88
+
###propsDirect Data Output
88
89
89
-
此功能需要依赖版本`>5.5.43`
90
+
This functionality requires dependency version`>5.5.43`.
In the`provide/inject`solution, to avoid losing reactivity, we need to use`.value`form to get specific data values, and we need to add different`namespace` for different pages'`fetch` return data to prevent property conflicts. These are all very necessary things. If developers think the current application doesn't need any data management solution, we provide the simplest`propsdirect data output` solution to allow components to get the data returned by`fetch`.
This chapter will introduce some technology choices of the`ssr`framework in different scenarios. We recommend reading[Ant Frontend Development Best Practices](https://github.com/sorrycc/blog/issues/90). We always believe that fixing a set of optimal technology choice solutions is far better than supporting diverse technology solutions.
Since we extend through plugin mechanisms, theoretically we can support any server-side framework. Currently, the official provides`Midway.js`and`Nest.js`implementation solutions that can be used directly. If you want to encapsulate a plugin based on otherNode.jsframeworks, it's also very easy. See[Plugin Mechanism](./features$plugin) for details.
8
8
9
-
##前端框架技术选型
9
+
##Frontend Framework Technology Choices
10
10
11
-
这里我们支持常见的流行前端框架`React``Vue2``Vue3`。用户可直接使用
11
+
Here we support common popular frontend frameworks`React`,`Vue2`,`Vue3`. Users can use them directly.
-Data Management: Using Hooks'`useContext`to implement minimal cross-component communication solutions, abandoning traditionalredux/dvaand other data management solutions. See[Component Communication](./features$communication) for details
In Vue3scenarios, we default to loading the[@vue/babel-plugin-jsx](https://github.com/vuejs/jsx-next#installation)plugin at the underlying level. Developers can decide whether to usetemplateor tsxapproaches for development based on personal preferences. For example, if you want to usetsx, you just need to change.vuefiles to.tsxfiles.
`Note:Vue3 + volar (VSCode plugin) + Pinia'stssupport is already excellent, not recommended to useVue3 + TSXcombination. Due to thebabelplugin's own issues,Webpack HMRhot update capabilities have certain problems in this scenario. If you must use it, it's recommended to use it together with Vite.`
40
40
41
41
```html
42
42
<template>
@@ -74,7 +74,7 @@ export default {
74
74
75
75
```
76
76
77
-
对应的tsx写法为
77
+
The correspondingtsxwriting method is:
78
78
79
79
```jsx
80
80
// render.tsx
@@ -106,10 +106,10 @@ export default {
106
106
107
107
```
108
108
109
-
##注意
109
+
##Notes
110
110
111
-
上述选型是我们经过深思熟虑后总结出来的一套优秀方案。如果开发者一定要用其他方案，例如下面介绍的
111
+
The above choices are an excellent solution we've summarized after careful consideration. If developers must use other solutions, such as those introduced below:
-`sass`, refer to [documentation](./features$faq#) can modify default`Webpack` configuration support through`chainBaseConfig` approach. But we don't recommend doing this.`90%`of framework`issue`types are caused by users modifying default configurations.
114
+
-`koa`, developing an`ssr`framework`koa`plugin only takes two minutes, but we still don't recommend doing this. If you must choose other server-sideNode.jsframeworks, please choose relatively mature ones.
115
+
-`redux`, by default doesn't support`redux`as data management, and we don't plan to support it in the future either.`redux-saga`,`dva`are the same, we don't plan to support them in the future either.`useContext`is already excellent enough. If you must choose other data management solutions, in the future we might consider the framework layer providing`MobX`or`redux-toolkit`as relatively complex data management solutions.