Mithril debugger

Prioritised features:

  1. Pointer-based hover-overlay to highlight elements generated by Mithril
  2. With a view of their corresponding vnode & associated path
  3. That allows travel through path and vnode tree interface to highlight other elements

Followed by:

  • Patch reporter:
    • Receive inspectable logs for changes that occur on render

There are many scenarios where a particular interaction makes repeated calls to an asynchronous, and each subsequent call invalidates the previous. For example, typing in a field which can query an HTTP service for insights: if I type 'a', and wait long enough, a call should be sent to ask for pertinent suggestions; but if I'm still waiting on that response when I type 'b', then the results of the last call are impertinent. Only the last call's response should resolve.

Calling latest creates a 'promise debouncer' function. Either you pass in the async function there and then and call it without arguments, or you instantiate it empty and pass in the async function upon request. In either case, calling the function before its last promise has resolved will ensure that promise never resolves: only the last request will ever resolve.

View BornToDie.js
const BornToDie = v => {
born = true,
to = false,
die = false,
let query
let draw
View Historian.js
const Historian = Object.assign(
Component => {
const histories = new WeakMap
return {
onbeforeupdate({}, old){
if(Component.onbeforeupdate && Component.onbeforeupdate.apply(this, arguments) === false)
return false
histories.set(old.state, old)
View broken.js
const broken = (promise, state = {
pending: true,
settled: false,
resolved: false,
rejected: false,
value: undefined,
error: undefined,
}) => (

Written to avoid the noisome pattern of

input => {
  const reference = expression with input


  return reference 
View mimix.js
const {assign, keys} = Object
const scope = fn =>
return fn(x => x.apply(this, arguments))
const compose = (key, values) => (
key === 'view'

Precedent: render props (or, view attributes)

I've been toying the idea of 'view attributes' for a while, but over the past year they've taken off in the popular domain of React as 'render props'.

A component written to make use of view attributes is a 'view component' inasmuch as it doesn't have an opinion on downstream virtual DOM, but performs a useful function in the context of virtual DOM (whether that be transforming other attribute input, querying DOM or external references, providing state), which can be exposed via the view attribute provided to it.

Here's a sample of view components with associated demos.

The React community has already proved the far-reaching value of this concept to the point where the pattern is part of the official documentation, ahead of 'integrating with other libraries'. React Router

View NoopComponent.js
export const {
view: v => (
?, v)