If /else in the front end

When writing business code, there are often conditional judgments. If there are too many criteria, there will be an if/else ladder, and if a new business scenario emerges, you will need to add another if/else. Such code is a disaster to maintain.

if (status === 0) {
  //do something
} else if (status === 1) {
  //do something
} else if (status === 2) {
  //do something
} else if (status === 3) {
  // do something
}
Copy the code

If a new business scenario appears, status === 4, then you need to write another if else, which is very unreadable.

Simple if/else —-> ternary expression

Let’s start with the simplest way to rewrite the scene: if/else:

if (status === 0) {
  action()
} else {
  do(a); }Copy the code

Like the above state judgment, in fact, is not necessary, so how to rewrite the judgment?

To eliminate the else

What else is there that’s not necessary

if (status === 0) {
  action();
  return;
}
do(a);Copy the code

Using ternary expressions

status === 0 ? action() : do(a)Copy the code

Isn’t that more concise? There is no doubt

If/Else Skyladder changed to Switch Skyladder

So we have a simple if/else, so let’s see, multiple if/else how do I rewrite that? You can improve the code with switch

switch (status) {
  caseZero: / /...case 1:
    // ...
  case 2:
    // ...
  default:
    //...
}
Copy the code

But all this does is change the if else to switch, making the code more readable. When encountering a new scenario, you still need to modify the corresponding code in switch.

Using Map, the code is configured

Define a map that stores the corresponding states and operations for the corresponding states

const statusMap = new Map([
  [0, doStatusZero],
  [1, doStatusOne],
  [2, doStatusThree] ]); Statusmap.get (status)();Copy the code

If possible, you can separate the configuration file to form a configuration file. If a new status changes, you only need to change the configuration file.

Matches the corresponding rule

The advantage of using maps is that code feasibility and neatness go up a notch, but only for a single judgment rule. What if you have multiple judgments? If (status === 0 && done === true && success == true), then simple map configuration is not possible.

If /else logic is essentially a state match, and the way to turn it into a computer is pattern matching. A single pattern is not enough, so create a multiple pattern match.

Scenario: Determine the three status: Status, done, and Success

Multivariate state matching requires two steps

  • Check whether the status matches
  • Match to complete the action to complete

Based on the above two behaviors, we abstract the map as follows

const judgeMap = new Map([
  [
    (status, done, success) => status === 0 && done === 1 && success === 1,
    () => {
      // do something
    }
  ],
  [
    (status, done, success) => status === 1 && done === 1 && success === 1,
    () => {
      // do something
    }
  ]
]);

for (let [rule, action] of judgeMap) {
  rule(status, done, success) && action()
}
Copy the code

conclusion

In fact, the whole idea comes from table driven method, which uses table data to store corresponding state processing. The concept of a table is not limited to a simple map, but can also be an array or object or even a string. The structure of a table can be defined by itself.

Common examples

What day is it today?

'Today is Monday${' day 1, 2, 3, 4, 5 '. CharAt ((new Date()).getDay())}`
Copy the code

The above example shows that a table is a string

The resources

Table driven data driven programming