Cross-end reuse practice of front-end components (1)

Our page is mainly composed of two parts: 1. Logic 2. If the view wants to be reused across ends, then you can start from the above two aspects. Generally, there are several situations for cross-end pages.

1. The requirements are the same, and the logic in the corresponding page is exactly the same. The view layer only uses different names of UI components (div is written in h5, View is written in the applet), and the logic layer needs to be completely reused.
2. The requirements are the same, and the corresponding logic and UI components are only partially different, and the common parts need to be reused
3. The requirements are completely different, each side writes its own, no need to reuse

Correspondingly, there are 2 multiplexing schemes

Multiplexing logic, injecting UI components at multiple ends

Extract the logic into a common common module, and then introduce the corresponding logic implementation in the projects at each end, and inject the logic into the UI components. See the specific code:

 // model.tsx
export const model = (props: any) => {
  const [name, setName] = useState(props.name)
  const [age, setAge] = useState(props.age);
  return {
    name,
    setName,
    age,
    setAge,
    ...props
  }
}
// mini view.tsx
import { model } from './common/model'
const miniView = (props: any) => {
  const { name, setName, age, setAge } = model(props)
  return <View onClick={setName}>
    <Text>{name}</Text>
    <Input value={age} onChange={setAge} />
  </View>
}
//h5 view.tsx
import { model } from './common/model'
const h5View = (props: any) => {
  const { name, setName, age, setAge } = model(props)
  return <div onClick={setName}>
    <p>{name}</p>
    <Input value={age} onChange={setAge} />
  </div>
}

the benefits of doing this

1. Logic reuse to improve efficiency
2. The logic and view can be changed in both the model layer and the UI layer. For the situation where the cross-end page requirements are partially the same, it is more friendly and can be adjusted flexibly. The common logic is written in the model, and the difference logic is written in the View layer

Multiplexing logic + view

The way of solution 1 is to separate the logic and UI. If we reuse the two together, the efficiency will be more obvious, but the following problems will be encountered.

1. The underlying UI components at each end are inconsistent

2. Each end will have its own specific adjustments. For problem 1, the underlying UI components are inconsistent, which can be achieved by introducing a glue layer, leveling the API of each end, and then modifying the reference path.

    // h5 rn mini引入View的方式都相同
   import { View } from 'XXComponents'
   
   //在编译时修改引用路径
   // h5 index.ts
   import { View } from 'XXComponents/h5'
   // rn index.ts
   import { View } from 'XXComponents/rn'
   
   //xxComponents/h5中
   const View = div
   export View
   
   //xxComponents/rn
   import { View } from 'react-native'
   export View = View

   For problem 2, the project file directory structure is: after the project is started, the common folder is copied to h5 | mini | rn in the form of a soft link

    ├── package.json
   ├── projects
   │   ├── common
   │   ├── h5
        ├── common
        ├── package.json
   │   ├── mini
        ├── common
        ├── package.json
   │   └── rn
        ├── common
        ├── package.json

For example, we have a PageA (with three ends), A has a component B (all three ends), and there is a component C in the B component (in h5, rn, not in the applet), similar to the following figure

 // pageA
import B from './Components/B' // 引用common文件夹中的B组件
import C from '../../Components/C' // 引用各端自己定义的C组件
<PageA>
  <B>
    <C></C>
  </B>
</PageA>

Then the processing method is:
The logic layer of ComponentC is written in the Common folder, and the View layer of ComponentC is written in the folders at each end. h5 | rn introduces the logic of ComponentC at the same time, and mini does not introduce logic code. code show as below

 // h5 componentC
import Model from '../common/modelC'
const ViewC = () => {
  const state = Model()
  return <div>
  {state.name}
  </div>
}
// rn ComponentC
import Model from '../common/modelC'

const ViewC = () => {
  const state = Model()
  return <View>
  {state.name}
  </View>
}

// mini ComponentC
const ViewC = () => {
  return null
}

This maximizes code reuse and maintains a clean and maintainable architecture