React Component Design Practice Summary 04 – Component Thinking

The basic code structure for the hooks in general is:

Function useHook(options) {// ⚛️states const [someState, setSomeState] = useState(initialValue); // ⚛️derived State const computedState = useMemo(() => computed, [dependencies]); // ⚛️refs const refSomething = useRef(); // ⚛️side effect useEffect(() => {}, []); useEffect(() => {}, [dependencies]); // ⚛️state operations const handleChange = useCallback(() => {setSomeState(newState)}, [] // ⚛️output return <div>{... }</div> }Copy the code

Custom hooks and function components have the same code structure, so sometimes hooks write more like components, and components write more like hooks. I think you can think of a component as a special hook that outputs the Virtual DOM.

Some considerations:

• Hooks can only be called at the top level of the component. Do not call hooks in loops, control flows, and nested functions
• You can only call hooks from the React function component
• Custom hooks are named use*

Summary common scenarios for hooks:

• Side effects encapsulation and listening: for example useWindowSize(listening window size), useOnlineStatus(online status)
• Side effects: useEffect, useDebounce, useThrottle, useTitle, useSetTimeout
• DOM event encapsulation: useActive, useFocus, useDraggable, useTouch
• To get the context
• Encapsulate reusable logic and state: useInput, usePromise(asynchronous request), useList(list load)
  • Replace higher-order components and render Props. For example, use useRouter instead of withRouter and useSpring instead of the old Spring Render Props component
  • Replacing container components
  • State manager: use-global-hook, unstated
• Extended state operations: The original useState was simple, so there was a lot of room to expand, such as useSetState(emulated old setState), useToggle(Boolean toggle), useArray, useLocalStorage(synchronized persistence to local storage)
• Keep your imagination open… The search for hooks continues

Learning hooks:

• The official documentation
• React Hooks
• React Today and Tomorrow and 90% Cleaner React With Hooks
• hook-guide
• How to Build Wheels with React Hooks
• Making Sense of React Hooks
• React hooks: not magic, just arrays

5. Hooksresponsiveprogramming

One of Vue’s most unique features is its non-invasive responsive system, which manipulates component state in accordance with Javascript’s data manipulation conventions and then automatically responds to the page. React provides setState. For complex component states, setState can make code stinky and long. Such as:

this.setState({ pagination: { ... this.state.pagination, current: defaultPagination.current ||1,
    pageSize: defaultPagination.pageSize || 15,
    total: 0,}});Copy the code

Then mobx came along, and it was pretty close to the Vue development experience:

@observer
class TodoView extends React.Component {
  private @observable loading: boolean;
  private @observableerror? :Error;
  private @observable list: Item[] = [];
  // Derived state
  private @computed get completed() {
    return this.list.filter(i= > i.completed)
  }

  public componentDidMount() {
    this.load();
  }

  public render() {
    / / /...
  }

  private async load() {
    try {
      this.error = undefined
      this.loading = true
      const list = await fetchList()
      this.list = list
    } catch (err) {
      this.error = err
    } finally {
      this.loading = false}}}Copy the code

Mobx also has a number of drawbacks:

• Code invasions. All components that need to respond to data changes need to use observer decorations, properties need to use Observable decorations, and data manipulation methods. The mobx coupling is deep and the cost of switching frameworks or refactoring later is high

• Compatibility: Proxy was used for refactoring after mobx v5, but Proxy was not supported until Chrome49. You can only use V4 if you want to be compatible with older browsers, and V4 has some pits that are hard to spot for newcomers to Mobx:

  • The Observable array is not really an array. Antd’s Table component, for example, does not recognize mobx’s array and needs to be passed in to components for conversion using slice
  • Adding properties to an existing Observable is not automatically captured

That’s where hooks come in, which makes component state management simpler and more straightforward, and which is close to the Mobx philosophy of responsive programming:

1. Declare state succinctly

State is the data that drives your application. Such as UI state or business domain state

function Demo() {
  const [list, setList] = useState<Item[]>([]);
  // ...
}
Copy the code

2. derivative

Anything that comes from a state and doesn’t have any further interaction is derivative. This includes user views, derived states, and other side effects

function Demo(props: { id: string }) {
  const { id } = props;
  // Replace Mobx Observables: get lists, request when mounting or id changes
  const [value, setValue, loading, error, retry] = usePromise(
    async id => {
      return getList(id);
    },
    [id],
  );

  // Derived state: replaces Mobx with computed
  const unreads = useMemo((a)= > value.filter(i= >! i.readed), [value]);// Side effect: automatic persistence after value changes
  useDebounce(
    (a)= > {
      saveList(id, value);
    },
    1000,
    [value],
  );

  // Derived view
  return <List data={value} onChange={setValue} error={error} loading={loading} retry={retry} />;
}
Copy the code

So hooks are revolutionary in that they make the flow of component state data much clearer. Instead of a class component, we might normally do data comparisons in the componentDidUpdate lifecycle methods and then trigger some methods imperative. For example, getList is triggered when an ID changes and saveList is performed when a list changes.

Hooks seem to dilute the concept of a component’s life cycle, allowing developers to focus more on relationships of states and think about component development in terms of data flow. Dan Abramov’s principle of “Don’t block the flow of data” in writing resilient components confirms my belief:

Whenever you use props and state, consider what happens if they change. In most cases, components should not handle the initial rendering and update process differently. This allows it to adapt to changes in logic.

Check out awesome-react-hooks, open source hook schemes that are interesting. For example, rxjs-hooks, a clever combination of React hooks and RXJS:

function App(props: { foo: Const value = useObservable(Inputs $=> inputs$. Pipe (map([val]) => val + 1)); [props.foo]); return <h1>{value}</h1>; }Copy the code

6. Class inheritance is also useful

As the React documentation states: “We use thousands of components in React, but we haven’t found anything that would recommend you use inheritance.” React tends to be a combination of functional programming, and object-oriented inheritance has few practical application scenarios.

Inheritance may come in handy when we need to convert some traditional third-party libraries into React component libraries. Because most of these libraries are organized using object-oriented paradigms, typically the Map SDK. Take Baidu Map as an example:

Baidu Map has various component types: Controls, Overlays, tileLayers. Each of these types has multiple subclasses. For example, overlay subclasses include Label, Marker, Polyline, etc. All subclasses have the same life cycle and are rendered to the map canvas using the addOverlay method. We can extract their lifecycle management from the parent class by inheritance, for example:

// Overlay Abstract class, which manages the Overlay lifecycle
export default abstract class Overlay<P> extends React.PureComponent<OverlayProps & P> {
  protectedinitialize? :(a)= > void;
  // ...
  public componentDidMount() {
    // Subclasses are instantiated in constructor or initialize methods
    if (this.initialize) {
      this.initialize();
    }

    if (this.instance && this.context) {
      // Render to Map canvas
      this.context.nativeInstance! .addOverlay(this.instance);
      // Initialize parameters
      this.initialProperties(); }}public componentDidUpdate(prevProps: P & OverlayProps) {
    // Attribute update
    this.updateProperties(prevProps);
  }

  public componentWillUnmount() {
    // The component is uninstalled
    if (this.instance && this.context) {
      this.context.nativeInstance! .removeOverlay(this.instance); }}// ...
  // Other common methods
  privateforceReloadIfNeed(props: P, prevProps: P) { ... }}Copy the code

Subclasses make it much easier to declare their own properties/events and instantiate concrete classes:

export default class Label extends Overlay<LabelProps> {
  public static defaultProps = {
    enableMassClear: true};public constructor(props: LabelProps) {
    super(props);
    const { position, content } = this.props;
    // Declare supported properties and callbacks
    this.extendedProperties = PROPERTIES;
    this.extendedEnableableProperties = ENABLEABLE_PROPERTIES;
    this.extendedEvents = EVENTS;

    // Instantiate the concrete class
    this.instance = newBMap.Label(content, { position, }); }}Copy the code

The code comes from react-bdmap

Of course this is not the only solution; it can also be done using higher-order components and hooks. But for libraries that are already organized in an object-oriented paradigm, inheritance is more understandable

7. Mode box management

Modal box is used frequently in application development, especially in middle and background management system. React is not particularly fun to use. The typical code is as follows:

const Demo: FC<{}> = props => { // ... const [visible, setVisible] = useState(false); const [editing, setEditing] = useState(); const handleCancel = () => { setVisible(false); }; Const prepareEdit = async (item: item) => {// Loading detail const detail = await loadingDeatil(item.id); setEditing(detail); setVisible(true); }; const handleOk = async () => { try { const values = await form.validate(); // Save await save(editing. Id, values); / / hide setVisible (false); } catch {} }; return; <> <Table dataSource={list} columns={[{text: ' ', render: Item => {return <a onClick={() => prepareEdit(item)}> Edit </a>; }},]} / > < Modal visible = {visible} onOk = {handleOk} onCancel = {handleHide} > {/ * * form rendering /} < / Modal > < / a >; };Copy the code

The code above is too ugly, with irrelevant logic piled up under a single component that does not fit a single responsibility. So we’re going to extract the modal box-related code and put it in EditModal:

const EditModal: FC<{ id? : string; visible: boolean; onCancel: () => void; onOk: () => void }> = props => { // ... const { visible, id, onHide, onOk } = props; const detail = usePromise(async (id: string) => { return loadDetail(id); }); useEffect(() => { if (id ! = null) { detail.call(id); } }, [id]); const handleOk = () => { try { const values = await form.validate(); // Save await save(editing. Id, values); onOk(); } catch {} }; Return (<Modal Visible ={visible} onOk={onOk} onCancel={onCancel}> {detail.value && {/* Form render */}} </Modal>); }; / * * * use * / const Demo: FC < {} > = props = > {/ /... const [visible, setVisible] = useState(false); const [editing, setEditing] = useState<string | undefined>(undefined); const handleHide = () => { setVisible(false); }; const prepareEdit = async (item: Item) => { setEditing(item.id); setVisible(true); }; return; <> <Table dataSource={list} columns={[{text: ' ', render: Item => {return <a onClick={() => prepareEdit(item)}> Edit </a>;  }, }, ]} /> <EditModal id={editing} visible={visible} onOk={handleHide} onCancel={handleHide}> {' '} </EditModal> </>; };Copy the code

The edit-related logic is now extracted to EditModal, but the Demo component also maintains the open state of the modal box and some data state. A complex page can have a lot of modal boxes, and the code becomes more and more disgusting, with all kinds of xxxVisible states flying around. From a practical development perspective, the simplest way to do modal box control would look like this:

Const handleEdit = item => {editmodal. show({// 🔴 starts the popover as a function call. This is consistent with the modal box idiom, which does not care about the visible state of the modal box. For example, window.confirm, wx.showmodal ().id: item.id, // 🔴 Pass data to the modal box onOk: saved => {// 🔴 Event callback refreshList(saved); }, onCancel: async () => {return confirm(' cancel '); // Control mode box hidden},}); };Copy the code

This approach is also controversial in the community. Some people think it is the anti-mode of React. Does @Lisangeng violate the React mode in modal. confirm? That’s the question. Take the picture for example:

The picture also comes from the article of Desire

The red line is time-driven (or timing driven) and the blue line is data-driven. Lu Sangeng believes that “even a React project with obvious data-driven characteristics still has many parts that are not data-driven but event-driven. Data can only drive state, only timing can drive behavior, and for a timing driven behavior, you have to harden it into a data-driven state, don’t you think it’s strange?” I’m not going to judge whether he’s right or wrong, but some scenarios are strictly ‘data-driven’ and can have a lot of template code that can be uncomfortable to write.

So how to implement?

Consider the antD Modal.confirm implementation, which uses reactdom. render for plug-in rendering, or the Context API. Close to ideal (at least in API terms) is react-comfirm:

/** * EditModal.tsx */ import { confirmable } from 'react-confirm'; const EditModal = props => { /*... * /}; export default confirmable(EditModal); /** * Demo.tsx */ import EditModal from './EditModal'; const showEditModal = createConfirmation(EditModal); const Demo: FC<{}> = props => { const prepareEdit = async (item: Item) => { showEditModal({ id: Item. id, // 🔴 Pass data to the modal box onOk: saved => {// 🔴 call refreshList(saved); }, onCancel: async someValues => {return confirm(' cancel '); // Control mode box hidden},}); }; / /... };Copy the code

The downside of using reactdom.render is that you can’t access the Context, so compromise and use the Context API as an example:

extension

• Modal.confirm
• Does modal. confirm violate the React mode?
• Use render props to abstract the state of the Modal component
• react-confirm
• How to Use React’s New Context API to easily manage modals Context-based scenarios

8. Use Context for dependency injection

Context provides a way to pass data to the component tree, eliminating the need to manually pass props properties at every level.

Context is used a lot in React applications, and the new Context API is very easy to use. Context is often used in the following scenarios:

• Share data that is considered “global” to a component tree. Such as current authenticated user, topic, I18N configuration, form status
• Configure the behavior of a component, such as ANTD’s ConfigProvider
• Communication across components. It is not recommended to communicate by ‘events’, but by’ states’
• Dependency injection
• Context can be packaged to replace Redux and Mobx state management schemes. There will be a special article on the follow-up

Context is scoped as a subtree, that is, a Context Provider can be applied to multiple subtrees, and a subtree Provider can override the value of the parent Provider. Basic structure:

import React, {useState, useContext} from 'react' export inteface MyContextValue { state: number setState: (state: number) => void } const MyContext = React.createContext<MyContextValue>( { state: // Set the default value, throw an error, must use setState with Provider: () => throw new Error(' MyContextProvider ')}) export const MyContextProvider: FC<{}> = props => { const [state, setState] = useState(1) return <MyContext.Provider value={{state, setState}}>{props.children}</MyContext.Provider> } export function useMyContext() { return useContext(MyContext) } export default MyContextProviderCopy the code

Methods in the Context default value should throw errors warning of improper use

Extension:

• Avoid repeated rendering caused by React Context

9. An immutable state

Immutable state has important implications for the React functional programming paradigm.

• Immutable data is predictable. Immutable data makes applications easier to debug and changes to objects easier to track and derive.

  For example, Redux requires that state changes can only be made through Dispatch + Reducer, and Devtool with Redux can well track how state changes are made. This feature makes a lot of sense for large applications because the state is so complex that if you don’t organize and constrain it, you don’t know where the state changed, and it’s hard to track bugs when they happen.

  Therefore, immutable data is a basic requirement for state manager (Redux), which requires the entire application to be mapped by a single state. Immutable data can make the entire application predictable.

• Immutable data also makes some complex functions easier to implement. Avoiding data changes allows us to safely retain references to old data, making it easy to undo redo, or time travel

• Rerender judgments can be made with precision. We can simplify the shouldComponentUpdate comparison.

Popular ways to implement immutable data:

• immer
• Immutable.js

I prefer immer, there is no mental burden, according to the JS customary object manipulation way can achieve immutable data.

10. React-router: URL is state

Traditional routes are mainly used to distinguish pages. Therefore, like back-end routes (also known as static routes), front-end routes are designed to use object configuration to assign different page components to different urls. When the application is started, components matching urls are searched in the routing configuration table and rendered.

React-router V4 is a real componentized routing library. React-router is officially called dynamic routing, which refers to routes that occur during application rendering. Specifically,
becomes a normal React component that determines if a URL matches at render time, renders the specified component if it does, and returns NULL if it does not.

At this time the MEANING of URL is not the same, URL is no longer a simple page logo, but the state of the application; Application composition is no longer limited to flat pages, but multiple areas that can be nested in response to URL state. It wasn’t loved when it first came out because of the big shift in thinking. This is more flexible, so choosing V4 doesn’t mean abandoning the old way of routing your pages.

As an example, an application consists of three areas: a sidebar holds multiple entries that load lists of the corresponding type, and clicking on a list item loads details. The three areas are cascaded

First, design a URL that expresses this cascading relationship, such as /{group}/{id}. URL design generally follows the REST style, so the application structure is roughly like this:

// App const App = () => { <div className="app"> <SideBar /> <Route path="/:group" component={ListPage} /> <Route path="/:group/:id" component={Detail} /> </div>; }; // SideBar const SideBar = () => {return (<div className=" SideBar "> {/* Use NavLink to display active status when matching */} <NavLink To ="/message"> </NavLink> <NavLink to="/task"> Task </NavLink> <NavLink to="/location"> location </NavLink> </div>); }; // ListPage const ListPage = props => { const { group } = props.match.params; / /... UseEffect (() => {load(group); }, [group]); Return <div className="list">{renderList()}</div>; }; // DetailPage const DetailPage = props => { const { group, id } = props.match.params; / /... UseEffect (() => {loadDetail(group, id); }, [group, id]); return <div className="detail">{renderDetail()}</div>; };Copy the code

extension

• The React the Router philosophy
• React Router V4

11. Component specifications

• Enable StrictMode: Enable StrictMode to detect potential problems and irregularities as soon as possible
• Third party development specification:
  • Airbnb React/JSX Style Guide
  • React bits
  • react-in-patterns

extension

• recompose
• Write resilient components