Here’s a project I’ve been working on for the last weeks!
The idea came after having built many Ember apps, and realising that I was always using the same UI elements with some minor styling tweaks.
Ember Sparks is like a framework for building reusable UI components that can easily be installed as addons without having to include a separate SCSS-file, and themed without having to remember obscure, prefixed class names.
I keep feeling component libraries like ember-sparks is building abstraction at the wrong level.
Take, for example, the select component. In ember-spark, this is implemented as a dropdown. What if I need a button group? The underlying state management logic is the same: I’m selecting 1 or multiple items from a collection. The interaction can be a list, a dropdown list, a button group, a radio button group, a checkbox list, you name it.
This is why I really like the approach of ember-microstates. It uses helpers to abstract away the state management and leaves the rendering entirely up to you.
Thanks for the feedback! I don’t see why something like ember-microstates couldn’t work well with Ember Sparks though.
I agree that it’s cool to have helpers abstract away the state management and leave the rendering up to the user. Ember-microstates would then take care of the “state management” part, whereas Ember Sparks helps out with the “leave the rendering up to the user” part. You could then theoretically decide whether you want to use the “select-spark” or the “button-group-spark”, depending on the UI you want. The state management would still work in the same way.
yeah thats not bad at all. We are using ember-power-select for selects though. Everyone wants the search capability. However I like the simplicity of the components. I’m sure I’ll try them.
