Unlock Front-End Power with Open-Closed, Functional Programming, and Messaging

Preface

In the classic novel "The Smiling, Proud Wanderer", the sword‑master’s hidden technique is likened to a swift wind that cannot be concealed; without inner power, even the finest swordplay is futile.

Just as a sword without internal energy is ineffective, modern front‑end technology stacks resemble a bustling martial‑arts world where each framework—React, Vue, Angular, jQuery—forms its own school, while newer contenders like Flux, Redux, MobX, Weex, and GraphQL vie for dominance.

Front‑end engineers often feel overwhelmed by the rapid release of new versions and frameworks, but each tool is simply a means to solve business requirements, much like different martial‑arts styles each have their strengths.

Beyond learning how to use a technology, we must grasp the underlying design philosophy and engineering mindset, which serve as the "inner skill" that powers any implementation.

We will discuss three engineering ideas—Open‑Closed Principle, Functional Programming, and Message Mechanism—showing how they appear in back‑end development and are also widely used in front‑end frameworks.

Open‑Closed Principle

In object‑oriented design, the SOLID principles are foundational, with the Open‑Closed Principle stating that software should be open for extension but closed for modification.

Single Responsibility Principle

Open‑Closed Principle

Liskov Substitution Principle

Dependency Inversion Principle

Interface Segregation Principle

The goal of SOLID is high cohesion and low coupling; the Dependency Inversion Principle is most common in back‑end design, as illustrated below.

This diagram shows the evolution from abstract concepts to concrete practice.

In front‑end frameworks, the Open‑Closed Principle is applied most frequently. The principle is defined as:

A software artifact should be open for extension but closed for modification.

In practice, this means the core logic of a system should remain stable while new functionality is added via extensions.

public abstract class Shape {
    public abstract double Area();
}

public class Rectangle : Shape {
    public double Width { get; set; }
    public double Height { get; set; }
    public override double Area() {
        return Width * Height;
    }
}

public class Circle : Shape {
    public double Radius { get; set; }
    public override double Area() {
        return Radius * Radius * PI;
    }
}

public double Area(Shape[] shapes) {
    double area = 0;
    foreach (var shape in shapes) {
        area += shape.Area();
    }
    return area;
}

Regardless of how shapes are extended, the Area method never needs to change; each shape implements its own calculation.

In Ant Design, the Form component embodies this principle. It provides a standard container for validation and submission while allowing custom form items to plug in without altering the core logic.

<FormItem>
  {getFieldDecorator('userName', {
    rules: [{ required: true, message: 'Please input your username!' }],
  })(
    <Input prefix={<Icon type="user" style={{color: 'rgba(0,0,0,.25)'}} />} placeholder="Username" />
  )}
</FormItem>

Custom components must follow three conventions: provide a controlled value prop, expose an onChange (or equivalent) event, and be class‑based rather than functional.

Provide a controlled value (or the prop named by valuePropName ). Provide an onChange (or the event named by trigger ). Must not be a functional component.

This demonstrates the Open‑Closed Principle: the Form’s core logic stays unchanged while custom fields integrate seamlessly.

Functional Programming

With emerging business scenarios like AI, blockchain, AR/VR, and new retail, front‑end development faces increasing complexity. Functional Programming (FP) offers high reusability, testability, and robustness, and many modern frameworks adopt FP as a core design tenet.

Functions are first‑class citizens

Modular composition

Referential transparency

Avoid state mutation

Avoid shared state

JavaScript functions can be passed as arguments and return values, naturally supporting first‑class status.

Find the first four non‑digit characters in a string

Non‑FP style

var words = [], count = 0;
var text = str.split('');
for (var i = 0; count < 4 && i < text.length; i++) {
  if (!text[i].match(/[0-9]/)) {
    words = words.concat(text[i]);
    count++;
  }
}

FP style

var words = str.split('').filter(function(x) {
  return (!x.match(/[1-9]+/))
}).slice(0, 4);

The FP version uses filter and slice, eliminating explicit loops and making the code more concise.

Implement sum, product, and bitwise AND for an array

Non‑FP style

function plus(array) {
  var res = array[0];
  for (let i = 1; i < array.length; i++) {
    res += array[i];
  }
}

function mul(array) {
  var res = array[0];
  for (let i = 1; i < array.length; i++) {
    res *= array[i];
  }
}

function and(array) {
  var res = array[0];
  for (let i = 1; i < array.length; i++) {
    res = res & array[i];
  }
}

FP style

var ops = {
  "plus": (x, y) => x + y,
  "mul": (x, y) => x * y,
  "and": (x, y) => x & y
}

function operation(op, array) {
  return array.slice(1).reduce(ops[op], array[0]);
}

Using reduce abstracts the calculation, allowing new operations to be added simply by extending the ops object.

FP thinking in React

React updates the UI by diffing a virtual DOM generated from data. The process can be expressed as:

UI = React(data)

Thus, React is essentially a pure function whose output depends only on its input data, satisfying referential transparency.

Components are composed of smaller components, each focusing on its own inputs. Higher‑order components exemplify function composition.

However, overly fine‑grained component decomposition can increase file count and communication overhead, a trade‑off often discussed in FP circles.

Message Mechanism

Message mechanisms enable decoupled communication between modules, as seen in observer patterns, OS kernels, Spring’s ApplicationListener, and Objective‑C method calls.

Without messaging, modules must directly invoke each other, creating tight coupling.

Introducing a message bus decouples modules: each component sends and receives messages via a central processor, unaware of other components’ existence.

In front‑end development, libraries like EventEmitter provide similar capabilities, allowing React and D3 sections to stay synchronized.

Middleware can be attached to the message flow to handle cross‑cutting concerns, keeping business code concise.

Redux exemplifies this pattern: actions are dispatched, reducers and middleware process them, and the UI updates accordingly.

Discussions about Redux’s pros and cons are extensive; this article does not repeat them.

Summary

The Open‑Closed Principle, Functional Programming, and Message Mechanism are three core "inner‑skill" concepts; mastering them deepens understanding of front‑end frameworks and unlocks their full potential.

In Jin Yong’s "Demi‑Gods and Semi‑Devils", the hero’s punch combines softness and strength, embodying the perfect balance sought by martial artists—just as well‑designed software balances flexibility and stability.

References

Functional Programming in JavaScript — Dan Mantyla

Functional JavaScript: Introducing Functional Programming with Underscore.js — Michael Fogus

Clean Architecture — Robert C. Martin

https://reactjs.org

https://ant-design.gitee.io/d...

https://redux.js.org/

https://redux-saga.js.org/

《笑傲江湖》— 金庸

《天龙八部》— 金庸

Original source: https://www.yuque.com/es2049/blog