@webqit/webflo 0.11.14 → 0.11.17
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 +27 -14
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -385,6 +385,8 @@ export default function(event, context, next) {
|
|
|
385
385
|
}
|
|
386
386
|
```
|
|
387
387
|
|
|
388
|
+
This step-based workflow helps to decomplicate routing and gets us scaling horizontally as our application grows larger.
|
|
389
|
+
|
|
388
390
|
<details>
|
|
389
391
|
<summary>More details...</summary>
|
|
390
392
|
|
|
@@ -453,12 +455,9 @@ export default async function(event, context, next) {
|
|
|
453
455
|
}
|
|
454
456
|
```
|
|
455
457
|
</details>
|
|
456
|
-
|
|
457
458
|
</details>
|
|
458
459
|
|
|
459
|
-
|
|
460
|
-
|
|
461
|
-
Workflows may be designed with *wildcard* steps using a hyphen `-` as step name. At runtime, a wildcard step matches any URL segment at its level in the layout! A `this.stepname` property could be used to see which URL segment has been matched.
|
|
460
|
+
However, workflows may be designed with *wildcard* steps using a hyphen `-` as step name. At runtime, a wildcard step matches any URL segment at the given level in the layout! A `this.stepname` property could be used to see which URL segment has been matched.
|
|
462
461
|
|
|
463
462
|
```js
|
|
464
463
|
/**
|
|
@@ -476,6 +475,12 @@ export default function(event, context, next) {
|
|
|
476
475
|
}
|
|
477
476
|
```
|
|
478
477
|
|
|
478
|
+
<details>
|
|
479
|
+
<summary>More details...</summary>
|
|
480
|
+
|
|
481
|
+
> Every handler function has a `this.stepname` and `this.pathname` property. Server-side handlers have an extra `this.dirname` property.
|
|
482
|
+
</details>
|
|
483
|
+
|
|
479
484
|
Additionally, workflows may be designed with as many or as few step functions as necessary; the flow control parameters `next.stepname` and `next.pathname` can be used at any point to handle the rest of an URL that have no corresponding step functions.
|
|
480
485
|
|
|
481
486
|
For example, it is possible to handle all URLs from the root handler alone.
|
|
@@ -640,15 +645,23 @@ my-app
|
|
|
640
645
|
└── public/index.html ----------------------- http://localhost:3000/index.html --------- text/html
|
|
641
646
|
```
|
|
642
647
|
|
|
643
|
-
But, we can also access the route in a way that gets the data rendered into the automatically-paired `index.html` file for a dynamic page response. We'd simply set the [`Accept`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept) header of the request to match `text/html` - e.g. `text/html`, `text/*`, `*/html`, `*/*`, and Webflo will automatically perform [Server-Side Rendering](#client-and-server-side-rendering) to give a page response.
|
|
648
|
+
But, we can also access the route in a way that gets the data rendered into the automatically-paired `index.html` file for a dynamic page response. We'd simply set the [`Accept`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept) header of the request to something that can match as `text/html` - e.g. `text/html`, `text/*`, `*/html`, `*/*`, and Webflo will automatically perform [Server-Side Rendering](#client-and-server-side-rendering) to give a page response.
|
|
644
649
|
|
|
645
|
-
>
|
|
646
|
-
|
|
650
|
+
<details>
|
|
651
|
+
<summary>How it works...</summary>
|
|
652
|
+
|
|
653
|
+
> The `Accept` header hint is already how browsers make requests on every page load. So, it just works!
|
|
654
|
+
|
|
655
|
+
> Note that the automatic pairing of an `index.html` file with a route works the same for nested routes! But top-level `index.html` files are implicitly inherited down the hierarchy.)
|
|
656
|
+
</details>
|
|
647
657
|
|
|
648
658
|
Now, for Single Page Applications, subsequent navigations, after the initial page load, just ask for the data on destination URLs and perform [Client-Side Rendering](#client-and-server-side-rendering) on the same running document. Navigation is sleek and instant!
|
|
649
659
|
|
|
650
|
-
>
|
|
651
|
-
|
|
660
|
+
<details>
|
|
661
|
+
<summary>How it works...</summary>
|
|
662
|
+
|
|
663
|
+
> Unless disabled, [SPA Routing](#spa-routing) is automatically built into your app's JS bundle from the `npm run generate` command. So, it just works!
|
|
664
|
+
</details>
|
|
652
665
|
|
|
653
666
|
With no extra work, your application can function as either a *Multi Page App (MPA)* or a *Single Page App (SPA)*!
|
|
654
667
|
|
|
@@ -1407,7 +1420,7 @@ console.log(document.state.network) // { requesting, remote, error, redirecting,
|
|
|
1407
1420
|
```
|
|
1408
1421
|
|
|
1409
1422
|
<details>
|
|
1410
|
-
<summary>Property: <code>.network.requesting
|
|
1423
|
+
<summary>Property: <code>.network.requesting: null|Object</code></summary>
|
|
1411
1424
|
|
|
1412
1425
|
This property tells when a request is ongoing, in which case it exposes the `params` object used to initiate the request.
|
|
1413
1426
|
|
|
@@ -1426,7 +1439,7 @@ On the UI, this could be used to hide a menu drawer that may have been open.
|
|
|
1426
1439
|
</details>
|
|
1427
1440
|
|
|
1428
1441
|
<details>
|
|
1429
|
-
<summary>Property: <code>.network.remote
|
|
1442
|
+
<summary>Property: <code>.network.remote: null|String</code></summary>
|
|
1430
1443
|
|
|
1431
1444
|
This property tells when a remote request is ongoing - usually the same navigation requests as at `network.requesting`, but when not handled by any client-side route handlers, or when `next()`ed to this point by route handlers. The `remote` property also goes live when a route handler calls the special `fetch()` function that they recieve on their fourth parameter.
|
|
1432
1445
|
|
|
@@ -1443,7 +1456,7 @@ On the UI, this could be used to show/hide a spinner, or progress bar, to provid
|
|
|
1443
1456
|
</details>
|
|
1444
1457
|
|
|
1445
1458
|
<details>
|
|
1446
|
-
<summary>Property: <code>.network.error
|
|
1459
|
+
<summary>Property: <code>.network.error: null|Error</code></summary>
|
|
1447
1460
|
|
|
1448
1461
|
This property tells when a request is *errored* in which case it contains an `Error` instance of the error. For requests that can be retried, the `Error` instance also has a custom `retry()` method.
|
|
1449
1462
|
|
|
@@ -1460,7 +1473,7 @@ On the UI, this could be used to show/hide cute error elements.
|
|
|
1460
1473
|
</details>
|
|
1461
1474
|
|
|
1462
1475
|
<details>
|
|
1463
|
-
<summary>Property: <code>.network.redirecting
|
|
1476
|
+
<summary>Property: <code>.network.redirecting: null|String</code></summary>
|
|
1464
1477
|
|
|
1465
1478
|
This property tells when a client-side redirect is ongoing - see [Scenario 4: Single Page Navigation Requests and Responses](#scenario-4-single-page-navigation-requests-and-responses) - in which case it exposes the destination URL.
|
|
1466
1479
|
|
|
@@ -1477,7 +1490,7 @@ On the UI, this could be used to prevent further interactions with the outgoing
|
|
|
1477
1490
|
</details>
|
|
1478
1491
|
|
|
1479
1492
|
<details>
|
|
1480
|
-
<summary>Property: <code>.network.connectivity
|
|
1493
|
+
<summary>Property: <code>.network.connectivity: String</code></summary>
|
|
1481
1494
|
|
|
1482
1495
|
This property tells of [the browser's ability to connect to the network](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/onLine): `online`, `offline`.
|
|
1483
1496
|
|