asutherland / glodastrophe

…flexbox

The hackish integration of redux and gelam's view slice and per-item serial
tracking now works reasonably happily.

Layout-wise:

It's clear I need a freshly awake brain for this, but in the interest of
saving awake-me some trouble, or at least giving awake-me something to
laugh at, here are various things I tried:

The eternal desire to enforce xul-style border-layout-esque things where
we don't hardcode the sizes of the things on the periphery once again
loses out.  I sleepily tried various hacks to interpose "position: relative"
boxes so that react-split-pane's use of "height: 100%" would not net out to
a height greater than 100%, but that tended to either take the box out of
the flow or run into the problem where the constraints were not being
propagated.

I also tried hacking react-split-pane to reduce its dependencies on using
100% but that tended to not cause the area we want to scroll to become
scrolling and instead grew the whole document.  This all very much suggests
I need to refresh my understanding of the flexbox layout model.

Some other npm packages were briefly investigated, but none seemed like a clear
win.  The most promising seemed to be trying to do more of the layout logic
itself.  And while in frustration I could see agreeing with that, it does seem
preferable to instead come back up to speed on flexbox.

…lanned

We've been using two mechanisms to trigger update of React components based on
events from GELAM:

1. EntireList and WindowedList pass the `serial` of the view and the items into
   their ReactList and the widget items as props.  This works with
   PureRenderMixin, but for evolutionary reasons we ended up with
   slice_item_mixin.js that can be replaced by PureRenderMixin or equivalent.

2. The header items use live_item_mixin that attempts to do a similar thing
   inside a component itself by adding a `change` listener and updating the
   state whenever anything changes.

Since mix-ins are only viable using React.createClass() and that's
idiomatically on the way out, our options are basically:

- higher-order-component like react-redux's connect() or react-intl's
  (connect-inspired) injectIntl().  These basically interpose an
  additional widget that declares a `contextTypes` entry and propagates all
  of the props they receives plus the extras they add from the context.

- Have our "viewing" reducer expose the serial numbers/similar values as
  explicit state inside the redux store that works with PureRenderMixin-style
  logic.  So `conversation` might also have a sibling `conversationSerial`
  and `conversationsView` might also have `conversationsViewMetaSerial` for
  consumers that care about the tocMeta for the view.  This does also require
  that the reducer registers for events and dispatches actions against itself.

- Keep doing the mix-in type thing with state, but somehow with a decorator.

- Have the components explicitly do what the mix-in does inside of themselves.

Right now, I am heavily leaning towards having the reducers expose the serial
numbers into the redux state.  The use of sibling values seems a little hacky,
but tupling the view with its serial in a new encapsulating object to effect
the change from an === perspective doesn't seem any cleaner.  Additionally, the
use of sibling values does allow the inherent view serial to be decoupled from
the tocMeta serial that we can create.  This matters in the case of headers
versus lists where the headers probably only care about the tocMeta and the
lists only care about the items.

One nice positive is that we get to work within the redux connect() idiom and
avoid having to add any other interposing widgets.  Plus the serial change is
made visible in the state which hopefully is more intuitive than mix-ins
maintaining their own state machines inside the components.  A downside to this
is that anyone wanting to play with redux devtools may be very disappointed
that we generate an incredible number of internal dispatches that exist only to
trigger updates and exist on top of underlying mutable state.  So if they try
and do any time travelling, they'll find that most travelling results in no
visible changes unless the state changes were actually due to user-initiated
interaction.  Perhaps there's some way we can tag automatic actions versus
user-initiated to assist such devtools?