allow lookups of subview creators to be a function call about backbone.subviews HOT 8 CLOSED

Not entirely clear on use case here or what is being proposed. Feel free to elaborate or open a PR to clarify. No guarantees though... note subviewCreators can be a function already. Thanks!

from backbone.subviews.

I want to have different data- attributes indicate different things. the data-subview attribute is being used for three things right now: determining which placeholders to swap out, identifying the view name for indexing and replacement (sweet setup, by the way) after re-render of the parent, and also for lookup of the creator function.

In the following snippet, I have factored the pre-existing code & policy with a data-extraction strategy. This strategy is easily replaced with a different strategy - perhaps one that uses data-subview as a view-class name, the id attribute for indexing/replacing the subview, and/or extracts any other interesting args for the subview instance. In this alternative strategy, there need not be any subviewCreators entry, if a single function can effectively initialize the subview indicated by the placeholder.

I've been browsing past closed issues, and I understand that I'm pushing 3 things at once that all seem counter to your methods of keeping this module simple. Still, here goes.

  // [in add(view, strategy):]
  view.subviewStrategy = strategy || extractSubviewOptionsFromEl;
  // ...
  function extractSubviewOptionsFromEl($el) { // default strategy
    var subviewName = $el.attr( "data-subview" );
    return {
      id: subviewName,
      creator: this.subviewCreators[ subviewName ]
    }
  }
  // ...
  var opts = _this.subviewStrategy(thisPlaceHolderDiv); // lookup options from the div
  var subviewId = opts.id;                     // extract the details from the options
  var subviewCreator = opts.creator;
  var newSubview;
  if( _.isUndefined( _this.subviews[ subviewId ] ) ) {
    // if the subview is not yet defined, then create it now using
    // the registered creator method in this.subviewCreators.
    if( _.isUndefined( subviewCreator ) ) throw new Error( "Can not find subview creator for subview identified as: " + subviewId );
    // this now allows the generic options extracted to be used by the subviewCreator, which 
    // can now be a generic factory.  
    newSubview = subviewCreator.apply( _this, [opts] );  // send all the options provided by the strategy, in case they're useful to the creator function

from backbone.subviews.

This strategy does as I described above, using id= for indexing sub-views, using data-subview as a class name, and other data- entries as options sent to the constructor of the subview class. Poof, no subviewCreators hash is needed.

  function extractSubviewOptionsFromEl($el) {
    var subviewClassName = $el.data( "subview" );
    var subviewClass = jsonPath( window, subviewClassName )[0];
    if (!subviewClass) {
      console.error("Unknown subview class: "+ subviewClassName, $el)
      return null
    }
    return _.extend({
      id: $el.attr( "id" ),
      creator: function(options) { return new subviewClass(options) }
    }, $el.data());
  }

from backbone.subviews.

Hard coding options into the element itself is not possible when options are dynamic or can not be encoded as attributes in the DOM, so this particular strategy is not as flexible as the default one. Also I am of the opinion that the place holder div should be just that, a place holder div. See #12. However if you like this strategy, I don't want to hold you back.

One thing we could do is factor out a _createSubview( subviewName ) method that you could then override for your purposes, defaulting to

https://github.com/rotundasoftware/backbone.subviews/blob/master/backbone.subviews.js#L90-L94

from backbone.subviews.

createSubview(subviewName) is very close along the lines of the original topic heading. I wouldn't prefix it if it's part of the API

I do prefer the flexibility offered by giving the developer access to the DOM node. Recognizing that this strategy-based approach allows the developer to substitute any actual function for instantiating a subview based on any information provided in $("[data-subview]"), I think it should be clear that the flexibility is only increased, though not without some costs.

from backbone.subviews.

Thanks for the good conversation, David. I feel like contextual sub-view creation is a big missing piece of creating user interfaces with Backbone that have flexibility and reusability built-in, so it's really super cool that there's a straightforward plugin for the purpose.

from backbone.subviews.

k just created this feature branch to explore this option

from backbone.subviews.

Alright @rjharmon this branch was just merged to master. Happy coding!

from backbone.subviews.