@webqit/webflo 0.11.15 → 0.11.16
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 +6 -4
- 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
|
|
|
@@ -455,9 +457,7 @@ export default async function(event, context, next) {
|
|
|
455
457
|
</details>
|
|
456
458
|
</details>
|
|
457
459
|
|
|
458
|
-
|
|
459
|
-
|
|
460
|
-
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
|
+
But, 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.
|
|
461
461
|
|
|
462
462
|
```js
|
|
463
463
|
/**
|
|
@@ -645,12 +645,14 @@ my-app
|
|
|
645
645
|
└── public/index.html ----------------------- http://localhost:3000/index.html --------- text/html
|
|
646
646
|
```
|
|
647
647
|
|
|
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 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.
|
|
649
649
|
|
|
650
650
|
<details>
|
|
651
651
|
<summary>How it works...</summary>
|
|
652
652
|
|
|
653
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.)
|
|
654
656
|
</details>
|
|
655
657
|
|
|
656
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!
|