preact-state-brainstorm.js

// set, update, remove

// Functions to mutate global state. No need for `dispatch`.
// Since there would only be these functions and no more dispatch,
// there would be no need for reducers.
set('items', [1, 2, 3]) // [1, 2, 3]
update(['items', 1], 'a') // [1, 'a', 3]


// batch(set, update, remove, ...)

// A utility to batch any number of set, update, remove calls
// so that any subscribers are only called after all passed in mutations
batch(set('url', '/cool/path'), set('loading', false))


// subscribe

// combination of atom.subscribe and the watchStore util functions.
// if only a callback is provided to subscribe then it will be called 
// after *any* mutation. 
subscribe((state, oldState) => console.log('state changed', state, oldState))

// If an array is given as the 1st param then the 
// given callback (2nd param) is only called if the array path on the 
// state has actually changed.
subscribe(['forms', 'search'], ...)

// Idea: if multiple functions are provided (with or without an array as
// the first param), they will be piped. For me, piping is such a common
// pattern, it would be nice not to have to import another util function
// to wrap my dumb components.
export const ResultsComponent = subscribe(['formResults', 'search'], normalizeSearchResults, ResultsComponentBase)

// Now that we have a util similar to redux-connect. We don't have to
// follow the pattern of a single `Main` component that syncs the global
// state and passes it down to child components in a Router. Main, or Router
// can just subscribe to 'url' and the page components and their children
// can specify parts of the state they want to subscribe to.


// example file structure

// base.js
const SomeComp = ({coolProp}) =>
  <div>{coolProp}</div>

// index.js
import SomComp from './base'

export default subscribe(['data', 'coolProp'], SomComp)

test.js

import test from 'ava'

import atom from 'atom'

const {
  set,
  update,
  remove,
  batch,
  subscribe,
  unsubscribe,
  getState
} = atom({
  coolProp: {a: 'Very cool'},
  num: 1,
  items: [1, 2, 3]
})

test('subscribe', (t) => {
})

test('unsubscribe', (t) => {
})

test('set', (t) => {
})

test('update', (t) => {
})

test('remove', (t) => {
})

test('batch', (t) => {
})

The main issue I can think of that this pattern will introduce is race conditions: If you have two or more components subscribed to the same state path, and there is a need for their re-rendering to be ordered.