Tarabass / solid

A declarative, efficient, and flexible JavaScript library for building user interfaces.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

drawing
     The Deceptively Simple User Interface Library

Build Status Coverage Status NPM Version Gitter Subreddit subscribers

Solid is yet another declarative Javascript library for creating user interfaces. It does not use a Virtual DOM. Instead it opts to compile its templates down to real DOM nodes and wrap updates in fine grained computations. This way when your state updates only the code that depends on it runs.

Key Features

  • Real DOM with fine-grained updates (No Virtual DOM! No Dirty Checking Digest Loop!).
  • Declarative data
    • Simple composable primitives without the hidden rules.
    • Function Components with no need for lifecycle methods or specialized configuration objects.
  • Almost indistinguishable performance vs optimized painfully imperative vanilla DOM code. See Solid on JS Framework Benchmark.
  • Supports modern features like JSX Fragments, Context, Portals, Suspense, and Asynchronous Rendering.
  • Webcomponent friendly
    • Implicit event delegation with Shadow DOM Retargeting
    • Shadow DOM Portals
    • Custom Element friendly Suspense flow

A Simple Component looks like:
const HelloMessage = ({name}) => (
  <div>
    Hello {name}
  </div>
);

render(
  () => <HelloMessage name="Taylor" />,
  document.getElementById("hello-example")
);

Installation

To use Solid with JSX (recommended) run:

> npm install solid-js babel-preset-solid

Or you can get started with a simple app with the CLI with by running:

> npm init solid app my-app

npm init solid <project-type> <project-name> is available with npm 6+.

Solid State

It all starts with State. State objects are immutable so to update you call their companion setter function. Through the use of proxies they give the control of an immutable interface and the performance of a mutable one. Note only Plain Objects and Arrays are deeply wrapped.

import { createState, onCleanup } from 'solid-js'

const CountingComponent = () => {
  const [state, setState] = createState({counter: 0});

  const interval = setInterval(() =>
    setState({counter: state.counter + 1})
  , 1000);

  onCleanup(() => clearInterval(interval));

  return <div>{(state.counter)}</div>;
}

You can also deep set:

const [state, setState] = createState({
  user: {
    firstName: 'John'
    lastName: 'Smith'
  }
});

setState('user', {firstName: 'Jake', middleName: 'Reese'});

You can also use functions:

const [state, setState] = createState({counter: 0});
setState('counter', c => c + 1);

This takes the form similar to ImmutableJS setIn for leaving all mutation control at the top level state object. Keep in mind that setState when setting an object attempts to merge instead of replace.

But where the magic happens is with computations(effects and memos) which automatically track dependencies.

createEffect(() =>
  setState({
    displayName: `${state.user.firstName} ${state.user.lastName}`
  })
);

console.log(state.displayName); // Jake Smith

Whenever any dependency changes the State value will immediately update. JSX expressions can also be wrapped in effects so for something as trivial as a display name you could just inline the expression in the template and have it update automatically.

Solid State also exposes a reconcile method used with setState that does deep diffing to allow for automatic efficient interopt with immutable store technologies like Redux, Apollo, or RxJS.

const unsubscribe = store.subscribe(({ todos }) => (
  setState(reconcile('todos', todos)));
);
onCleanup(() => unsubscribe());

Solid Rendering

Solid's rendering is done by the DOM Expressions library. This library provides a generic optimized runtime for fine grained libraries like Solid with the opportunity to use a number of different Rendering APIs. The best option is to use JSX pre-compilation with Babel Plugin JSX DOM Expressions to give the smallest code size, cleanest syntax, and most performant code. The compiler converts JSX to native DOM element instructions and wraps expressions to be wrapped in our computations when indicated by in inner parens {( )}.

Prettier and some compile to JS libraries like CoffeeScript will strip Parenthesis causing issues with Solid's JSX. So unfortunately they are incompatible at this time. Use // prettier-ignore at the top of your JSX to have Prettier not format your JSX.

The easiest way to get setup is add babel-preset-solid to your .babelrc, or babel config for webpack, or rollup:

"presets": ["solid"]

Alternatively in non-compiled environments you can use Tagged Template Literals Lit DOM Expressions or even HyperScript with Hyper DOM Expressions.

For convenience Solid exports interfaces to runtimes for these as:

import h from 'solid-js/h';
import html from 'solid-js/html'

Remember you still need to install the library separately for these to work.

Why?

This project started as trying to find a small performant library to work with Web Components, that had easy interopt with existing standards. It is very much inspired by fine-grain change detection libraries like Knockout.js and RxJS. The idea here is to ease users into the world of Observable programming by keeping it transparent and starting simple. Classically the Virtual DOM as seen in React for all its advances has some signifigant trade-offs:

  • The VDOM render while performant is still conceptually a constant re-render
    • It feels much more imperative as variable declarations and iterative methods for constructing the tree are constantly re-evaluating.
  • Reintroduced lifecycle function hell that breaks apart the declarative nature of the data. E.g., relying on blacklisting changes across the tree with shouldComponentUpdate.
  • Homogenous promise of Components and the overly simplistic local state in practice:
    • Imposes boundaries on components to solve performance concerns
    • Places you into a very specific but not necessarily obvious structure
    • Only served to make it more ambiguous when emerging best practices lead to specialized component classification anyway
  • Abstracts debugging to the point a <div /> is not longer just a div
  • VDOM libraries still are based around having specialized data objects.

So the driving questions here are:

  • If the data is going to be specialized anyway can we use Proxies to move the complexity into it rather than the rendering while keeping the appearance simple?
  • Can this free up existing constraints on how you modularize your view code?
  • Does this approach ultimately provide more adaptibility while reducing the API surface?
  • Is fine grained change detection fundamentally more performant than the Virtual DOM?

Admittedly it takes a strong reason to not go with the general consensus of best, and most supported libraries and frameworks. And React's Hooks API addresses the majority of what I once considered its most untenable faults. But I believe there is a better way out there than how we do it today.

I cover this in more detail in my Bring Your Own Framework Blog Series (links below).

Documentation

Examples

Related Projects

Articles

Status

This project is still a work in progress. While Solid's change management is reaching stability (this repo), I am still refining the rendering APIs from the DOM Expressions.

About

A declarative, efficient, and flexible JavaScript library for building user interfaces.

License:MIT License


Languages

Language:JavaScript 57.9%Language:TypeScript 42.1%