@composi/runtime:

• Runtime
• Init
• View
• Update
• Effects
• Tagged Unions
• Subscriptions
• Composition
• Stop Program
• Immutability
• Higher Order Program

View

Representation of State

The view is a function that deals with how to present the data from the state. It doesn't dictate how that view will be produced. You can do that with @composi/core's render function, or any other rendered. You could use it to return a string of HTML for server-side rendering or even return native code for native app development. Here we're dealing with front end development so we'll use @composi/core's render function to output our program to the DOM.

The view function takes two arguments: state and send. You should already be familiar with state. Send is a function that enables the view to send messages to the update function. Send is a unary function. It can only handle one argument. Therefore to help update distinguish one message from another, we pass and object with a type. If you need to also pass along some data, you can add that to the message object as well.

In general we recommend using JSX to define the view to be created, but you could use the h function instead. Here's the same view created with JSX and then h:

function List({state}) {
  return (
    <div>
      <p>
        <input type="text">
        <button>Add</button>
      </p>
      <ul>
        {
          state.items.map(item => <li key={item.key}>{item.value}</li>)
        }
      </ul>
    </div>
  )
}

A quick glance is sufficient to understand what DOM elements will be created. Now here is the same component defined with h:

function List({state}) {
  return h(
    'div',
    {},
    [
      h(
        'p',
        {},
        [
          h(
            'input',
            {type: 'text'}
          ),
          h(
            'button',
            {},
            'Add'
          )
        ]
      ),
      h(
        'ul',
        {},
        ${
          state.items.map(item => h('li', {key: item.key}, item.value))
        }
      )
    ]
  )
}

As you can see, using the h function to create the virtual nodes instead of using JSX produces a more verbose and difficult to read result.

Sending Messages

Views can be completely static, such as a newsletter or blog. However many views will be designed for user interaction. The @composi/core runtime provides a send function for views to send messages and data to the program's update function.

A message can be any type: null, undefined, number, string, array or object. However, in most cases a message will need to be an object so you can have a consistent interface for the update function to test what type of message was sent. An object also allows you to pass along some data with the message.

When you define a program's view, you pass in two arguments, the state and the send function. In the following example, notice how in the List component we have click events that send a message object with a type and some data. This enables us to use a switch in the update function to check what type of message was sent.

See the Pen @composi/core + runtime by Robert Biggs (@rbiggs) on CodePen.

Hydration

The default render function of @composi/core makes it easy to hydrate server-rendered content. Just pass it a reference to the element you want to hydrate as the secont argument of render. Composi always mounts a component on a node that already exists in the DOM, the base for the component. A such, if you have, say, a list rendder on the server. You can automatically hydrate it by using a selector for the list as the second argument to the render function when you render your list component.