inferno README

The project's README from github.com/infernojs/inferno. As one markdown file: README.md.

Inferno

Build Status Coverage Status MIT NPM npm downloads Discord gzip size Backers on Open Collective Sponsors on Open Collective

Inferno is an insanely fast, React-like library for building high-performance user interfaces on both the client and server.

Description

The main objective of the InfernoJS project is to provide the fastest possible runtime performance for web applications. Inferno excels at rendering real time data views or large DOM trees.

The performance is achieved through multiple optimizations, for example:

Features

Runtime requirements

Inferno v9 requires following features to be present in the executing runtime:

Browser support

Since version 4 we have started running our test suite without any polyfills. Inferno is now part of Saucelabs open source program and we use their service for executing the tests.

InfernoJS is actively tested with browsers listed below, however it may run well on older browsers as well. This is due to limited support of browser versions in recent testing frameworks. https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md

Browser Test Status

Migration guides

Benchmarks

Live examples at https://infernojs.github.io/inferno

Code Example

Let's start with some code. As you can see, Inferno intentionally keeps the same design ideas as React regarding components: one-way data flow and separation of concerns.

In these examples, JSX is used via the Inferno JSX Babel Plugin to provide a simple way to express Inferno virtual DOM. You do not need to use JSX, it's completely optional, you can use hyperscript or createElement (like React does). Keep in mind that compile time optimizations are available only for JSX.

import { render } from 'inferno';

const message = "Hello world";

render(
  <MyComponent message={ message } />,
  document.getElementById("app")
);

Furthermore, Inferno also uses ES6 components like React:

import { render, Component } from 'inferno';

class MyComponent extends Component {
  constructor(props) {
    super(props);
    this.state = {
      counter: 0
    };
  }
  render() {
    return (
      <div>
        <h1>Header!</h1>
        <span>Counter is at: { this.state.counter }</span>
      </div>
    );
  }
}

render(
  <MyComponent />,
  document.getElementById("app")
);

Because performance is an important aspect of this library, we want to show you how to optimize your application even further. In the example below we optimize diffing process by using JSX $HasVNodeChildren and $HasTextChildren to predefine children shape compile time. In the MyComponent render method there is a div that contains JSX expression node as its content. Due to dynamic nature of Javascript that variable node could be anything and Inferno needs to go through the normalization process to make sure there are no nested arrays or other invalid data. Inferno offers a feature called ChildFlags for application developers to pre-define the shape of vNode's child node. In this example case it is using $HasVNodeChildren to tell the JSX compiler, that this vNode contains only single element or component vNode. Now inferno will not go into the normalization process runtime, but trusts the developer decision about the shape of the object and correctness of data. If this contract is not kept and node variable contains invalid value for the pre-defined shape (fe. null), then application would crash runtime. There is also span-element in the same render method, which content is set dynamically through _getText() method. There $HasTextChildren child-flag fits nicely, because the content of that given "span" is never anything else than text. All the available child flags are documented here.

import { createTextVNode, render, Component } from 'inferno';

class MyComponent extends Component {
  constructor(props) {
    super(props);
    this.state = {
      counter: 0
    };
  }

  _getText() {
     return 'Hello!';
  }
  
  render() {
    const node = this.state.counter > 0 ? <div>0</div> : <span $HasTextChildren>{this._getText()}</span>;
      
    return (
      <div>
        <h1>Header!</h1>
        <div $HasVNodeChildren>{node}</div>
      </div>
    );
  }
}

render(
  <MyComponent />,
  document.getElementById("app")
);

Tear down

To tear down inferno application you need to render null on root element. Rendering null will trigger unmount lifecycle hooks for whole vDOM tree and remove global event listeners. It is important to unmount unused vNode trees to free browser memory. 

import { createTextVNode, render, Component } from 'inferno';

const rootElement = document.getElementById("app");

// Start the application
render(
  <ExampleComponent/>,
  rootElement
);

// Tear down
render(
  null,
  rootElement
);

More Examples

If you have built something using Inferno you can add them here:

Getting Started

The easiest way to get started with Inferno is by using Create Inferno App.

Alternatively, you can try any of the following:

Core package:

npm install --save inferno

Addons:

# server-side rendering
npm install --save inferno-server
# routing
npm install --save inferno-router

Pre-bundled files for browser consumption can be found on our cdnjs:

Or on jsDelivr:

https://cdn.jsdelivr.net/npm/inferno@latest/dist/inferno.min.js

Or on unpkg.com:

https://unpkg.com/inferno@latest/dist/inferno.min.js

Creating Virtual DOM

JSX:

npm install --save-dev babel-plugin-inferno

Hyperscript:

npm install --save inferno-hyperscript

createElement:

npm install --save inferno-create-element

Compatibility with existing React apps

npm install --save-dev inferno-compat

Note: Make sure you read more about inferno-compat before using it.

Third-party state libraries

Inferno now has bindings available for some of the major state management libraries out there:

JSX

Inferno has its own JSX Babel plugin.

Differences from React

Differences from Preact

Event System

Like React, Inferno also uses a light-weight synthetic event system in certain places (although both event systems differ massively). Inferno's event system provides highly efficient delegation and an event helper called linkEvent.

One major difference between Inferno and React is that Inferno does not rename events or change how they work by default. Inferno only specifies that events should be camel cased, rather than lower case. Lower case events will bypass Inferno's event system in favour of using the native event system supplied by the browser. For example, when detecting changes on an <input> element, in React you'd use onChange, with Inferno you'd use onInput instead (the native DOM event is oninput).

Available synthetic events are:

linkEvent (package: inferno)

linkEvent() is a helper function that allows attachment of props/state/context or other data to events without needing to bind() them or use arrow functions/closures. This is extremely useful when dealing with events in functional components. Below is an example:

import { linkEvent } from 'inferno';

function handleClick(props, event) {
  props.validateValue(event.target.value);
}

function MyComponent(props) {
  return <div><input type="text" onClick={ linkEvent(props, handleClick) } /><div>;
}

This is an example of using it with ES2015 classes:

import { linkEvent, Component } from 'inferno';

function handleClick(instance, event) {
  instance.setState({ data: event.target.value });
}

class MyComponent extends Component {
  render () {
    return <div><input type="text" onClick={ linkEvent(this, handleClick) } /><div>;
  }
}

linkEvent() offers better performance than binding an event in a class constructor and using arrow functions, so use it where possible.

Controlled Components

In HTML, form elements such as <input>, <textarea>, and <select> typically maintain their own state and update it based on user input. In Inferno, mutable state is typically kept in the state property of components, and only updated with setState().

We can combine the two by making the Inferno state be the "single source of truth". Then the Inferno component that renders a form also controls what happens in that form on subsequent user input. An input form element whose value is controlled by Inferno in this way is called a "controlled component".

Inferno Top-Level API

render (package: inferno)

import { render } from 'inferno';

render(<div />, document.getElementById("app"));

Render a virtual node into the DOM in the supplied container given the supplied virtual DOM. If the virtual node was previously rendered into the container, this will perform an update on it and only mutate the DOM as necessary, to reflect the latest Inferno virtual node.

Warning: If the container element is not empty before rendering, the content of the container will be overwritten on the initial render.

createRenderer (package: inferno)

createRenderer creates an alternative render function with a signature matching that of the first argument passed to a reduce/scan function. This allows for easier integration with reactive programming libraries, like RxJS and Most.

import { createRenderer } from 'inferno';
import { scan, map } from 'most';

const renderer = createRenderer();


// NOTE: vNodes$ represents a stream of virtual DOM node updates
scan(renderer, document.getElementById("app"), vNodes$);

See inferno-most-fp-demo for an example of how to build an app architecture around this.

createElement (package: inferno-create-element)

Creates an Inferno VNode using a similar API to that found with React's createElement()

import { Component, render } from 'inferno';
import { createElement } from 'inferno-create-element';

class BasicComponent extends Component {
  render() {
    return createElement('div', {
        className: 'basic'
      },
      createElement('span', {
        className: this.props.name
      }, 'The title is ', this.props.title)
    )
  }
}

render(
  createElement(BasicComponent, { title: 'abc' }),
  document.getElementById("app")
);

Component (package: inferno)

Class component:

import { Component } from 'inferno';

class MyComponent extends Component {
  render() {
      return <div>My Component</div>
  }
}

This is the base class for Inferno Components when they're defined using ES6 classes.

Functional component:

const MyComponent = ({ name, age }) => (
  <span>My name is: { name } and my age is: {age}</span>
);

Another way of using defaultHooks.

export function Static() {
    return <div>1</div>;
}

Static.defaultHooks = {
    onComponentShouldUpdate() {
        return false;
    }
};

Default props

export function MyFunctionalComponent({value}) {
    return <div>{value}</div>;
}

MyFunctionalComponent.defaultProps = {
    value: 10
};

Functional components are first-class functions where their first argument is the props passed through from their parent.

createVNode (package: inferno)

import { createVNode } from 'inferno';

createVNode(
  flags,
  type,
  [className],
  [...children],
  [childFlags],
  [props],
  [key],
  [ref]
)

createVNode is used to create html element's virtual node object. Typically createElement() (package: inferno-create-element), h() (package: inferno-hyperscript) or JSX are used to create VNodes for Inferno, but under the hood they all use createVNode(). Below is an example of createVNode usage:

import { VNodeFlags, ChildFlags } from 'inferno-vnode-flags';
import { createVNode, createTextVNode, render } from 'inferno';

const vNode = createVNode(VNodeFlags.HtmlElement, 'div', 'example', createTextVNode('Hello world!'), ChildFlags.HasVNodeChildren);

// <div class="example">Hello world!</div>

render(vNode, container);

createVNode arguments explained:

flags: (number) is a value from VNodeFlags, this is a numerical value that tells Inferno what the VNode describes on the page.

type: (string) is tagName for element for example 'div'

className: (string) is the class attribute ( it is separated from props because it is the most commonly used property )

children: (vNode[]|vNode) is one or array of vNodes to be added as children for this vNode

childFlags: (number) is a value from ChildFlags, this tells inferno shape of the children so normalization process can be skipped.

props: (Object) is object containing all other properties. fe: {onClick: method, 'data-attribute': 'Hello Community!}

key: (string|number) unique key within this vNodes siblings to identify it during keyed algorithm.

ref: (function) callback which is called when DOM node is added/removed from DOM.

createComponentVNode (package: 'inferno')

import { createComponentVNode } from 'inferno';

createComponentVNode(
  flags,
  type,
  [props],
  [key],
  [ref]
)

createComponentVNode is used for creating vNode for Class/Functional Component.

Example:

import { VNodeFlags, ChildFlags } from 'inferno-vnode-flags';
import { createVNode, createTextVNode, createComponentVNode, render } from 'inferno';

function MyComponent(props, context) {
  return createVNode(VNodeFlags.HtmlElement, 'div', 'example', createTextVNode(props.greeting), ChildFlags.HasVNodeChildren);
}

const vNode = createComponentVNode(VNodeFlags.ComponentFunction, MyComponent, {
  greeting: 'Hello Community!'
}, null, {
  onComponentDidMount() {
    console.log("example of did mount hook!")
  }
})

// <div class="example">Hello Community!</div>

render(vNode, container);

createComponentVNode arguments explained:

flags: (number) is a value from VNodeFlags, this is a numerical value that tells Inferno what the VNode describes on the page.

type: (Function/Class) is the class or function prototype for Component

props: (Object) properties passed to Component, can be anything

key: (string|number) unique key within this vNodes siblings to identify it during keyed algorithm.

ref: (Function|Object) this property is object for Functional Components defining all its lifecycle methods. For class Components this is function callback for ref.

createTextVNode (package: 'inferno')

createTextVNode is used for creating vNode for text nodes.

createTextVNode arguments explained: text: (string) is a value for text node to be created. key: (string|number) unique key within this vNodes siblings to identify it during keyed algorithm.

import { createTextVNode } from 'inferno';

createTextVNode(
  text,
  key
)

cloneVNode (package: inferno-clone-vnode)

This package has same API as React.cloneElement

import { cloneVNode } from 'inferno-clone-vnode';

cloneVNode(
  vNode,
  [props],
  [...children]
)

Clone and return a new Inferno VNode using a VNode as the starting point. The resulting VNode will have the original VNode's props with the new props merged in shallowly. New children will replace existing children. key and ref from the original VNode will be preserved.

cloneVNode() is almost equivalent to:

<VNode.type {...VNode.props} {...props}>{children}</VNode.type>

An example of using cloneVNode:

import { createVNode, render } from 'inferno';
import { cloneVNode } from 'inferno-clone-vnode';
import { VNodeFlags } from 'inferno-vnode-flags';

const vNode = createVNode(VNodeFlags.HtmlElement, 'div', 'example', 'Hello world!');
const newVNode = cloneVNode(vNode, { id: 'new' }); // we are adding an id prop to the VNode

render(newVNode, container);

If you're using JSX:

import { render } from 'inferno';
import { cloneVNode } from 'inferno-clone-vnode';

const vNode = <div className="example">Hello world</div>;
const newVNode = cloneVNode(vNode, { id: 'new' }); // we are adding an id prop to the VNode

render(newVNode, container);

createPortal (package: 'inferno')

HTML:

<div id="root"></div>
<div id="outside"></div>

Javascript:

const { render, Component, version, createPortal } from 'inferno';

function Outsider(props) {
	return <div>{`Hello ${props.name}!`}</div>;
}

const outsideDiv = document.getElementById('outside');
const rootDiv = document.getElementById('root');

function App() {
	return (
  	    <div>
    	    Main view
            ...
            {createPortal(<Outsider name="Inferno" />, outsideDiv)}
        </div>
    );
}


// render an instance of Clock into <body>:
render(<App />, rootDiv);

Results into:

<div id="root">
    <div>Main view ...</div>
</div>
<div id="outside">
    <div>Hello Inferno!</div>
</div>

Cool, huh? Updates (props/context) will flow into "Outsider" component from the App component the same way as any other Component. For inspiration on how to use it click here!

createRef (package: inferno)

createRef API provides shorter syntax than callback ref when timing of element is not needed.

import { Component, render, createRef } from 'inferno';

class Foobar extends Component {
  constructor(props) {
    super(props);

    // Store reference somewhere
    this.element = createRef(); // Returns object {current: null}
  }

  render() {
    return (
      <div>
        <span id="span" ref={this.element}>
          Ok
        </span>
      </div>
    );
  }
}

render(<Foobar />, container);

createFragment (package: inferno)

createFragment is the native way to createFragment vNode. createFragment(children: any, childFlags: ChildFlags, key?: string | number | null)

createFragment arguments explained:

children: (Array) Content of fragment vNode, typically array of VNodes

childFlags: (number) is a value from ChildFlags, this tells inferno shape of the children so normalization process can be skipped.

key: (string|number) unique key within this vNodes siblings to identify it during keyed algorithm.

Alternative ways to create fragment vNode are:

In the below example both fragments are identical except they have different key

import { Fragment, render, createFragment } from 'inferno';
import { ChildFlags } from 'inferno-vnode-flags';

function Foobar() {
    return (
      <div $HasKeyedChildren>
        {createFragment(
            [<div>Ok</div>, <span>1</span>],
            ChildFlags.HasNonKeyedChildren,
            'key1'
        )}
        <Fragment key="key2">
          <div>Ok</div>
          <span>1</span>
        </Fragment>
      </div>
    );
}

render(<Foobar />, container);

forwardRef (package: inferno)

forwardRef is a new mechanism to "forward" ref inside a functional Component. It can be useful if you have simple functional Components and you want to create reference to a specific element inside it.

import { forwardRef, Component, render } from 'inferno';

const FancyButton = forwardRef((props, ref) => (
  <button ref={ref} className="FancyButton">
    {props.children}
  </button>
));

class Hello extends Component {
  render() {
    return (
      <FancyButton
        ref={btn => {
          if (btn) {
            // btn variable is the button rendered from FancyButton
          }
        }}
      >
        Click me!
      </FancyButton>
    );
  }
}

render(<Hello />, container);

hydrate (package: inferno-hydrate)

import { hydrate } from 'inferno-hydrate';

hydrate(<div />, document.getElementById("app"));

Same as render(), but is used to hydrate a container whose HTML contents were rendered by inferno-server. Inferno will attempt to attach event listeners to the existing markup.

findDOMNode (package: inferno-extras)

This feature has been moved from inferno to inferno-compat in v6. No options are needed anymore.

Note: we recommend using a ref callback on a component to find its instance, rather than using findDOMNode(). findDOMNode() cannot be used on functional components.

If a component has been mounted into the DOM, this returns the corresponding native browser DOM element. This method is useful for reading values out of the DOM, such as form field values and performing DOM measurements. In most cases, you can attach a ref to the DOM node and avoid using findDOMNode() at all. When render returns null or false, findDOMNode() returns null. If Component has rendered fragment it returns the first element.

Inferno Flags (package: inferno-vnode-flags)

VNodeFlags:

VNodeFlags Masks:

ChildFlags

ChildFlags Masks

renderToString (package: inferno-server)

import { renderToString } from 'inferno-server';

const string = renderToString(<div />);

Render a virtual node into an HTML string, given the supplied virtual DOM.

Functional component lifecycle events

Name Triggered when Arguments to callback
onComponentWillMount a functional component is about to mount
onComponentDidMount a functional component has mounted successfully domNode
onComponentShouldUpdate a functional component has been triggered to update lastProps, nextProps
onComponentWillUpdate a functional component is about to perform an update lastProps, nextProps
onComponentDidUpdate a functional component has performed an update lastProps, nextProps
onComponentWillUnmount a functional component is about to be unmounted domNode
onComponentDidAppear a functional component has mounted and is ready for animations domNode, props
onComponentWillDisappear a functional component is unmounted before DOM node is removed domNode, props, callback

onComponentWillDisappear has special type of argument "callback" which needs to be called when component is ready to be removed from the DOM. fe. after animations are finished.

Class component lifecycle events

All these Component lifecycle methods ( including render and setState - callback) are called with Component instance context. You don't need to "bind" these methods.

Name Triggered when Arguments to callback
componentDidMount component has been mounted successfully
componentWillMount component is about to mount
componentWillReceiveProps before render when component updates nextProps, context
shouldComponentUpdate component has been triggered to update nextProps, nextState
componentWillUpdate component is about to perform an update nextProps, nextState, context
componentDidUpdate component has performed an update lastProps, lastState, snapshot
componentWillUnmount component is about to be unmounted
getChildContext before render method, return value object is combined to sub tree context
getSnapshotBeforeUpdate before component updates, return value is sent to componentDidUpdate as 3rd parameter lastProps, lastState
static getDerivedStateFromProps before render method nextProps, state
componentDidAppear component has mounted and is ready for animations domNode
componentWillDisappear component is unmounted before DOM node is removed domNode, callback

componentWillDisappear has special type of argument "callback" which needs to be called when component is ready to be removed from the DOM. fe. after animations are finished.

Using functional lifecycle events

Functional lifecycle events must be explicitly assigned via props onto a functional component like shown below:

import { render } from 'inferno';

function mounted(domNode) {
  // [domNode] will be available for DOM nodes and components (if the component has mounted to the DOM)
}

function FunctionalComponent({ props }) {
  return <div>Hello world</div>;
}

render(
  <FunctionalComponent onComponentDidMount={ mounted } />,
  document.getElementById("app")
);

Please note: class components (ES2015 classes) from inferno do not support the same lifecycle events (they have their own lifecycle events that work as methods on the class itself).

Development vs Production modes

By default, Inferno will run in development mode. Development mode provides extra checks and better error messages at the cost of slower performance and larger code to parse. When using Inferno in a production environment, it is highly recommended that you turn off development mode.

Running Inferno on Node JS

Ensure the environment variable process.env.NODE_ENV is set to production.

Application bundling

When building your application bundle, ensure process.env.NODE_ENV is replaced with string"development" or "production" based on the workflow. It is recommended to use ts-plugin-inferno for typescript TSX compilation and babel-plugin-infeno for javascript JSX compilation.

When building for development, you may want to use inferno.dev.mjs for v9 or newer and inferno.dev.esm.js for older than v9. That bundle file contains ES6 exports for better tree-shaking support, improved error messages and added validation to help fixing possible issues during development. The file is found from package.json - dev:module entry point and the files are physically located in node_modules/inferno/dist/ folder. Remember that it is not recommended to use that file in production due to slower performance. For production usage use node_modules/inferno/dist/inferno.mjs -file for v9 or newer and node_modules/inferno/dist/inferno.esm.js -file for older than v9.

Example of Webpack configuration:

const path = require('path');
const infernoTsx = require('ts-plugin-inferno').default;

... webpack config ...

    module: {
        rules: [
            {
                test: /\.js$/, // Add "jsx" if your application uses `jsx` file extensions
                exclude: /node_modules/,
                use: [{
                    loader: 'babel-loader',
                    options: {
                        plugins: [
                            // Compile javascript JSX syntax using inferno's own plugin
                            ['babel-plugin-inferno', {imports: true}]
                        ]
                    }
                }]
            },
            {
                test: /\.ts+(|x)$/, // Compile ts and tsx extensions
                exclude: /node_modules/,
                use: [{
                    loader: 'ts-loader',
                    options: {
                        getCustomTransformers: () => ({
                            // inferno custom TSX plugin
                            after: [infernoTsx()]
                        }),
                        compilerOptions: {
                            /* typescript compiler options */
                        }
                    }
                }]
            }
        ]
    },
    resolve: {
        extensions: ['.js', '.ts', '.tsx'],
        alias: {
            // This maps import "inferno" to es6 module entry based on workflow
            inferno: path.resolve(__dirname, 'node_modules/inferno/dist', isProduction ? 'index.dev.mjs' : 'index.mjs')
        }
    },
    plugins: [
        new webpack.DefinePlugin({
            'process.env': {
                'NODE_ENV':  JSON.stringify(isProduction ? 'production' : 'development')
            }
        })
    ]

Example of Rollup configuration:

const path = require('path');
const alias = require('@rollup/plugin-alias');
const {babel} = require('@rollup/plugin-babel');
const replace = require('@rollup/plugin-replace');
const typescript = require('rollup-plugin-typescript2');
const transformInferno = require('ts-plugin-inferno').default;

... Rollup config ...
{
    input: /* entry file */,
    plugins: [
            alias({
                resolve: ['.js'],
                entries: [
                    // This maps import "inferno" to es6 module entry based on workflow
                    {find: 'inferno', replacement: path.resolve(__dirname, 'node_modules/inferno/dist', isProduction ? 'index.dev.mjs' : 'index.mjs')}
                ]
            }),
            typescript({
                include: ['*.ts+(|x)', '**/*.ts+(|x)'],
                transformers: [
                    () => ({
                        after: [transformInferno()]
                    })
                ],
                tsconfig: 'tsconfig.json',
                tsconfigOverride: {
                    /* typescript compiler options */
                }
            }),
            babel({
                babelrc: false,
                sourceMaps: isDeploy,
                plugins: [
                    // Compile javascript JSX syntax using inferno's own plugin
                    ['babel-plugin-inferno', {imports: true}]
                ],
                babelHelpers: 'bundled'
            })
    ]
}

Custom namespaces

Inferno always wants to deliver great performance. In order to do so, it has to make intelligent assumptions about the state of the DOM and the elements available to mutate. Custom namespaces conflict with this idea and change the schema of how different elements and attributes might work, so Inferno makes no attempt to support namespaces. Instead, SVG namespaces are automatically applied to elements and attributes based on their tag name.

Development

If you want to contribute code, fork this project and submit a PR from your fork. To run browser tests you need to build the repos. A complete rebuild of the repos can take >5 mins.

$ git clone [email protected]:infernojs/inferno.git
$ cd inferno && pnpm install
$ pnpm run test:node
$ pnpm run build
$ pnpm run test:browser

If you only want to run the browser tests when coding, use the following to reduce turnaround by 50-80%:

$ pnpm run quick-test:browser # Compiles all packages and runs browser tests
$ pnpm run quick-test:browser-inferno # Only compiles the inferno package and runs browser tests
$ pnpm run quick-test:browser-debug # Compiles all packages and runs browser tests with "debug"

Community

There is an InfernoJS Discord. You can join via https://discord.gg/SUKuhgaBpF.

Contributors

This project exists thanks to all the people who contribute. [Contribute].

Backers

Thank you to all our backers! 🙏 [Become a backer]

Sponsors

Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]

inferno (infernojs/inferno)

Searching Database…

16.5K ·GitHub
Inferno
这是什么东西?Inferno 是一个速度极快的、类似 React 的 JavaScript 库,用于构建现代用户界面。它渲染虚拟 DOM,并保留了 React 的核心设计理念:组件、单向数据流以及关注点分离。
它是一个完整的框架,还是只是一个视图层?只是视图层:一个同时支持类组件和函数式组件的组件库,和 React 一样。状态管理需要你自己选择——官方为 Redux、MobX 和 Cerebral 提供了绑定。
我该怎么用它新建一个项目?README 说 Create Inferno App 是最简单的上手方式。其他选择:最简的 Inferno Boilerplate、功能更全的 Inferno Starter Project、一个移动端起步项目,或者从 cdnjs、jsDelivr 和 unpkg 获取预先打包好的浏览器版本。
我需要 polyfill 吗?它在老浏览器里能跑吗?Inferno v9 要求比较新的运行环境:Promise、String.prototype.includes 和 startsWith、Array.prototype.includes、对象展开运算符以及 for...of。从 v4 开始,测试就在没有 polyfill 的情况下运行,面向现代浏览器,不过老浏览器可能仍然可用。
必须用 JSX 吗?不用——你可以像在 React 里那样,改用 hyperscript 或 createElement。但编译期优化只有在使用 JSX 时才可用。
它能在浏览器之外运行吗,比如移动端或原生应用?它是针对浏览器和服务器、围绕 DOM 设计的,所以不支持 React Native。不过社区有一个 Inferno Mobile Starter Project,可以用来开发移动应用。
linkEvent 是什么?为什么 README 推荐它?它是一个辅助函数,可以把 props、state 或 context 数据附加到事件处理函数上,而不用 bind() 或箭头函数闭包。README 说它的性能比在类构造函数里绑定更好,所以它是处理事件的首选方式,在函数式组件里尤其如此。
我用惯了 React,表单事件上有什么要注意的坑?有——Inferno 不改事件名称:只有像 onClick 这样的驼峰命名会走它的合成事件系统,小写名称则会直接落到浏览器原生事件上。所以要用原生 DOM 事件 onInput,而不是 React 的 onChange。
我还想进一步压榨渲染性能,可以吗?可以——像 $HasVNodeChildren 和 $HasTextChildren 这样的子节点标志,让你能在编译时预先声明 vNode 子节点的结构,Inferno 就可以跳过运行时的规范化。但如果数据不符合这个约定,应用会在运行时崩溃,所以只在结构有保证的情况下才使用它们。
有真的项目在用它吗?README 里提到的例子包括 Lemmy,一个可以自己架设的 Reddit 替代品,它的前端就是用 Inferno 构建的;此外还有一些演示项目,比如 CodeSandbox 上的 TMDb 电影数据库界面,以及简单的时钟和计数器示例。
What are similar projects?snabbdom, preact, emotion, styled-components, million, riot, hyperapp, virtual-dom
Which topics is it in?vdom, jsx, dom, ssr, frontend-framework, rendering, javascript-library, ui, web-development, performance, react, npm
Creator
infernojs
Size
46.9 MB
Stars
16.5K
Updated
CommitOct 17Releasev10.0.0Oct 04
Age
11y
Commits · 90 Days