Developing high-performance responsive Web applications with inferno instead of react

What Is Inferno

Inferno can be seen as another streamlined, high-performance implementation of react. It is used in the same way as react, whether it is JSX syntax, component building, component life cycle, or with Redux or MOBX, routing control, etc., can be basically in accordance with the react way to develop, only a small difference. However, Inferno is designed specifically for Web pages, and cannot develop mobile-based local apps like react native.

Why do you use Inferno?

Since inferno and react are basically similar, and do not have the ability to develop native apps, why use Inferno? Simply because of performance.

First of all, Inferno itself is very small, only the react one-fifth, and it has a very obvious advantage in page performance. Inferno also uses the virtual DOM technology, but it is different from the react, and does not use the more popular open source Virtual-dom project, but its own complete development of a set of virtual DOM, its implementation is relatively light, efficient, better performance. As for how well the performance of Inferno, you can refer to the Inferno homepage (www.infernojs.org) on the running of the comparison.

Therefore, it is very advantageous to try inferno on some devices that attach great importance to performance, especially the mobile side. Although now the mobile phone replacement quickly, the configuration is more and more high, but the speed and network traffic constraints still require the download file smaller the better, and the phone memory and CPU is always a valuable resource, the page performance requirements are still higher than the PC.

In addition, Inferno has some minor improvements that make it easier to use than react, especially when building a pure function component in flux mode.

In short, Inferno is a great choice to enjoy an efficient, responsive development experience like react, and to get high performance close to native code.

What to consider when you want to use Inferno

But if you really want to move development from react or even other frameworks to inferno, there are some issues that need to be considered first.

1. Whether to rely on the Integrated UI component library

Now many web software, especially the development of industry software, is very dependent on an integrated UI component library. I even learned that some developers started learning react because they wanted to use ant Design. Vue is now so well developed that it is also associated with an increasingly rich library of components in its ecosystem. Inferno, after all, is a niche framework, and at least it is impossible to find a complete library of components for Inferno. Although a tool such as inferno-compact can be used to fit the react component into the inferno, since many of the components will use ref, the use of ref in two frames is different (as detailed below), Causing difficulties in referencing react components in Inferno. So if your project requires a lot of uniform, ready-made components, just give up inferno, and be honest with react or vue.

However, when your project needs to be highly customized, or it is relatively simple, you can consider using Inferno. I met a situation where the demand customization was too high to be met by Ant design. And a framework based on inferno to encapsulate components is actually a very pleasant thing to do. For very complex components, such as date selection, sliding, and so on, it is convenient to encapsulate libraries that do not rely on specific frameworks as Inferno components.

2. Requirements for browser compatibility

Inferno only supports modern browsers. If you have a very important target user is not IE9 the following browser is not available, it is better to use jquery, with Easyui. This is the development of a previous era.

3. Is there a plan for sharing code with web and native apps

One reason to choose to use react might be that react has a derivative that is react Native, which means that some large applications can allow mobile web and apps to share a set of code to save on development costs. But inferno can only be used for web development, which is why it has a lot of refinement and performance optimizations over react.

4. Do you have the patience to solve problems?

Although Inferno and react feel very much alike, there are still differences. When there is a problem, react random search has a bunch of results, and inferno can be used for reference only official documents (of course, English, there is no Chinese translation), currently even StackOverflow on Inferno questions and answers are few. Of course, there are also source code.

And Inferno is younger than react and does not have a Facebook luxury team like react to maintain, although it is basically stable, but there are still some small problems. But since he is an active open source software, the obvious bugs found in this release are usually fixed in subsequent releases.

For example, I've had a weird problem, a set of checkboxes that Inferno renders, and when the sequence changes, clicking on a checkbox will tick the other one. By tracing the source code to find Inferno in order to achieve optimal performance, when the virtual DOM changes, for the same position on the same tag name element is not re-rendered, but to the actual DOM on the original node re-assigned properties, but onchange this event property is specially processed, not native , the event handler is not changed when the property is reassigned, so it can be circumvented by not putting the checkbox's binding value in the closure and dropping it on the element, and the next version fixes the problem. Look at the previous version of the code to find this bug is very oolong, there is no prior to this problem, is the developer in the process of streamlining the event processing code to ignore the onchange of such processed event processing way. Who happened in this version has this bug, I caught up.

Doubts about the stability of this niche may be that many people do not dare to use it for the most important reason, in fact there are some companies in the foreign countries in the production of the use of Inferno, so do not worry too much.

Getting Started with Inferno

If you are already using react development, you will basically already be using Inferno. As for the construction of the Inferno project is basically the same as the react project, just to replace some dependent packages with inferno related. If there is a react project on hand, then please open the Package.json file to see which package name with react words, basically all "react" replaced by "Inferno" on it, The following columns list some dependent packages that can be replaced with Inferno:

• React→inferno
• React-component→inferno-component
• React-redux→inferno-redux
• React-mobx→inferno-mobx
• React-router→inferno-router

And some possible development dependency packages:

• Babel-plugin-react→babel-plugin-inferno
• Eslint-plugin-react→eslint-plugin-inferno
• React-devtools→inferno-devtools

For react-related package names that are not listed, you can verify on the npmjs.com if there is a corresponding inferno-related package.

If you want to use the JSX syntax, you need to Babel the JSX tag into a function that is accepted by Inferno, which is to add Babel to the BABELRC node in the plugins configuration file. Inferno, such as a simple, The full support for the inferno. babelrc file looks like this:

{  "presets": ["env", "stage-0"],  "plugins": ["inferno"]}

If you want to use Eslint, you also need to add the appropriate plugin in the Eslint configuration file. ESLINTRC:

{  "parser": "babel-eslint",  "plugins": [    "inferno"  ],  ...}

In short, according to the react configuration of the "react" are replaced by "Inferno" on the line.

Inferno and React Differences

Inferno Development and react the same, the key "small differences" to figure out, development is no obstacle.

Creating Elements and components

The inferno creation element can use the JSX syntax or the createelement function, which is the same as react, but the createelement function is not in the Inferno package. Instead, you need to introduce an additional inferno-create-element package.

In addition, Inferno provides an hyperscript way to create elements. It is used in a similar way to createelement, but the class name and ID can be written together with CSS syntax and tag names, and the div can be omitted, which is similar to Pug (formerly known as Jade). Another difference is that a child node is placed in an array.

The following is a list of the three Ways inferno create elements:

import Inferno from ‘inferno‘const demo =   <div id="example1" className="example-div">    Hello,    <a className="example-link" href="infernojs.org">      Inferno    </a>  </div>

import createElement from ‘inferno-create-element‘const demo = createElement(‘div‘, {  id: ‘example1‘,   className: ‘example-div‘},   ‘Hello, ‘,  createElement(‘a‘, {    className: ‘example-link‘,     href: ‘infernojs.org‘  },     ‘Inferno‘  ))

import h from ‘inferno-hyperscript‘const demo = h(‘#example1.example-div‘, [  ‘Hello, ‘,  h(‘a.example-link‘, {    href: ‘infernojs.org‘  }, [    ‘Inferno‘  ])])

When a node is rendered to a page, Inferno react uses the Render function, but Inferno's render function belongs to the Inferno package, rather than react as a separate react-dom package.

import Inferno from ‘inferno‘Inferno.render(<div>Hello, Inferno</div>)

Component

Inferno declares components in three ways: function components, ES6 (2015) classes inherit the component class, and use the Createclass function. This is basically the same as react, but the Inferno component class comes from a separate package "inferno-component", and the Createclass function comes from a separate package "Inferno-create-class".

Inferno strongly encourages developers to use function components, that is, only one component equivalent to the Render function, which has the characteristics of stateless, similar to pure functions. You'll also see that Inferno provides a series of features that are very handy for working with function components. Life cycle functions

We know that in react, if a component uses the Createclass function to create or inherit a component class, it can do things by implementing life cycle methods-such as Componentdiemount-at key points in the component's life cycle, And the function component is out of the way. Inferno can achieve life cycle management by passing the function component into the lifecycle attribute function. The life cycle attribute names are mostly preceded by those life cycle names. All life cycle attributes supported by Inferno are as follows:

• Oncomponentwillmount
• Oncomponentdidmount
• Oncomponentshouldupdate
• Oncomponentwillupdate
• Oncomponentdidupdate
• Oncomponentwillunmount

This allows us to inject a lifecycle property function into a function component when creating a container-type component with the Inferno-redux connect function, which makes it possible to use function components in more cases.

Note: The lifecycle attribute supports only function components and is not valid for components created in other ways. No_op

Shouldcomponentupdate the attribute of this life cycle is oncomponentshouldupdate, we know that it is possible to improve performance by making some judgments about whether or not to render in this life cycle. Inferno there is a more convenient way to do this is to inferno.no_op. This is a markup that does not need to be re-rendered, and when the token is returned in the rendered function (the function component itself or the render function), it is equivalent to returning false in Shouldcomponentupdate. No_op and function components are very simple and easy to use. Unfortunately, the function of the function component cannot get the properties of the last render of the component, and the most commonly used method to determine whether a re-render is required is not available on no_op.

Ref

In react, you can add a ref string property to an element, and after the component is rendered, you can find the element that is tagged with the ref attribute by This.refs.xxx. The inferno element also supports the ref attribute, but unlike react, it does not accept a string, but rather a callback function. This callback function is called after the component rendering is complete, and the passed parameter is the true DOM node of the element, and you are free to store the node anywhere for later use or to use it immediately. This allows the function component to use ref-referenced elements as well.

However, due to the difference between inferno and react, many react-based components are difficult to fit on inferno. At the moment I have not found a good solution, anyway, I did not try to use the react components to inferno up, as I said before, if you want to use ant design based on react component library, or honestly use react bar.

Another notable point is that the ref attribute is valid only for native DOM elements, such as ' div ', ' input ', and the Inferno component (non-native DOM tag) automatically ignores the ref attribute when it is loaded. Even if we want to pass elements manually through the ref attribute in the component we write, we also find that the ref attribute is not received at all. It's really a bit strange. But since it's a component of your own, you can simply name the property as needed. For example, a "elref" attribute can be set to pass it directly to the ref attribute of the component's outermost label (native DOM tag, non-Inferno component) so that the outermost actual DOM element can be obtained when the component is used. If you want the component's ref to be the same as the react component through ref, you can set a "Cpnref" property, call it in the Componentdidmount method, and pass in the component instance object, which is this. But pay attention to naming conventions in your project.

OnChange and event function bindings

Inferno's event handling method and react are basically the same, but the Change event processing and react different, inferno with the input native change event triggered the same way, will not let each keyboard input trigger the Change event. To get the onchange effect in react, you can use Oninput.

Inferno provides a very small event helper function: Linkevent. We know that when declaring a react component with a class of ES6, the event handler for the class method needs to be bound to this by the "This" binding, and should be bound in the constructor instead of on the event property to avoid performance loss. Inferno a more concise approach through linkevent, see the following example to see how it is used:

import Inferno, { linkEvent } from ‘inferno‘import Component from ‘inferno-component‘class MyComponent extends Component {  render () {    return <div><input type="text" onChange={linkEvent(this, handleChange)} /><div>;  }}function handleChange(instance, event) {  instance.props.setValue(event.target.value)}

Linkevent actually did a very simple thing, that is, to return an object like this: {data:this, event:handlechange}. Writing this object directly in the onchange attribute is also the same effect. The Inferno event wrapper function, when encountered with an object of this format, will handle the corresponding special processing.

I think the meaning of linkevent is not only to slightly simplify the binding of event handlers, but to make it easy for function components to use event handlers. As shown in the following example:

import Inferno, { linkEvent } from ‘inferno‘export default function (props) {  return <div><input type="text" onChange={linkEvent(props, handleChange)} /><div>;}function handleChange(props, event) {  props.setValue(event.target.value)}

The key in the list

React requires that each element in the array must have a different key attribute when the array is rendered, and a scary red warning on the console if no key is present.

The inferno element also supports the key attribute, but the function is not the same as react. Its role is to guide the element rendering, for the same level of sibling elements, in a single render, with the same element that renders with the same key, this element will not be replaced, but will remain the original state (such as the INPUT element's focus state and the non-controlled input value unchanged).

Note that the key property of the Inferno element is valid for sibling elements of the same level in the same parent element, that is, not limited to array elements. For the rendered array, Inferno also does not require that the elements in the array have a key attribute, and the element with duplicate key is not excluded, only a console warning is given.

In general, Inferno does not recommend using the key property unless you need to preserve the native Dom state of the element, or you need to add or remove elements in the middle of the array.

Proptypes

Inferno does not support the use of Proptypes to qualify component properties like react. In fact, I used to use react in the development of rare proptypes, even if used, at most, also reflects the functionality of a document, because react does not match to the proptypes type of property throws an exception, but only at development time in the console output warning. It is true that proptypes validation makes some types of errors easier to discover in team development, but for me that is accustomed to the dynamic type language, there is no proptypes and there is no sense of loss, and I have even deliberately made some of these properties to be multiple types to achieve a more flexible API when developing some components.

Component Encapsulation

As mentioned earlier, for some of the more complex components, it is convenient to find some mature, non-dependent framework-specific third-party components for encapsulation. This is not really inferno's unique ability, react is also very good at this. However, due to the fact that react has a complete library of supporting components, many people are less likely to be involved in the encapsulation of third-party components in development. Here I give an example for reference.

Just take the date to select the component. I'm not going to use an "old-fashioned control" like My97datepicker, because it requires a stiff introduction to a bunch of things that don't fit into the way of modular development now, I chose the flatpickr found on NPM. After installing it with NPM, you can encapsulate it with the following code:

 import Inferno from ' Inferno ' import Component from ' inferno-component ' import Moment from ' moment ' import flatpickr from ' Flatpickr ' import flatpickrzh from ' flatpickr/dist/l10n/zh.js ' import '    Flatpickr/dist/flatpickr.css ' Flatpickr.localize (FLATPICKRZH.ZH) Export default class extends component{render () { const {style, className, value} = This.props return (<input ref={el=>this.el = el} Style={style} classname= {className} value={value}/>)} componentdidmount () {const {onChange, options} = this.props THIS.PICKR = FLA    Tpickr (This.el, {onChange (dates) {OnChange (Moment (Dates[0]). Format (' Yyyy-mm-dd ')}, ... options })} Componentwillunmount () {This.pickr.destroy ()}}  

The general way to encapsulate a component is to take out the rendered DOM element when the Inferno component renders, and build a third-party component with it and the attributes passed in through props. Flatpickr needs to use a DOM element as the trigger element for the calendar display, where an INPUT element is fixed. The properties required for Flatpickr are passed through the options property in addition to Onchagne, and date formatting is done in onchange to make the component easier to use in certain situations. Because of the onchange and value, this component can be manipulated like other form elements, and in order to be consistent with other form elements, in the actual project I will change the parameters passed to onchange, simulate an event object, Put the values in the Event.target.value for easy batch processing.

Finally, don't forget to destroy third-party components when uninstalling components, or you might leave a heap of junk on the page.

Written in the last

I believe that by reading these words, you have mastered the development of react programmers can be developed with Inferno. I write these as a summary of the development of inferno in the previous period, and I hope to make it easier for more people to understand and try to use the small and beautiful framework of Inferno.

Developing high-performance responsive Web applications with inferno instead of react