What is React.js?

For a long time, I worked very hard to understand what React was and how robust it was in the application architecture. This article answers the doubts I want others to answer for me.

What is React?

How does React behave compared to angular,ember,backbone and so on? How do you work with data? How do I connect to the server? What the hell is JSX? How is "component" defined?

Stop.

Stop right now.

React is just the VIEW layer.

React is often mentioned at the same time as other JavaScript frameworks, but saying "React contrast Angular" does not work because they are not comparable. Angular is a complete framework (including a view layer), but React is not. This is also why React is difficult to understand, although it is drawn from an ecosystem with a complete framework, but only a view layer.

React provides template syntax as well as some function hooks for basic HTML rendering. This is the React all output--html. You put html/javascript together, called "components," that allow you to put their own internal state into memory (for example, which one is selected in a tab), but in the end you just spit out the HTML.

Obviously, you can't use React alone to create a fully functional dynamic application. Let's look at the details below.

Benefits

After using React for a period of time, I found three very important features.

1. By looking at a source file, you can see how your component will be rendered.

This is the biggest benefit, although this is no different from the Angular template. Let's look at a real application example.

Suppose you need to update the user name of the site header after the user logs on. If you're not using the JavaScript MVC framework, you might want to do this:

 <div class = "name" ></div>   

$.post(‘/login‘, credentials, function( user ) { // Modify the DOM here $(‘header .name‘).show().text( user.name );});

In my experience, this code will ruin your life and even the lives of your coworkers. How to debug output? Who's going to update the head? Who can also access the HTML of the header? Who will maintain the display hidden state of the name? This DOM operation will make your project as bad as a GOTO statement.

In React you can do something like this:

 render: function  () {return <header > {this. State. Name <div>this. State. Name</div> : null } </header>;}      

We will clearly discern how this component might be rendered. If you know this statement, you will know the output after rendering. You don't need to record the process of the program. It is particularly important in complex applications, especially in team development.

2. Binding JavaScript and HTML to JSX to make components easier to understand

The sort of combination of HTML and JavaScript may be very uncomfortable for you. It's natural for us to refuse to put JavaScript in the DOM (like the OnClick event handler) Even though we're small developers. But be sure to trust me; the JSX component really makes your job "nice".

Traditionally, you would detach the view (HTML) from the functionality (JavaScript). This produces a huge JavaScript file that contains all the functional requirements of a "page", and you have to document complex processes, from JS to HTML to JS to grief.

Bundled functions are directly tagged and packaged into a portable, self-contained "component" that makes you happier and less messy code. Because JavaScript is closely related to HTML, it is normal to rub together.

3. You can render React on the server

If you are creating a portal or app, and follow the render-it-all-on-the-client route, you may have made a mistake. Only client-side rendering makes Soundcloud feel so slow, whereas Stack Overflow (pure server rendering) is so fast. You can render React on the server, and you should do so.

Angular you to do something disgusting, such as using PHANTOMJS to render the page, analyzing the user agent in the request header, making these pages available to the search engine, or buying a service for this. Uh.

Harm

Don't forget that React is just a view layer.

1. None of the following:

• Event System (except for native DOM events)
• AJAX Features
• Data layer
• Promises
• Application Architecture
• Specifications for implementing the above functions

The React alone is really useless in this world. What's worse, as we're going to see, this forces every developer to reinvent the wheel.

2. Official documentation is neither "easy to understand" nor "good". Again, it's a blog post for idiots. See the first section of the document page sidebar:

There are three independent, conflicting quick start guides. I was a little overwhelmed, and I didn't drink much. The lower sidebar is like a nightmare, and it is clear that some chapters should not be placed there, like "more about Refs" and "Purerendermixin".

3. React is too big for the benefits that React offers you. And there's limited support for browsers.

Update: I wrote earlier that the React size is less than 144KB. Compressed via gzip after transmission at around 35KB.

This does not contain any React plugins, and you need to use those plugins to implement a real app!

Also does not contain ES5 Shim's class library, you need to support IE8 words.

Does not contain any type of application class library!

The size of the React is comparable to that of Angular, but Angular is a complete application framework. React is obviously bloated, but you only get a few features. I hope this will be improved in the future.

Don't say Flux.

Perhaps React development, the most offensive is the "Flux." Far more chaotic than React itself. The name "Flux" is a very confusing one.

Flux is not really there. It's just a concept, not a class library. Fortunately, there is a class library, in a way:

"Flux is more like a pattern than a frame. ”

Uh. One of the most inappropriate names: React has not reshaped the knowledge of the UI system for the last 40 years, nor has it brought new concepts to data management.

The concept of Flux is simple, the view layer triggers an event (for example, the user enters a name in the text field), the event updates the model, and then the model triggers an event that the view responds to the model's event and renders with the latest data. That's it.

This data flow/decoupling observer pattern is designed to ensure that your resources are always present in memory/mode. This is a good Thing ™.

The downside of Flux is that everyone will reinvent the wheel. Because there is no agreement in the event library, model layer, AJAX layer, etc., there are many kinds of "Flux" implementations, and they are mixed with each other.

Should I use React?

Simple answer: Yes.

Exhaustive answer: Unfortunately, yes, in most scenarios.

Here's why to use React:

• It's a great performance for team development.
• Enhanced readability and maintainability of UI code and workflow pattern UI.
• The modular UI is a trend in web development, and you should start now.

Here's why you need to think about it before you choose:

• At first React will greatly slow down your development. Understanding how props, State, and component communication works is not easy, and the document information is complex. Theoretically, this will be overcome, and your entire team will have a big boost in the speed of development.
• React does not support any browser below IE8, and never will.
• If your app/site doesn't require frequent dynamic page updates, you may be writing a lot of code for small functions.
  
• You're going to change a lot of wheels. React is very young, and because there is no authoritative way to handle events, component communication, you must create a large number of component libraries from scratch. Does your app have drop-down menus, resizable windows, or Lightbox? You must also write these from scratch.

That's it!

Next post, Flux fool tutorial

I hope it helps people like me to understand React better. If this article makes life easier for you, you can follow me on Twitter.

Original: Reactjs for Stupid people

What is React.js?