Color Chooser Illustrates ViewModel Hierarchy Questions

Thank you, @justinbmeyer. To answer your question, I would be honored to present this Color Picker at DoneJS Chicago.

As you can tell from prior messages, I’ve been struggling with CanJS view inheritance. My concern was to avoid iterating through the entire <ul> every time a <li> event occurred. I kept trying to manage click and hover events at the <li> level, but it seems a CanJS-coded event handler only operates at its view level.

Perhaps I have stumbled upon the purpose of the virtual DOM: my code need not manage DOM event listeners but rather should rely on CanJS to intelligently update them. Am I on the right track?


Another issue: each element in your <ul class=final-colors> appears in Chrome DevTools’ Elements panel as:

<li on:click="selectFinalColor(color)"...>

yet is sending your selectFinalColor(color) method color values specific to that <li>.

How this works is far from obvious. In pure JavaScript it simply fails and a function called via onclick generates an Uncaught ReferenceError: color is not defined. I’m assuming this is because parameters to onclick must be values, not references.

Adding a debugger statement to your selectFinalColor(color) method causes DevTools to reveal in its Sources panel that in your Color Picker, color is an object enclosing a property for each of the <li>'s three colors.

I didn’t expect that and am beginning to understand how much CanJS does “behind the scenes.” Apparently once we create an object (color here), it can be passed back and forth between views and methods, and even revised “declaratively” by changing one of its dependencies (which you’ve stacked up here as this.baseColor || this.suggestedBaseColor || this.lastBaseColor) and CanJS synchronizes all side effects for me.

If the above is correct, I’m impressed by the power of it, but also concerned: how do I predict what CanJS will and will not manage “behind the scenes?” How is this object-passing capability described formally?

Example taken. Pointers appreciated.


Addendum:
Dear @justinbmeyer, I cannot help but notice a performance problem with your example. When dragging my mouse back and forth over the top row of colors (<ul class ='base-colors'), updates to the final-colors grid are notably slow. Chrome DevTools attributes this jank to Scripting:
image
There are also complaints in Chrome’s console:
19:47:58.043 core.js:18161 [Violation] 'mouseenter' handler took 237ms
19:47:58.307 core.js:18161 [Violation] 'mouseenter' handler took 226ms
...

The same test with http://vue-colors.code-read.com/ shows no such jank or console “Violations” and its performance report looks like:
image

Even my CanJS example runs much more smoothly.

Frankly, I’m stumped as to what is causing this. I found using //unpkg.com/can/core.min.mjs increased performance of your code significantly but still not on par with the other examples above. This is not what I expected. Why does my amateur code (and even my evil Vue script) outperform your far more elegant example?