@webqit/oohtml 3.0.1-7 → 3.0.1-9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +65 -5
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -593,12 +593,42 @@ Here, we get a comment-based data-binding tag `<?{ }?>` which works like regular
|
|
|
593
593
|
<title><?{ app.title }?></title>
|
|
594
594
|
</head>
|
|
595
595
|
<body>
|
|
596
|
-
Hi, I'm <?{
|
|
597
|
-
and here's another way to write the same comment: <!--?{
|
|
596
|
+
Hi, I'm <?{ name ?? 'Default name' }?>!
|
|
597
|
+
and here's another way to write the same comment: <!--?{ cool }?-->
|
|
598
598
|
</body>
|
|
599
599
|
</html>
|
|
600
600
|
```
|
|
601
601
|
|
|
602
|
+
<details><summary>Details</summary>
|
|
603
|
+
|
|
604
|
+
Here, JavaScript references are resolved from the closest node up the document hierarchy that exposes a corresponding *binding* on its Bindings API ([discussed below](#bindings-api)). Thus, the above markup could have an underlying data structure like the below:
|
|
605
|
+
|
|
606
|
+
```js
|
|
607
|
+
document.bind({ name: 'James Boye', cool: '100%', app: { title: 'Demo App' } });
|
|
608
|
+
document.body.bind({ name: 'John Doe' });
|
|
609
|
+
```
|
|
610
|
+
|
|
611
|
+
```js
|
|
612
|
+
document: { name: 'James Boye', cool: '100%', app: { title: 'Demo App' } }
|
|
613
|
+
└── html
|
|
614
|
+
├── head
|
|
615
|
+
└── body: { name: 'John Doe' }
|
|
616
|
+
```
|
|
617
|
+
|
|
618
|
+
So, above, the `name` reference remains bound to the `name` *binding* on the `<body>` element until the meaning of "closest node" changes again:
|
|
619
|
+
|
|
620
|
+
```js
|
|
621
|
+
delete document.body.bindings.name;
|
|
622
|
+
```
|
|
623
|
+
|
|
624
|
+
While the `cool` reference remains bound to the `cool` *binding* on the `document` node until the meaning of "closest node" changes again:
|
|
625
|
+
|
|
626
|
+
```js
|
|
627
|
+
document.body.bindings.cool = '200%';
|
|
628
|
+
```
|
|
629
|
+
|
|
630
|
+
</details>
|
|
631
|
+
|
|
602
632
|
<details><summary>With SSR Support</summary>
|
|
603
633
|
|
|
604
634
|
On the server, these data-binding tags would retain their place in the DOM while having their output rendered to their right in a text node.
|
|
@@ -647,7 +677,7 @@ Here, we get the `binding` attribute for a declarative and neat, key/value data-
|
|
|
647
677
|
|
|
648
678
|
| Directive | Type | Usage |
|
|
649
679
|
| :---- | :---- | :---- |
|
|
650
|
-
| `&` | CSS Property | `<div binding="& color:someColor; & backgroundColor:
|
|
680
|
+
| `&` | CSS Property | `<div binding="& color:someColor; & backgroundColor:someBgColor;"></div>` |
|
|
651
681
|
| `%` | Class Name | `<div binding="% active:app.isActive; % expanded:app.isExpanded;"></div>` |
|
|
652
682
|
| `~` | Attribute Name | `<a binding="~ href:person.profileUrl+'#bio'; ~ title:'Click me';"></a>` |
|
|
653
683
|
| | Boolean Attribute | `<a binding="~ ?required:formField.required; ~ ?aria-checked: formField.checked"></a>` |
|
|
@@ -676,15 +706,45 @@ Here, we get the `binding` attribute for a declarative and neat, key/value data-
|
|
|
676
706
|
|
|
677
707
|
</details>
|
|
678
708
|
|
|
709
|
+
<details><summary>Details</summary>
|
|
710
|
+
|
|
711
|
+
Here, JavaScript references are resolved from the closest node up the document hierarchy that exposes a corresponding *binding* on its Bindings API ([discussed below](#bindings-api)). Thus, the above CSS example code could have an underlying data structure like the below:
|
|
712
|
+
|
|
713
|
+
```js
|
|
714
|
+
document.bind({ someColor: 'green', someBgColor: 'yellow' });
|
|
715
|
+
document.body.bind({ someBgColor: 'silver' });
|
|
716
|
+
```
|
|
717
|
+
|
|
718
|
+
```js
|
|
719
|
+
document: { someColor: 'green', someBgColor: 'yellow' }
|
|
720
|
+
└── html
|
|
721
|
+
├── head
|
|
722
|
+
└── body: { someBgColor: 'silver' }
|
|
723
|
+
```
|
|
724
|
+
|
|
725
|
+
So, above, the `someBgColor` reference remains bound to the `someBgColor` *binding* on the `<body>` element until the meaning of "closest node" changes again:
|
|
726
|
+
|
|
727
|
+
```js
|
|
728
|
+
delete document.body.bindings.someBgColor;
|
|
729
|
+
```
|
|
730
|
+
|
|
731
|
+
While the `someColor` reference remains bound to the `someColor` *binding* on the `document` node until the meaning of "closest node" changes again:
|
|
732
|
+
|
|
733
|
+
```js
|
|
734
|
+
document.body.bindings.someColor = 'brown';
|
|
735
|
+
```
|
|
736
|
+
|
|
737
|
+
</details>
|
|
738
|
+
|
|
679
739
|
<details><summary>All in realtime</summary>
|
|
680
740
|
|
|
681
|
-
|
|
741
|
+
Bindings are resolved in realtime! And in fact, for lists, in-place mutations - additions and removals - on the *iteratee* are automatically reflected on the UI!
|
|
682
742
|
|
|
683
743
|
</details>
|
|
684
744
|
|
|
685
745
|
<details><summary>With SSR Support</summary>
|
|
686
746
|
|
|
687
|
-
|
|
747
|
+
For lists, generated item elements are automatically assigned a corresponding index with a `data-index` attribute! This helps in remapping generated item nodes to their respective entry in *iteratee* - universally.
|
|
688
748
|
|
|
689
749
|
</details>
|
|
690
750
|
|