Quantcast
Channel: Ember.JS - Latest topics
Viewing all articles
Browse latest Browse all 4828

Extensible className additions

$
0
0

@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 as component-x gets internal requirements for qualifying its root node with classes, the classy 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 invoking this._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? :smiley:

Posts: 2

Participants: 1

Read full topic


Viewing all articles
Browse latest Browse all 4828

Trending Articles