There is a lot of stuff I did in famous-views which I felt I should have really happened at a lower level (maybe above engine, but definitely relevant for all integrations). One of those was jQuery style selectors. I think jQuery was such a big hit because it made working with DOM Nodes such a pleasure. It’s basic usage is also very familiar with - I think - a majority of developers.
In famous-views you can currently give Nodes a unique
id or any number of
class's and do stuff like:
FV(node)- get an fview instance of an existing ref
FV('#id')- get a specific node
FV('.class')- get all nodes with that class
FV('Node')- e.g. get all nodes (multiple selectors were planned for the future)
And then using chainable methods like
each(), you could do stuff like:
var deck = FV("#cardDeck"); deck.doSomethingCool(); // plugin architecture deck.children('.selected').bounceAnimation(); // Or the second part in one command FV('#cardDeck > .selected').bounceAnimation();
Very basic examples but I think everyone gets the idea. Just having functional methods for working around a tree is super helpful!
The only downside of course is that where possible, direct (non selector) methods are always preferable for performance. But of course, scene graph in JS is significantly faster than DOM and DOM selector queries. I think it’s a pattern that could help adoption with caveats mentioned in a “Performance Optimizations” post. And only relevant for building components, not for internal use.
cc: @peacechen, IjzerenHein