Blast Command, don't let a UI framework ruin you

ruin your vision

These UI frameworks are like high walls, putting you under house arrest in their warm ecosystem. After a long time, you will forget that there is a vast world outside. Treat the UI layer as the entirety of the software, and everything else becomes an accessory.
There is no need for state management, no MVC, no need for hierarchical governance, no cohesive decoupling, and no architectural thinking. Everything is Component and Hooks.

ruin your technology

With React/Vue, the native Dom operation has been forgotten, and the browser rendering principle is too lazy to learn. No one knows about the classic works such as JQ and RX, and the design pattern seems to be gone.
Your technology stack is the surrounding ecology of the UI framework, and you don't know how to write front-end pages without React/Vue...

Ruined your state management

With Hooks/Composition API no need for separate state management? Purely technically, it may be possible, but have you ever thought that Hooks/Composition API are the products of a specific UI framework, and are deeply coupled with the rendering and life cycle of the UI framework.
In the JS realm they are like dialects, plus some obscure mental burden, far from a Flux framework is simple and clear.
Moreover, how easy it is to test, monitor, and roll back an "Action", you test, monitor, and roll back a "Hooks" to try...
Of course, it's not that Hooks are bad and can't be used. Hooks belong to the UI's own magic method, of course it is handy to let it handle its own affairs, and other non-UI responsibilities, although it can be done, it is not suitable. If you can speak Mandarin, why do you use dialects?

ruin your project

Brothers, open your Component code to see if it is full of various life cycles, various data definitions, various interaction logic, various business logic, various Ajax requests, various routing jumps, various Cookies/LocationStorage Operation and so on, easily hundreds of lines of code...
Don't say that with Hooks/Composition API, it can be disassembled and clear. No, it can be reused at a smaller granularity, but it may become more unintuitive.
Some simple data exchanges need to be passed around by Props. Even if I don’t need it, I have to pass it on to my children and grandchildren. I also need to consider whether the transmission and reception are synchronous or asynchronous, and whether there will be closure traps. Will not cause redundant rendering... a good straight path, which is biased by the rendering mechanism of the UI framework.
Pull the UI framework off the altar
The UI layer is not the whole of the software architecture, not even the core. There are only two accusations of UI: input and output, that's all.
It is the collector of instructions and the feedbacker of results, not the executor of instructions.
The core of the application is the business logic
What is the core of that application? It is business logic, not UI interaction logic.
The existence of the UI is only to make the user more friendly to use the system, just like Dos and Linux systems cannot be used without installing the UI?
So now I ask you a question:

If your app doesn't use the UI, can the user use it via commands?

You might argue with me that no user commands to use my app, which is a pointless assumption. However, this scenario may not be open to users, but to partners, testing tools, and log analysis?
Don't rely too much on the UI layer

UI said: The application needs to be revised, and the skin, interaction, and page organization must be adjusted. How long will it take?
The product said: How long will it take to change H5 and make it into a small program or APP?
The manager said: React people are too difficult to recruit, or let's switch to Vue, how long will it take?
Leader said: Vue3 is out, let's upgrade to the latest version, how long will it take?

The business logic remains the same, just adjust the UI and its operating platform, how long will it take you? One week? a month? a year? still...
If your answer is reluctant, it means that you have over-relyed on the UI layer...
Homogeneous UI framework
Take UI frameworks too seriously? Still struggling to use "React" or "Vue"? Tangled "Ajax request" should put "onCreate()" or "onMount()"? Thinking about how to optimize rendering performance every day? When encountering dissidents, you always have to argue which is better?
How different is VUE3+JSX and React?
software architecture revisited
Thin the UI layer, it's nothing more than rendering data (output) and collecting actions (input).
Let the Controller and Model layers return, they are the C-bit of the architecture and the brain of the application.
Re-examination of layered governance and MVC, so that "objective and stable" business logic is not interfered by "emotional and changeable" UI logic, and ensures that core logic can run across UI frameworks and operating platforms.
Reinvigorating the Flux framework
How does MVC land? The famous Flux architecture is a landing solution for Controller and Model.
Redux/Vuex/Pinia, and Elux, which has been recommended for everyone to use later, can be regarded as its variants.
From State to Model
MVVM applications are full of states, some of which are used to describe the internal state of Component. It is closely related to Component, and follows the birth and destruction of Component. This is what we often call ComponentState.
There are also some states, which are used to describe the business state, which are not directly related to the specific Component, and there is no reuse and destruction. We can call it Model.

ComponentState is UI logic, which should be encapsulated in Component, and the outside world does not need to know.
Model is business logic, reflecting the status of the entire APP, independent of Component, and should be managed by the Flux framework.

From Event to Action
Human-computer interaction events generated by users through the UI interface, we are used to calling them "Event events", and the business purpose behind "Event events" can be called "Action actions".

The Handler that handles the Event is UI logic and should be written in the UI component
The Handler that handles Action is business logic and should be written in the Controller

Let's take a specific example: "SubmitLoginForm|Submit the login form", usually the following logic should be completed:

Verify that the input is valid
Verify that the current user is logged in
Request backend API and wait for return
If successful, save the user information and jump back to the original page
If it fails, prompt an error and stay put

This is a business action, because it can run independently of any specific UI. It may be triggered by the user clicking the login button through the "onClick event", or it may be triggered by pressing the enter key through the "onKeyPress", or even you can directly let the user Triggered by "Login command".
So "onSubmitLoginForm()" should be written in Controller instead of UI component.
There are only "onLoginButtonClick()" or "onEnterKeyPress()" in UI components, and they are often just one sentence, that is, Dispatch an Action to trigger "onSubmitLoginForm()" in Controller
Move the business logic out of the UI components, so that the UI layer becomes thinner and returns to its essence: only responsible for collecting business actions, not responsible for processing it.

Improved Flux framework
The traditional Flux framework also has pain points:

Global centralized management leads to too centralized logic;
Single instance and no destruction can easily cause information accumulation and explosion;
The DispatchAction mechanism is too simple and is not suitable for dealing with long-term business processes.

The Elux framework that I want to recommend to you here is improved for the above pain points:

Although it insists on global centralized management, Elux proposes the concept of "micro-module", which splits the application layer into independent and autonomous "micro-modules", each micro-module only handles things in its own domain.
No longer a single instance, each route change will generate a new blank Store, and then re-select useful state mounts, similar to a garbage collection mechanism.
The concept of ActionBus is proposed, and Action is broadcast as an event in the Model.
Let the Action processing chain have a "coroutine" mechanism to better coordinate the association between various business actions.

It is precisely because it follows the design idea of ​​light UI and heavy model that Elux can cross-framework and can be developed with React/Vue/more other UI frameworks. It is not necessary to learn NextJS for React, and NuxtJS for Vue, UI framework. has become less important.
Formally, because of the separation of UI logic and business logic, Elux projects can be cross-platform, and can develop Web (browser), Micro (micro front-end), SSR (server rendering), MP (small program), APP ( mobile application).
Sincerely! Welcome to communicate:

Throwing bricks and attracting jade
6-20 update added:
Another very important point: UI is too emotional, too flexible, with a strong personal subjective color, often optimized, modified, or even overturned, not as stable as business logic. This is also an important reason to separate UI logic and business logic. If you write business logic and UI logic together, your originally stable code will be seriously disturbed by unstable code.
In addition, some people say that this is pushing the framework, but it is not. The most important thing in programming is the idea, followed by a specific framework. The core idea emphasized in the article is not to put all the logic in the UI layer, but to let the UI layer return to its essence. As for what MVC framework you use, it's just a means. To be honest, I'm not very satisfied with Redux/Mobx/Vuex/Pinia, so I made another wheel. If you find a useful layered framework, you can recommend and share it. ..

Related Articles

Explore More Special Offers

  1. Short Message Service(SMS) & Mail Service

    50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00