How to write good business code? There is a lot of business code in the front end, and if it is not written properly, it can be fatal to maintain later.

Judgment configuration

The business scenario

It is common for a field in a back-end database to have several different states, such as:

Status: 2 // The meanings of each field 0: birth 1: child 2: teenager 3: middle age 4: oldCopy the code
  • The meaning of such different numbers needs to be displayed in the front end.
  • The front-end needs to do different processing according to different states

Method 1 (Switch) (bad)

The following code is a common infinite if/else or switch scenario

// Switch (status) {caseZero: / /do something
        return 'born';
    case1: / /do something
        return 'child'; . . default:return ' ';
}
Copy the code

This is not good, because if you add another field to the back end, for example

5: deadCopy the code

Then the front end needs to modify the switch function, which needs to modify the corresponding business function, which undoubtedly destroys the integrity of the business code.

Method two (written as a configuration file) (Better)

// cfg.js
exportConst CFG = new Map ([[] 0, was born, children [1], [2, young],...... ); CFG. Get (status)Copy the code

However, this only shows the relevant state. If the judgment of the state is involved, there are some problems with this processing method. For example, it is necessary to make the corresponding judgment according to the specific state

switch (status) {
    caseZero: / /do something
        return; . . }Copy the code

As in the case above, it becomes the first case again, and obviously this configuration approach is not sufficient. If you separate the corresponding operation from the configuration, the code is more difficult to maintain.

Method 3 (Upgrade configuration files, deal with code sets) (Better)

Centralizing state handling, if you can encapsulate the state presentation and the corresponding state, will make later code maintenance very centralized.

/ / CFG. Js const status = new Map ([] [0, was born, children [1], [2, young],...... ); const checkIsBirth = (status, callback) => {if(status === 0) {
        callback && callback()
    }
}
exportDefault {status, checkIsBirth} // Import Person from for specific use'./cfg.js'
const a = 1;
Person.status.get(a);
Person.checkIsBirth(a, () => {
    console.log('Person is in Birth state');
})
Copy the code

This way, if the status changes later, you only need to change the judgment logic in checkIsBirth by one change.

Code configuration

When writing code with React, this situation is often used. Determine whether to display the corresponding components based on the situation.

Method 1 (Assembly line work) (BAD)

function Business({status, bug}) {
    return (
        <Fragment>
            {
                status === 0
                    ? (
                        <div>123</div>
                    )
                    : null
            }
            {
                bug === 1
                    ? (
                        <div>456</div>
                    )
                    : null
            }
        </Fragment>
    );
}
Copy the code

It would be nice if you just had one, but if you had a lot of them, it would make your code very verbose, and it would make your code ugly if you had a lot of them on a page. Therefore, it is suggested to divide the code into small components and encapsulate the corresponding code, which will improve the readability of the code.

Approach 2 (Component granularity refinement) (Better)

function Business() {
    return (
        <Fragment>
            <One isShow={status === 0} />
            <One isShow={bug === 1} />
        </Fragment>
    );
}

// One
function One({isShow}) {
    return (
        <Fragment>
            {
                isShow === true
                ? (
                    <div>123</div>
                )
                : null
            }
        </Fragment>
    );
}

// Two
function Two({isShow}) {
    return (
        <Fragment>
            {
                isShow === true
                ? (
                    <div>456</div>
                )
                : null
            }
        </Fragment>
    );
}
Copy the code

If it’s annoying to write this often, you can abstract generic logic into generic components.

Approach 3 (Higher-order Components) (Better)

You can wait and see how the decorator is used in the future.

function IsShowCom(isShow, Wrapped) {
    if (isShow === true) {
        return (Wrapped) => <Wrapped />
    }
    return() => null; } // If you want to forward a ref, you have to do sofunction IsShowCom(isShow, Wrapped) {
    if (isShow === true) {
        return React.forwardRef((props, ref) => {
            return<Wrapped {... props} ref={ref} /> }); }return () => null;
}
// 
import IsShowCom from './isShowCom';

function Business() {
    const One = IsShowCom(
        status === 0,
        <div>
            123
        </div>
    );
    const Two = IsShowCom(
        bug === 1,
        <div>
            456
        </div>
    );
    return (
        <Fragment>
            <One/>
            <Two/>
        </Fragment>
    );
}
Copy the code

Note ⚠ ️

Do not use higher-order components in render, as higher-order components return a new component each time, losing the state of the child components. In stateless components, however, this is fine, because stateless components themselves change with parameters, and may cause performance problems.

conclusion

The overall idea of front-end configuration:

  • When doing different things for different values, think about whether you can centralize the logic.
  • For the display/hide of components, the specific hiding logic can be encapsulated as higher-order components for easy maintenance