Add setFilter and removeFilter

[cmaher]

Following up on #2261, I see a very common use case being: change your filter, and render with that new filter. To that end, I am proposing a setFilter/removeFilter pair. They would behave as follows:

---

To change the filter and re-render the collection view, call setFilter with the new filter function.
setFilter will not cause the view to render if

• the view has not yet been rendered
• the view has been destroyed
• the new filter is the same as the existing filter
• { preventRender: true } is passed in the options

To remove the filter, use removeFilter, which accepts the same options
as setFilter and will cause a re-render under the same conditions.

  var cv = new Marionette.CollectionView({
    childView: SomeChildView,
    emptyView: SomeEmptyView,
    collection: new Backbone.Collection([
      { value: 1 },
      { value: 2 },
      { value: 3 },
      { value: 4 }
    ]),

    // Only show views with even values
    filter: function (child, index, collection) {
      return child.get('value') % 2 === 0;
    }
  });

  // renders the views with values '2' and '4'
  cv.render();

  // removes the filter, re-renders and shows all views
  cv.removeFilter();

  // re-renders the collection view, showing the views with values '1' and '3'
  cv.setFilter(function (child, index, collection) {
    return child.get('value') % 2 !== 0;
  });

  // removes the filter, but does not re-render
  cv.removeFilter({ preventRender: false });

  // shows all views, using the new filter
  cv.render();

  // re-renders the collection view, showing the empty view
  cv.setFilter(function (child, index, collection) { return false; });

  // updates the filter, but does not re-render
  cv.setFilter(function (child, index, collection) { return true; }, { preventRender: true });

  // shows all views, using the new filter
  cv.render();

So why use setFilter instead of manually calling render? I see this as a classic case of wanting to do something whenever you change a value, which is the exact use case of a setter. It's also easily overridable in case the users don't want this behavior (and it's entirely opt-in and thus BC).

I'm also explicitly avoiding Object.defineProperty setters to maintain compatibility with IE8 and because that could result in difficult-to-customize behavior. It might not be modern semantic JS, but I think it's the best way to handle this behavior in the present.

[ianmstew]

Hey guys, any issue moving this one into 2.5 considering #2592 is targeting 2.5 already? @ahumphreys87

[ahumphreys87]

yeah sounds good @ianmstew

[paulfalgout]

Looks like this was merged by @ahumphreys87