@webqit/webflo 0.11.10 → 0.11.11
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 +7 -7
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1258,7 +1258,7 @@ Unless disabled in config, it is factored-in at build time for the application c
|
|
|
1258
1258
|
+ If navigation is initiated from a form element that has the `target` attribute, navigation is allowed to work the default way - regardless of the first rule above.
|
|
1259
1259
|
|
|
1260
1260
|
<details>
|
|
1261
|
-
<summary>Default
|
|
1261
|
+
<summary>Config (Default)</summary>
|
|
1262
1262
|
|
|
1263
1263
|
```json
|
|
1264
1264
|
{ "spa_navigation": true }
|
|
@@ -1406,7 +1406,7 @@ One more thing: HTML forms can only accept two HTTP methods on their `method` at
|
|
|
1406
1406
|
Webflo client-side applications are intended to provide an app-like-first experience. So unless disabled in config, a [Service Worker](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) is built as part of your application on running the `npm run generate` command. You may define [route handlers in the `/worker` directory](#handler-functions-and-layout) of your application, and these will be built into the service worker to handle Same-Origin requests of the application. Where there are no *worker* handlers, or where these forward incoming requests, requests are fetched, either from the cache, or from the network, depending on the fetching strategy built into the Service Worker.
|
|
1407
1407
|
|
|
1408
1408
|
<details>
|
|
1409
|
-
<summary>Default
|
|
1409
|
+
<summary>Config (Default)</summary>
|
|
1410
1410
|
|
|
1411
1411
|
```json
|
|
1412
1412
|
{ "service_worker_support": true }
|
|
@@ -1420,7 +1420,7 @@ Webflo client-side applications are intended to provide an app-like-first experi
|
|
|
1420
1420
|
+ **Network First** - This strategy tells the Service Worker to always attempt fetching from the network first for given resources, before fetching from the cache. On every successful network fetch, a copy of the response is saved to the cache for next time. (This is good for resources that need to be fresh to the user on a "best effort" basis.) Unless changed, this is Webflo's default fetching strategy. When not the default strategy, a list of specific URLs that should be fetched this way can be configured.
|
|
1421
1421
|
|
|
1422
1422
|
<details>
|
|
1423
|
-
<summary>Default
|
|
1423
|
+
<summary>Config (Default)</summary>
|
|
1424
1424
|
|
|
1425
1425
|
```json
|
|
1426
1426
|
{ "default_fetching_strategy": "network-first" }
|
|
@@ -1438,7 +1438,7 @@ Webflo client-side applications are intended to provide an app-like-first experi
|
|
|
1438
1438
|
+ **Cache First** - This strategy tells the Service Worker to always attempt fetching from the cache first for given resources, before fetching from the network. After serving a cached response, or where not found in cache, a network fetch happens and a copy of the response is saved to the cache for next time. (This is good for resources that do not critially need to be fresh to the user.) When not the default strategy, a list of specific URLs that should be fetched this way can be configured.
|
|
1439
1439
|
|
|
1440
1440
|
<details>
|
|
1441
|
-
<summary>
|
|
1441
|
+
<summary>Config (Alternative)</summary>
|
|
1442
1442
|
|
|
1443
1443
|
```json
|
|
1444
1444
|
{ "default_fetching_strategy": "cache-first" }
|
|
@@ -1456,7 +1456,7 @@ Webflo client-side applications are intended to provide an app-like-first experi
|
|
|
1456
1456
|
+ **Network Only** - This strategy tells the Service Worker to always fetch given resources from the network only. They are simply not available when offline. (This is good for resources that critially need to be fresh to the user.) When not the default strategy, a list of specific URLs that should be fetched this way can be configured.
|
|
1457
1457
|
|
|
1458
1458
|
<details>
|
|
1459
|
-
<summary>
|
|
1459
|
+
<summary>Config (Alternative)</summary>
|
|
1460
1460
|
|
|
1461
1461
|
```json
|
|
1462
1462
|
{ "default_fetching_strategy": "network-only" }
|
|
@@ -1474,7 +1474,7 @@ Webflo client-side applications are intended to provide an app-like-first experi
|
|
|
1474
1474
|
+ **Cache Only** - This strategy tells the Service Worker to always fetch given resources from the cache only. (This is good for resources that do not change often.) When not the default strategy, a list of specific URLs that should be fetched this way can be configured. The listed resources are pre-cached ahead of when they'll be needed - and are served from the cache each time. (Pre-caching happens on the one-time `install` event of the Service Worker.)
|
|
1475
1475
|
|
|
1476
1476
|
<details>
|
|
1477
|
-
<summary>
|
|
1477
|
+
<summary>Config (Alternative)</summary>
|
|
1478
1478
|
|
|
1479
1479
|
```json
|
|
1480
1480
|
{ "default_fetching_strategy": "cache-only" }
|
|
@@ -1718,7 +1718,7 @@ Webflo applications are often built on/with the following technologies.
|
|
|
1718
1718
|
Webflo natively supports OOHTML in full! But it is also possible to switch this to none, or to partial support - when specific features aren't needed anywhere in your application. Server-side and client-side support for OOHTML exist independently. This is good when, for example, your application places more importance on SSR, and less on CSR, in which case a reduced support for OOHTML can reduce the overall client JS bundle size.
|
|
1719
1719
|
|
|
1720
1720
|
<details>
|
|
1721
|
-
<summary>Default
|
|
1721
|
+
<summary>Config (Default)</summary>
|
|
1722
1722
|
|
|
1723
1723
|
```json
|
|
1724
1724
|
{ "oohtml_support": "full" }
|