Bombard the headquarters. Don't let a UI framework destroy you

Since React/Vue After the fire , Whether it's a topic or a recruitment , They are everywhere , It seems that as long as you master them, that is the advanced front-end . Here I want to bombard the headquarters ：UI The frame is not Jesus 、 Not the Savior , Relying too much on them will ruin you ...

Destroy your vision

these UI The frames are like high walls , Put you under house arrest in their warm ecosystem , For a long time, you have forgotten that there is a vast world outside . hold UI Layer as the whole of software , Everything else has become an accessory .

No need for state management 、 Unwanted MVC, No layering is required 、 Not oriented to cohesion and decoupling 、 Don't think about architecture , Everything is Component、Hooks.

Destroy your skills

Ever since React/Vue, Native Dom The operation is forgotten , Browser rendering principle is too lazy to learn ,JQ、RX No one knows about the classics , Design patterns don't seem to work anymore .

Your technology stack is UI The surrounding ecology of the framework , Leave React/Vue I don't know how to write the front page ...

Ruin your state management

With Hooks/CompositionAPI There is no need for separate state management ？ Technically speaking, it may be possible , But have you thought about it Hooks/CompositionAPI Are specific UI The product of the framework , And UI Rendering of frames 、 Life cycle deep coupling . stay JS They are like dialects in the country , Plus some obscure mental burdens , Far from one Flux The framework is simple and clear .

and , test 、 monitor 、 Roll back one “Action” How easy , You test 、 monitor 、 Roll back one “Hooks” try ...

Of course not Hooks It's not good , It's not working .Hooks Belong to UI Own magic method , It's easy for him to handle his own affairs , Others are not UI Responsibilities , Although it can also do , But it's not appropriate . The art has a specialty , If you can speak Mandarin, why should you use dialect ？

Ruin your project

Brothers, open your Component Look at the code , Is it filled with various life cycles 、 Various data definitions 、 Various interaction logic 、 Various business logic 、 Various Ajax request 、 Various route jumps 、 Various Cookies/LocationStorage Operation and so on , A few hundred lines of code are easy ...

Don't say you have Hooks/CompositionAPI It can be disassembled 、 It's clear ,No, But it can be reused with smaller granularity , But it may become less intuitive .

Some simple data exchange , Need to be Props Come and go , Even if I don't need , Also for my children and grandchildren , Also consider whether the delivery and reception are synchronous or asynchronous 、 Will there be a closure trap , Will it cause redundant rendering ... A good straight road , By UI The rendering mechanism of the framework is biased .

take UI The frame pulls down the altar

UI Layer is not the whole of software architecture , Not even the core ,UI The only accusations are 2 individual ：

Input and output

, That's it .

It is the collector of instructions and the feedback of results , It should not be the executor of the instruction .

The core of application is business logic

What is the core of the application ？ It's business logic , Instead of UI Interactive logic .

UI The existence of is just to make users more friendly to use the system , It's like Dos、Linux System not installed UI Can't you use it ？

Now let me ask you a question ：

If your app doesn't use UI, Can users use the command ？

You might say to me , No user will use my application through commands , This is a meaningless assumption . However , This scenario may not be open to users , It's for partners 、 Leave it to the test tool 、 For log analysis ？

Don't over rely UI layer

• UI say ： The application needs to be revised , The skin 、 Interaction 、 Page organization should be adjusted , How long will it take? ？

• The product says ： hold H5 change , Make a little program 、APP Well , How long will it take? ？

• The manager said ：React People are too difficult to recruit , Why don't we change to Vue Well , How long will it take? ？

• Leader say ：Vue3 Come out , Let's upgrade to the latest version , How long will it take? ？

Business logic remains unchanged , Adjust only UI And its operating platform , How long will it take you ？ A week ？ A month ？ A year ？ still ...

If your answer is reluctant , That means you've become overly dependent on UI The layer ...

Homogeneous UI frame

hold UI The frame is too heavy ？ Still struggling to use “React” Good or not “Vue” good ？ tangle “Ajax request ” Yes “onCreate()” still “onMount()”？ Think about how to optimize rendering performance every day ？ When you meet a different person, you always have to argue about which is better B？

Try to ask  VUE3+JSX  And  React  And how much difference ？

Revisit the software architecture

hold UI The layer becomes thinner , It's just rendering data （ Output ） And collect actions （ Input ）.

Give Way Controller、Model Hierarchical regression , They are the architecture C position , Applied brain .

Re mention and treat by layers 、 Hark back to the MVC, Give Way “ objective 、 Stable ” The business logic of is not “ perceptual 、 Changeable ” Of UI Logical interference , Ensure that the core logic can span UI frame 、 Run across operating platforms .

Reinvigorate Flux frame

MVC How to land ？ big-name Flux Architecture is a kind of  Controller  and  Model  Landing plan of .

Redux

/

Vuex

/

Pinia

、 It has been and will be recommended for everyone to use

Elux

, Can be regarded as a variant of it .

from State To Model

MVVM Applications are full of States , Some are used to describe Component The internal condition of , It is associated with Component be closely related and mutually dependent , Follow Component Birth and destruction , This is what we often say

ComponentState

.

There are also some states , Used to describe business status , Which one is it Component Not directly related , There is no reuse and destruction , We can call it

Model

.

• ComponentState  yes UI Logic , Should be encapsulated in Component Inside , The outside world doesn't need to know .

• Model  It's business logic , Reflect the whole APP The state of , And Component irrelevant , It should be done by Flux Framework for unified management .

from Event To Action

User pass UI Human computer interaction events generated by the interface , We are used to calling "Event event ", and "Event event " The business purpose behind it can be called "Action action ", They are one cause and the other effect , One is a table, the other is a book .

• Handle  Event  Of  Handler  yes UI Logic , It should be written in UI In the component

• Handle  Action  Of  Handler  It's business logic , It should be written in Controller Inside

Take a specific example ："SubmitLoginForm｜ Submit the login form ", The following logic is usually completed ：

• Verify that the input is valid

• Verify that the current user is logged in

• Request backend API, And wait to return

• If it works , Save user information , And jump back to the original page

• If you fail , Prompt error , And stay where you are

This is a business action , Because it can not depend on which specific UI And running , The user may go through “onClick event ” Click the login button to trigger , Or maybe through “onKeyPress” Press enter to trigger , You can even directly let users through “Login command ” To trigger .

therefore “onSubmitLoginForm()” It should be written in

Controller

Instead of UI In the component .

UI There are only "onLoginButtonClick()" or "onEnterKeyPress()", And they often just say , Namely Dispatch One Action To trigger

Controller

Medium “onSubmitLoginForm()”

Move the business logic out of UI Components , such UI The layer becomes thinner , Back to its essence ：

Only collect business actions , Not responsible for handling it

.

improvement Flux frame

Conventional Flux The frame also has pain points ：

• Global centralized management leads to over centralized logic ;

• Single instance 、 It is easy to cause information accumulation and explosion if not destroyed ;

• DispatchAction The mechanism is too simple , It is not suitable for long process business dealing with cause and effect .

Here I would like to introduce myself to you  

Elux frame

, The above pain points have been improved ：

• Although we insist on overall centralized management , but Elux Put forward “ Micro module ” The concept of , The split layer will be applied independently and autonomously “ Micro module ”, Each micro module only deals with things in its own domain .

• No more single instances , Each route change creates a new blank Store, Then re select the useful state to mount , Similar to a garbage collection mechanism .

• Put forward ActionBus The concept of , Give Way Action As Model To broadcast .

• Give Way Action The processing chain of has “ coroutines ” Mechanism , Better coordinate the association between business actions .

Model driven

It is because of the following

light UI、 heavy Model

Design idea , Give Way Elux It can span the framework , have access to

React/Vue/ More others UI frame

To develop , You don't have to do it for React And learning

NextJS

, in order to Vue Learn again

NuxtJS

,UI Frameworks have become less important .

Officially because of separation

UI Logic and business logic

, Give Way Elux Projects can cross platforms , It can be developed in an engineering mode Web( browser )、Micro( Microfront )、SSR( Server render )、MP( Applet )、APP( Mobile phone application ).

advance ！ Welcome to exchange ：

https://eluxjs.com

throw away a brick in order to get a gem

There is also a very important point ：UI Too emotional 、 Too flexible. , With a strong personal subjective color , Often optimized 、 modify 、 Even overthrow , Not as stable as business logic . This is also to UI The important reason why logic and business logic are separated , If you combine business logic with UI Logic is written together , Your otherwise stable code will be severely damaged by unstable code .

in addition , Some people say that this is pushing the framework , It's really not , The most important thing in programming is thinking , The second is a specific framework . The core idea emphasized in the article is not to put all logic into UI In the layer , Must let UI Layers return to nature . As for what you use MVC frame , It's just a means , Tell the truth

Redux

/

Mobx

/

Vuex

/

Pinia

I'm not very satisfied , That's why we built another wheel , If you find a useful layered framework , Can recommend sharing ...