Hi, everybody. I’m the wave counter kill.

Tonight, my friends and I watched a big live broadcast on the Nuggets.

I don’t know. I enjoy the atmosphere. Watching the same thing with a group of like-minded friends, and then expressing their own opinions and opinions, this feeling is very different from watching a live stream of bullets.

When I entered the studio, the live broadcast had already started for more than ten minutes. React-hooks: mental overhead, closure traps, useEffect dependencies, etc.

But I have a different opinion about these jokes. Closure traps are caused by the fact that closures are not well understood and therefore cannot be sensed when certain closures are being generated using partial hooks. In fact, the logic for closure traps, if true, does not only exist in React hooks, but in all possible scenarios in JavaScript. This is especially true for weakly aware scenarios like anonymous functions.

The useEffect dependency problem is not a drawback of hooks in my opinion, but a benefit of hooks. I devoted this feature to the React Philosophy, the most important chapter in my new book React Knows How. UseEffect dependencies help us listen to single data to drive multiple data, so we can use this feature to accomplish single-data-driven multi-data, multi-data-driven UI switching thinking. It can greatly simplify our development and improve development efficiency.

Switch thinking is my own development concept. It refers to the design concept of one data state driving multiple data states, and multiple data states driving the UI.

useEffect(() => { if (refreshing) { http.get(api).then(res => { setList(res.data) setRefreshing(false) }) } }, [refreshing]) // The useEffect callback must be executed if there is a refreshing change.Copy the code
// When used, you can use very concise code to implement complex interactive logic
function App() {
  const {refreshing, incresing, list, setRefreshing, setIncresing} = usePagination(api)

  return (
    <PaginationList 
      list={list}
      refreshing={refreshing}
      incresing={incresing}
      onRefresh={()= > setRefreshing(true)}
      onIncrese={() => setIncresing(true)}
    />)}Copy the code

Uvu introduced the advantages of the Options API and Composition API.

Vue3 combined with TS

The second question is about the incomplete combination of VUE3 and TS. The main problem is the way props is defined versus generic components.

It can only be said that the friends who ask questions are really sharp and belong to the model of which pot is not mentioned. This question, answered sideways by The University of Utah, also recognizes the existence of the problem. In fact, there is a very good discussion on this issue in Zhihu. You can go here to learn more about it.

www.zhihu.com/question/45…

Vue 3 across

Many friends are expecting Vue3 to provide some officially supported cross-end solutions for stable maintenance. Unfortunately for you, UVU made it very clear that the Vue team doesn’t have the energy to do these things, and only the corporate size is capable of doing them, because cross-side support is really complex.

However, at this time, you have stepped on uniapp, so the selection of technology ready to use may be a little careful, there are also friends in the group to ridicule the pit of Uniapp, such as CSS only support class selector and so on.

In addition, UVU introduced a very powerful feature of Vue: Vue3 directly exposes a set of interfaces for custom renderers, which can theoretically access any rendering target, such as a team member who is accessing a cool command line UI.

How to join an open source project

A few big guys talk a lot about open source. Moon shadow believes that the complexity of open source projects is no less than operating a company. Guo Hui believes that engaging in open source requires enthusiasm, and the original intention is simple, because there may be no return, and even the obligation to solve many issues. Plus many users aren’t that friendly.

For His part, he is more concerned that if you consistently contribute good code to a project, you have a good chance of joining the open source team.

Uhsu subtext: Let’s all work for Vue, haha.

Vue -> canvas

It’s actually a very interesting problem, and it’s theoretically possible. But this direction is a bit like a cross-end direction, and JUDAH thinks that the browser takes a lot of effort to implement these capabilities, which means that Vue probably doesn’t think about it.

We can also think about the complexity of this implementation. For example, if we need to have a VUE component structure, we need to have a style standard, then we need to implement a component parser and a style parser in addition, we need to combine the results of the two parses into something like render Tree and render it to the canvas. This process is indeed quite complex, and is also a set of parsing and rendering mechanisms implemented by the underlying principles of the browser.

State management VEX5

Unfortunately Utah didn’t introduce the features of VEX5, just the background. I’m not a heavy user of Vue, so I didn’t hear anything particularly useful.

Disadvantages of VUE3, new changes of VUe4

For this, Utah clearly stated that the TS aspect needs to be improved, including generics and slots.

In addition, VUE3 is too new to be maintainable for large projects, which makes it a little clunky for especially lightweight embedded scenarios. Therefore, a very small petite-Vue, only about 6KB, will be produced to solve the application of this scenario.

Most importantly, Utah has made it clear that Vue will use solid’s build model. For those of you who know Solid, that would be a huge performance leap.

Solid is a framework that does away with the virtual DOM in favor of a compiled approach, which, among other things, beats current Vue and React. So if Vue does follow this pattern, the performance is very much to be expected.

Moonshadow: A new trend in front-end technology

When talking about the new trends in front-end technology, moonshadow made a lot of history, probably describing and feeling web1.0 and web2.0. For example, the read-only nature of Web 1.0, and the strong interaction of Web 2.0, I think they all hit the spot. I thought that spending so much time talking about past lives must be a preview of web 3.0, but I waited.

It turned out he was just talking about the fact that Internet speeds were getting faster and front-end projects were getting heavier. He also expressed the core philosophy that technology is unpredictable, but changes are always the same.

Fair enough, but somewhat disappointing.

Guo Hui: Low code, no code

To tell the truth, many people are concerned about low code, and even some anxious players are worried about whether the low code will affect the job of front-end programmers. Miss Guo dispelled our concerns with her simple and clear expression.

He says there are a lot of teams that are experimenting with low code, and there are even financial companies that “I suspect he’s talking about Kingdee” that are very mature with low code, but most of them are not very good at it. The main reason is that the business logic of many scenarios is complex, not general, and cannot be abstracted. As a result, low code implementation became the vision.

A lot of teams are working on the component rendering layer, but in reality these are relatively simple and not the core pain points of the project. In other words, Guo felt they were going in the wrong direction.

Low code is only suitable for scenarios where logical abstractions are simple and generic. Take invoices. Business logic abstraction is easier. The business logic of the toB is unsolvable.

No code, low code, many years ago, there were other similar conceptual scenarios and applications in other languages. Guo also put forward a very useful concept: we should properly jump out of the front circle. Don’t even limit yourself to tech circles.

I couldn’t agree more.

Utah: A view of new front-end technologies

The view of low code is different at home and abroad. Most of the domestic low code are some big factories, in order to performance what “ha ha ha, vague kicked a, understand all understand”

In foreign countries, more small factories are doing these.

But Judah made a point that I quite agree with: different stages should focus on different things. For example, when starting out on the front end, there is less need to focus on low code. We should pay more attention to the improvement of our own ability.

In fact, The University of Utah provides us with a very good prospect in the field of new technology. That’s the change in front-end engineering. As projects become more complex, faster development performance becomes our goal. He gave some examples.

Use Rust to rewrite postCSS to quickly process CSS AST transformations. This scenario is written in the native language, and the payback ratio is relatively certain.

In addition, there is the familiar Esbuild, written in the GO language. The engineering shift has slowly infiltrated our project developers.

This is actually a big challenge and opportunity for advanced front-end engineering.

In addition to engineering, UVU also provided some decision-making thoughts on the original biochemistry scenarios, including business logic, iteration speed, flexibility, stability, performance and other aspects, to discuss whether the corresponding scenes of “image processing, front-end framework” are suitable for the original biochemistry.

For example, is protobiochemistry appropriate at the framework level: some calculations are faster, but the cost of communicating with the DOM is higher. Implementation costs are also higher. So write a module in native language and get a definite performance boost. All in WebAssembly is unrealistic without JavaScript.

The future of programmers

The University of Utah didn’t offer any useful advice on the subject.

He also directly expressed the limited reference value of personal experience. Finding the opportunity to do an open source project with a large audience, for example, is an accident. Ability is a prerequisite, but luck is a big part of it.

He considered himself one of the luckier ones. When I did VUE, the front end happened to be in a slash-and-burn era.

And some suggestions, if we want to make a product to sell to some teams, we should pay more attention to the overseas market.

Overall, there are some gains, but the biggest gain is that several groups of people in the group at the same time laughing at the joy of these tycoons. Ha ha.

I am this wave of anti-kill, watch me unlock more front-end skills!