@webqit/oohtml 3.0.1-6 → 3.0.1-8
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 +68 -9
- 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
|
|
|
@@ -900,7 +960,7 @@ Observer.set(element, 'liveProperty'); // Live expressions rerun
|
|
|
900
960
|
|
|
901
961
|
## Polyfill
|
|
902
962
|
|
|
903
|
-
OOHTML is being developed as something to be used today
|
|
963
|
+
OOHTML is being developed as something to be used today—via a polyfill. This is an active and intentional effort that continues to ensure that the project evolves through a practice-driven process.
|
|
904
964
|
|
|
905
965
|
<details><summary>Load from a CDN<br>
|
|
906
966
|
└───────── <a href="https://bundlephobia.com/result?p=@webqit/oohtml"><img align="right" src="https://img.shields.io/bundlephobia/minzip/@webqit/oohtml?label=&style=flat&colorB=black"></a></summary>
|
|
@@ -1040,7 +1100,7 @@ If you'll be going ahead to build a real app to see OOHTML in action, you may wa
|
|
|
1040
1100
|
|
|
1041
1101
|
## Examples
|
|
1042
1102
|
|
|
1043
|
-
Here are a few examples in the wide range of use cases these features cover.
|
|
1103
|
+
Here are a few examples in the wide range of use cases these features cover. While we'll demonstrate the most basic forms of these scenarios, it takes roughly the same principles to build an intricate form and a highly interactive UI.
|
|
1044
1104
|
|
|
1045
1105
|
<details><summary>Example 1: <i>Single Page Application</i><br>
|
|
1046
1106
|
└───────── </summary>
|
|
@@ -1082,7 +1142,7 @@ The following is how something you could call a Single Page Application ([SPA](h
|
|
|
1082
1142
|
</template>
|
|
1083
1143
|
```
|
|
1084
1144
|
|
|
1085
|
-
**-->**
|
|
1145
|
+
**-->** *Then a 2-line router that alternates the view based on the URL hash*:
|
|
1086
1146
|
|
|
1087
1147
|
```html
|
|
1088
1148
|
<body importscontext="/pages/home">
|
|
@@ -1104,7 +1164,6 @@ The following is how something you could call a Single Page Application ([SPA](h
|
|
|
1104
1164
|
<details><summary>Example 2: <i>Multi-Level Namespacing</i><br>
|
|
1105
1165
|
└───────── </summary>
|
|
1106
1166
|
|
|
1107
|
-
|
|
1108
1167
|
The following is a Listbox component lifted directly from the [ARIA Authoring Practices Guide (APG)](https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-grouped/#sc_label) but with IDs effectively "contained" at different levels within the component using the `namespace` attribute.
|
|
1109
1168
|
|
|
1110
1169
|
```html
|