reposoft / collection-subset

Collection Subset

Here's how it goes:

1. You value Backbone because it gives you a model layer with business logic.
2. Your UI is rendered from this whole master model.
3. But in fact your widgets tend to be concerned with only parts of the data (your app isn't "todomvc").
4. Look around and thre's if statements scattered around your views to disregard some models.
5. Switch your Backbone.Collection:s for Subset's CollectionB instead.
6. Later if you drift away from Backbone's View+Router stuff try to switch to Collection and bmc instead.
7. What you got is a data structure lib that can continue to back you app through UI generations.

Summary:

Subsets Support Views, on a need-to-know basis.

We want Backbone style Collections, with change events. While single-model (view+controller)s are trivial to maintain, we need some layer between the collection and multi-model (view+controller)s. Otherwise they tend to listen to events just to add to their own internal collection that's effectively a subset. They would have an informal relation between this subset's definition and the attributes they add to new models in order for them to match the subset.

We also want better control (than in Backbone) of ordering. And for other views to deal with the same data in sync we want re-order events. A way to do that is through linked-list style references between models, but we've found that to be a leaky abstraction to simplify persistence.

Use cases follow.

Authoring

Subsets can be used to author on a particular section, i.e. under a headline.

Assuming this is a level-2 heandline, there are level-3 headlines below, that we can manage in two ways:

• Keep paragraphs strictly ordered
  • with the headlines in between as title paragraphs
  • or with a reference to the section id in paragraph models
• Keep additional subsets as sub-sections

collection-subset's Issues

Add before-add event

Use cases:

• Generic validation (not backbone's built in one)
• immerse impl

Define transactions and templating data models

Most templating libs run on plain arrays of attribute hashes. That's what you get with toJSON, but with two way data-binding you might get updates to the data with no change events.

Also frequently when using Backbone I often want to delay some change events until all changes imposed by the current operation have been carried out. In composable logic it tends to be impractical to collect a single object with all attribute changes before calling set. For that it would be useful to sort of begin and end transactions on the collectoion.

Maybe these two use cases can be combined.

Expose filter factories through collection

So collections can be passed around without every consumer having to requirecollection-subset

Establish convention on the var name to `require` to

Feels a bit awkward now

Backbone wraps models resulting in model.attributes.attributes

This stuff in backbone 1.1.2 has changed in current master:

      // Turn bare objects into model references, and prevent invalid models
      // from being added.
      for (i = 0, l = models.length; i < l; i++) {
        attrs = models[i] || {};
        if (attrs instanceof Model) {
          id = model = attrs;
        } else {
          id = attrs[targetModel.prototype.idAttribute || 'id'];
        }
``
Using instanceof is quite problematic in a modular application because you need to know that the model and the collection comes from the same source file. See https://github.com/Reposoft/collection-subset/commit/4d2aaac8dc7f3027938f0a95f7b3c716926e06cc

Backbone requires jquery dependency

At downstream require of 0.2.1 you get a missing jquery dependency inside node_modules/collection-subset. You can add it manually, but it's huge so we'd ideally get rid of it instead of adding to package.json. We want to use Backbone just for data structures, and downstream can import a full Backbone.