4 ms·
Funny, we've been doing this with a modified-Backbone.js site and have found it requires tedious, manual management of an excess of IDs and classes, plus an err
by snprbob86 15y ago
Funny, we've been doing this with a modified-Backbone.js site and have found it requires tedious, manual management of an excess of IDs and classes, plus an error-prone mountain of jQuery expressions.
What I'd really like to do is go 100% the other way: all functions, all the time.
A view could just be a named function, accepting the object(s) to be rendered as arguments, define some closures for callbacks/event handlers, then return a DOM structure.
- Animus7 15y agoI've been doing exactly that in my more recent projects, and it works extremely well for simpler views/shallow DOMS. But it turns into write-only code pretty fast when you have tons of callbacks flying around for highly interactive elements.
- snprbob86 15y agoFor one-off actions, like the "save" and "cancel" buttons, callbacks don't descend into madness. Most UIs have very few commands which need true event handling. And the ones that do, the commands are often pretty simple one-button -> one-command. Sometimes many-buttons -> parameterized-command. For everything else, you can use data-binding. If you're already writing lexically scoped render functions, you can trivially create a data-bindable local object in a variable to eliminate the event management process. Instead of an onclick event for a checkbox, you can trivially set the checked property to be equal to an observable value box containing a boolean. With the right abstractions, callback spaghetti is not an issue.