barneycarroll

[See here](https://flems.io/#0=N4IgzgpgNhDGAuEAmIBcICSYoEMB2SAdAFZggA0IAZgJYxmoDaoeOAthGpnlDXhCTKVYAezyJxXCAA8ADiIBO8AARIIVHAFcoKqprwIaYgBQA3AJTAAOnmXLReMLuUBeZcZt2vy04VgALOiQFCDxGAAYAXWVPLwAyONjveABPWQgRKh8-QKhg0IjInKCQ2xdy5QByPQN4IzxKpOUEprtfAJKCqOK80tjzG1iQ+E0FWw9bb2UqJoB+VvcF7ypCWQUReA20iGa46dX1zdT0wlMaCAB3JeV5yamvfgvpswG7qdRruyoXhdfvD7edmsgK8Z0uL2B928w1G40+U18OHg8AUYFO5yuIPutyhUMRyNR6PBFnhdgBuPu+JRaI6vVC8L+UIAvgsWZNXmyKOBoHA6mIGCBwqgAIwAFhATPILHYnHQWFwBEEXIcEngUjkihUag02hUplcAD5lJDlAB6U3KDDiCBjHBQWIwFTrDZec3KAByEBwIScynwsAgTgUduUbBE+ngAFp5Hx4A6ICpZEj-K6LaZKmBlPIwDQ+bYLrnArYVTg+Db43q8CI1Jm3QAlEQu0xVmt+zOZZS4X0BOAAawrykQbFkqeUADVvTQkfVlB3m9XA8oC-AU6Jh2JQvBM1R1mxlM6VJtB96AOYJ-cQMOmZCDPCxN0AMVwJ8zR4Ajpo7TQqCllKwRiEs5ZLAoylFqwZPFAjayAOtCoiobgopoEADlBsAhm4GhQJAt52DCYzGk0YiwCESIQKgg40LAvbkEReCaLISBkRRdTUbRd5vGCFzsXYbL3hadbqD6KZ7D654hFQNqhAGYCxDUhhiJR1HGDugb+JYTT6t4mHCbhXhwb6mF2jhbxoRh0zGShkx8ZM8l5j4GLGBpbz4bY7S5PkYTdLSnnGMABnwOQnYiOhUBBSEwQ4BcTKMjZdhugA8teChQTgSAXpFTx2fUcn6AptgRRBxj+PgSAwAozneG6ACy+CfmFygyLIv

barneycarroll

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.

barneycarroll

const BornToDie = v => {
  let 
    born = true,
    to   = false,
    die  = false,
  
  let query
  
  let draw
  

barneycarroll

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)

barneycarroll

const broken = (promise, state = {
  pending:  true,
  settled:  false,
  
  resolved: false,
  rejected: false,
  
  value: undefined,
  error: undefined,
}) => (

barneycarroll

Written to avoid the noisome pattern of

input => {
  const reference = expression with input

  sideEffects(reference)

  return reference 
}

barneycarroll

const {assign, keys} = Object
const scope = fn => 
  function(){
    return fn(x => x.apply(this, arguments))
  }

const compose = (key, values) => (
    key === 'view'
  ?
    values.pop()

barneycarroll

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

barneycarroll

export const {
  view: v => (
      v.attrs.view 
    ? 
      v.attrs.view.call(v.state, v)
    :
      v.children
  )
}

barneycarroll

const callOBR = v =>
  Promise.all(
    ['tag', 'attrs']
      .map(x => 
           v[x] 
        && v[x].onbeforeremove 
        && v[x].onbeforeremove.call(v.state, v)
      )
  )