Provide first class support for showing/hiding elements

[kevindente]

It's very common to show/hide UI elements based on properties of a model (especially common - a boolean value that maps to visible/hidden). You can currently do by binding class names with a formatter, but it's kind of clunky. It would be nice if there was first class support for controlling element visibility in stickit.

[delambo]

@kevindente I can see the use for this. Any ideas on how this could be configured in the api?

Possibly toggle (best thing that came to my mind):

// Configuration for model attributes that contain truthy values.
'#header': {
  modelAttr: 'header',
  toggle: true
}
// Overloaded with a callback, which should return a truthy value to toggle.
'#header': {
  modelAttr: 'header',
  toggle: function(modelVal, elVal, attrName) { return true; }
}

[kevindente]

Hmm, I'm not totally sure what "toggle" represents in your sample. Does that equate to "visible"? And does the value determining visibility come from the modelAttr header in that case (ie model.get('header') == true means visible, model.get('header') == false means invisible)? Or is visibility determined solely by the function return value, and independent of the property value?

Actually, I'm unclear on this for readonly property as well (which I assume this is modeled after). The {param: true} setup is a tad confusing.

[delambo]

model.get('header') == true means visible

Yeah, that is what I was going for in the first configuration style. When toggle is true, then toggling would be turned on for the element based on the model attribute's boolean value. Maybe toggle isn't the best name (?).

Or is visibility determined solely by the function return value, and independent of the property value?

The second example configuration is an overloaded value type for when the model attribute does not have a boolean value. In that case, when the model attribute is changed, the callback return value, true or false, will dictate whether it is shown or hidden.

Make sense? Any suggestions/changes?

FYI, readonly has been deprecated from the api (on master) - element properties can now be bound in the attributes configuration.

[kevindente]

OK, makes sense. I agree that toggle isn't the best name. It makes sense from a jQuery perspective, but isn't that obvious when you just read the bindings. Perhaps just "visible" would be better.

BTW is there a way you'd be able to inject a transition animation into the showing and hiding (like making it collapse up instead of just disappearing)?

[delambo]

@kevindente Starting to look into this now. I've settled on visible.

What were your ideas for injecting a transition animation? The cleanest and most flexible solution is to supply an extra callback which passes back the $el, which the user can use to manually animate a transition, but I'm not sure if that is a big win. Something like the following:

bindings: {
  '#header': {
    modelAttr: 'header',
    visible: true,
    visibleFn: 'fadeFast'
  }
},
fadeFast: function($el, attrVal, attrName) {
  if (attrVal) $el.fadeIn('fast');
  else $el.fadeOut('fast');
}

[kevindente]

Hmm, maybe supporting arbitrary transitions is more than this needs. Seems like there isn't much difference between your visibleFn example and the afterUpdate function, and providing 2 ways to do the same thing probably doesn't make sense.

What about just providing a path for passing through the standard parameters to jQuery's toggle/show/hide functions - duration, easing, and maybe callback?

[delambo]

The visibleFn would be necessary in this case because visible is a special binding that does not actually update the dom value, just toggles it, right?

The problem with configuring jQuery parameters for show/hide is that it doesn't cover enough ground and that you would need both show and hide option configurations. What if I wanted to use slideDown and slideUp or some other combination of UI animations? I think a single callback, like visibleFn should be enough. A function like fadeFast could get complex depending on the project requirements, and could easily be tucked into Backbone.View.prototype as a mixin.

[kevindente]

Ah, OK, I see what you're saying. afterUpdate fires after the DOM is updated, but visibleFn would fire after the model value changes (and then would enact the DOM change).

I'm not totally convinced that passing through show/hide params wouldn't be helpful, even if it's just a single set for both show and hide (I think it would be pretty common for the duration and easing to be symmetrical for show/hide). But that's something that could easily be added later if other people request it.

[delambo]

This is on master - I'll cut a tag soon. Thanks for the help @kevindente

[kevindente]

Awesome! Thanks!