Compose-able and Extendable ViewModels

[HallM]

Could be a great idea for a ViewModel to compose or extend another ViewModel. Would remove the need for the "layout" field. As such, some ViewModels may not have a route. Their fetchers would not be directly executed, but instead executed by other ViewModel fetchers.

Extendable:

• Extending from another VM is much like extending in Dust or Swig. Start with a "layout" and add more to it.
• Parent components would need to have a this.props.children to render the children views.

Compose-able:

• Including a sub-view and rendering it in a specific spot. Maybe it creates/grabs the React component tag and allows it for use within the React component? The important part is being able to run the fetcher.

Multi??:

• Could more than one VM be created and sent to a layout for rendering as an array of children?

[HallM]

Potential API:

'use strict';

var Bluebird = require('bluebird');

var layout = ViewModel({
  // no url, page title, just the view
  // this isn't a page we access, it's something we extend/include

  view: {
    file: require('../views/Layout')
    // props default to the thing returned from the Promise in the fetch()
  },
  fetch: function() {
    // fetch maybe like header, or sidebar, footer, whatever stuff
    return Bluebird.resolve({header: 'I am header', sidebar: 'action item', footer: 'something statically dynamic!'});
  }
});

var reuseable = ViewModel({
  // same thing. no page title or url things if not a full page

  view: {
    file: require('../views/Reusable'),
  },
  fetch: function() {
    return Bluebird.resolve({foo: 'bar'});
  }
});

var subpage = ViewModel({
  // but, it could be a full page as a subpage too!
  url: '/mypage',
  pageTitle: 'Hello page!',

  view: {
    file: require('../views/Subpage'),
  }
});

ViewModel({
  extend: layout,
  url: '/',
  pageTitle: 'Hello world!',

  view: {
    file: require('../views/Hello'),
    props: {world: 'world(default)'}
  }
});

ViewModel({
  extend: layout, // extend may not be the best word. "parent" may be more appropriate to describe, but eh
  include: [reuseable, subpage], // array, so we can have many children. could be not array for just one thing.

  url: '/secondPage',
  pageTitle: 'The ultimate page',

  view: {
    file: require('../views/Page2')
  },
  fetch: function() {
    return Bluebird.resolve({hello: 'world'});
  }
});

Subpages with children/includes and parent/extended-from may need to bring those along too. But maybe there's situations a user doesn't want to.

[HallM]

Just to add some more notes/thoughts:

• Putting the layout info in the render part (example below) is not ideal as change pages causes the entire React-DOM to be checked even when the same Layout is used. React would minimize DOM changes, but it still has more work to do if we don't narrow the scope.

render() {
  return (
    <MyLayout>
      <div>my stuff</div>
    </MyLayout>
  );
}

• Extending React components by adding our own properties or methods is not ideal as it makes it more difficult to support other view layers in the future and increases possibility of breakage during a major React version change.
• Requiring ViewModels from within React views I'm hesitant on as it creates a circle of dependencies where ViewModels rely on Views which rely on ViewModels just feels wrong. Also doesn't work when it comes to many other template engines such as handlebars, mustache, dust, swig, and more.
• Avoid any situation where a single update could require updating both the ViewModel and the View.