DOMClass VS Knockout

This page replicates Knockout examples via DOMClass components.

Each example explains main differences between original code [↗] and the one used here.

Feel free to check the source code of this page to actually see that WYSIWYG.

Please bear in mind that DOMClass is a Web Components like abstraction, which is very different as paradigm to Knockout one. Also please remember not a single piece of DOMClass code has been evaluated and also there are no repeaters in the templates. It's a simplified way to create components which are nice and clean and don't need model definitions on the wild but just a class definition to possibly never even interact with directly but through events.

Hello World [↗]

Main difference is that DOMClass one changes in real time and not only on change event.

First name:

Last name:

Hello, {{join(firstName, lastName)}}!

Click counter [↗]

Main difference is that we use standard events when we need them. This gives us the ability to also drop them eventually in some edge case we might encounter.

You've clicked {{clicks}} times
That's too many clicks! Please stop before you wear out your fingers.

Simple list [↗]

The main difference is that DOMClass doesn't have auto-magic behaviors. The bound options, as example, will be exactly the select.options and instead of using this.items.push(value) we expose a proper addItem method.

Another important difference is the ability to pass constructor arguments as JSON Array and through the data-arguments property. This makes the component usable as pre-rendered HTML, or as simple JS created one: body.append(new SimpleList('a','b'))

New item:

Your items:

Better list [↗]

Same differences described in the simple list plus some extra logic for sorting and removing. Once again, there's no auto-magic behaviors in DOMClass, neither code evaluation. We need to define what happens by ourselves and here that's defined in the handleEvent.

Add item:

Your values:

Control types [↗]

The main difference is that in DOMClass you can invoke methods but you need to specify per which property such method should be invoked.

Please note this is a very demo-ish exercise and the crossed representation of the same binding in multiple place is not an ideal scenario to define with current bindings logic but also ... hey, it works ;-)

For the first time in this page we use direct methods bindings too so that onchange:method will invoke bindings.method(event) once it changes.

Again, this is a demo, so here I am showing off some bindings features but in a component like approach we could just use addEventListener and update bindings once triggered.

What's in the model?

Text value: {{stringValue}}
Password: {{passwordValue}}
Bool value: {{getBoolTxt(booleanValue)}}
Selected option: {{getSingleSelectValue(selectedIndex)}}
Multi-selected options: {{getMultipleSelectValue(selectedOptions)}}
Radio button selection: {{getRadio(radioAlpha,radioBeta,radioGamma)}}

HTML controls

Text value (updates on change):
Text value (updates on keystroke):
Text value (multi-line):
Password:
Checkbox:
Drop-down list:
Multi-select drop-down list:
Radio buttons:

Working with Collections [↗]

Main difference in this example is that DOMClass does not use eval or Function so it's more procedural.

Also there are no repeaters in the template, because there are no nested bindings yet.

The component is split in 3: the main container, its generic Person and eventually children through the Child component.