4 ms·
It seems like this library is just a less well-thought out version of component/reactive[1]. It makes the mistake of jamming way too much logic into magicky str
by ianstormtaylor 13y ago
It seems like this library is just a less well-thought out version of component/reactive[1]. It makes the mistake of jamming way too much logic into magicky strings instead of using existing semantics to render things. For example, there's a
data-each
attribute for handling looping, but then instead of solving polymorphic children in the same way, with a
data-polymorphic="role"
attribute, it's solved with a weirdly hacky appending of "Polymorphic-" to a class name.
The same goes for the use of class names to begin with. Why rely on hacky parsing of class names that end in dashes, when you could just have
data-text="firstName"
and be done with it. That's the route reactive takes and it's much more flexible.
And then another piece of critique, the frequency that people actually use curly braces in their attribute names is so incredibly low that it is absolutely worth having a nicer syntax for interpolation by dropping the leading # to end up with
href="{interpolated}"
Not only that, but check out something like ianstormtaylor/get[2] to see how easy it could be to add support for backbone-like models alongside regular properties and terser, single-method models.
And finally, the API for creating a reactive instance is also much nicer in that you aren't relying on ever-present singletons that you have to tightly couple all of your modules to. Instead, you just get your template however you want, get your model however you want and call:
reactive(el, model);
Very clean.
Sorry if this comes off as harsh, I just think it's a shame that people using Backbone (or more frequently Angular) are constantly making poor API decisions for their plugins because they're exposed to so many poor API decisions in their core toolkit.
[1]: https://github.com/component/reactive https://github.com/component/reactive
[2]: https://github.com/ianstormtaylor/get https://github.com/ianstormtaylor/get
- devhinton 13y agoAgreed, thanks for the feedback, and, after having worked with end-dash I've come to a lot of the same conclusions you just made. The dashes were initially just to shorten the common: <div class="thing" data-text="thing"></div> to <div class="thing-"></div> Using dashes for polymorphic attributes was a bad idea, and is being removed, the data-each was recently added to replace a dashed syntax for collections. We're adding interpolated variables, so that the dash syntax will only be used for scoping. > Not only that, but check out something like ianstormtaylor/get[2] to see how easy it could be to add support for backbone-like models alongside regular properties and terser, single-method models. https://github.com/Amicus/end-dash/blob/master/lib/util.js#L67 https://github.com/Amicus/end-dash/blob/master/lib/util.js#L... This does exactly that. Thanks, from Amicus
- devhinton 13y agoOn further reflection, It is also true that reactive does not have any support for collections or scoping. Reactive seems to take a view-centric approach while EndDash takes a template-centric approach. To us, the later seems more logical, as HTML is the structure of any webpage. EndDash hooks into this structure and acts as an optimization so that HTML turns into a high level description of html/views/value interpolation. Thus defining a large template (with partials if needed) can be passed a single javascript model which is scoped down into. Passing models to views as needed. Again, thank you for the comment :) From Amicus.