@barneycarroll wrote:
The application I'm working on depends upon DOM layout considerations which demand given parent nodes to qualify child components' root nodes with classNames. This mixin has made my life easy for a while:
// classy.js import Ember from 'ember'; // External context often defines the requirements of the wrapping element // Enable generic component root customisation through passed in properties export default Ember.Mixin.create( { classNameBindings : [ 'classNameProperty' ], classNameProperty : Ember.computed( 'class', className ) } );
It is now possible to invoke things like this:
// component-x.js import Ember from 'ember'; import classy from '../lib/classy'; export default Ember.Component.extend( classy );
<div class="grid column"> {{component-x class="grid__item"}} </div>
This has been serving me well. The handlebars templates read nicely, I minimise DOM cruft and end up with an idiomatic flexible layout. The problem is that, despite the adorable signature of the
classNameBindings
API — namely an array of strings which are evaluated for one of Ember's several internal logic-as-a-string DSLs —classNameBindings
is not extensible. As cool as arrays of custom logic-syntax string DSLs are, they're still just static properties which defy inheritance & composition. Therefore as soon ascomponent-x
gets internal requirements for qualifying its root node with classes, theclassy
mixin behaviour is silently lost.If we had such a thing as a
classNameBind
method, which performed arbitrary logic and returned a string, then we could rely on invokingthis._super
to ensure any extension was non-destructive. However I'm having difficulty figuring out how this would integrate with observability concerns etc.Any ideas?
Posts: 2
Participants: 1