Transition hook for Mobile Unit

[barneycarroll]

Mobile Unit could be extended with a transition hook that stretched over the period before and after DOM movement to control the transition.

A generator would be useful for yielding to the point of movement and resuming thereafter. Here follows pseudo-code example tweening the element between its initial & eventual positions:

const fixed = {position: 'fixed'}

m(Unit, {
  *transition({dom, move}){
    const initial  = dom.getBoundingClientRect()
  
    yield move 
    // dom is now in its new position
  
    const eventual = dom.getBoundingClientRect()
  
    dom.animate([
      {…fixed, initial },
      {…fixed, eventual},
    ], options)
  }
},
  m(Video)
)

🤔

[barneycarroll]

Jotted down some tentative thoughts for an idiom of ‘transition layout’ components in the Mithril chatroom.

With regard to ‘document transitions’, and in the context of a Mithril SPA, we’d have all route endpoints resolve to the same reference, whose view would persist across the entire application lifecycle. This ‘transition layout’ would instantiate the Mobile controller for all Units that desire to persist between different pages.

In the case of the example application demonstrated in Googles recent page transitions presentation, the prime example is a video component: there is a video whose UI view model we want to persist between different pages. On a very basic level, we want the user to be visually aware of that particular video which occupies the major part of the layout on page 2, being the same video they presumably clicked on from several in a list displayed on page 1. The page layout will change drastically, and the videos position within it, but according to the users mental model it is the same video. Mobile Unit allows us to structure our view model such that this identity persists; we can keep all component state & the video element itself and move them from one structure to another, even as the old is structure is destroyed and the new created — the *transition API allows us to hook into the moment of movement & describe the transition as we see fit to represent it adequately to the user.

[barneycarroll]

The ‘transition layout’ acts as a conceptual amalgamation of concerns here: in a simple 2 page application it would not be too difficult to conceive of a single component containing the logical expressions which determine whether the same identifiable Unit ought to be rendered as part of structure 1 (the list) or structure 2 (the single-video page).

This cuts across Mithrils canonical route idiom whereby different pages are defined with different endpoints before any common view expressions can be described. Nonetheless, we can invert and later revert the order of control such that routing concerns are forked within the Mobile expression, and the controlled Unit reference is thereby able to be passed in to externally-defined, route-specific components: the author can then stick with the more familiar idiom of distinct view expressions for distinct pages, while still keeping the persistent references necessary to keep state & DOM live & transitionable despite their distinct positions being described in different execution contexts …