piral-page-layouts 0.15.0-beta.4579 → 0.15.0-beta.4633
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 +73 -1
- package/package.json +3 -3
package/README.md
CHANGED
|
@@ -8,7 +8,79 @@ By default, these API extensions are not integrated in `piral`, so you'd need to
|
|
|
8
8
|
|
|
9
9
|
## Why and When
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
Sometimes you have some pages that are radically different than the usual pages / layout. For instance, while most pages in a single application should be shown with a header, footer, and navigation, a login page is usually shown without these elements (or with just some of them, e.g., the footer).
|
|
12
|
+
|
|
13
|
+
Of course, you could leave this layout to the page itself, e.g., that
|
|
14
|
+
|
|
15
|
+
```jsx
|
|
16
|
+
const PageA = () => (
|
|
17
|
+
<>
|
|
18
|
+
<Header />
|
|
19
|
+
<Navigation />
|
|
20
|
+
<ActualContentOfPageA />
|
|
21
|
+
<Footer />
|
|
22
|
+
</>
|
|
23
|
+
);
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
while another page is
|
|
27
|
+
|
|
28
|
+
```jsx
|
|
29
|
+
const PageB = () => (
|
|
30
|
+
<>
|
|
31
|
+
<ActualContentOfPageB />
|
|
32
|
+
<Footer />
|
|
33
|
+
</>
|
|
34
|
+
);
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
however, this is rather cumbersome and inconvient to write. If the `Footer` (or other used elements) are not globally available it may be even impossible for a page to use these artifacts. Surely, you could use an extension to transport these, but then again it would remain rather cumbersome and inconvenient to write.
|
|
38
|
+
|
|
39
|
+
A nice way out is to use this plugin, which enables the use of distributed, reusable layouts. It allows you to register a page together with its layout.
|
|
40
|
+
|
|
41
|
+
Beforehand you'd have:
|
|
42
|
+
|
|
43
|
+
```js
|
|
44
|
+
const PageA = () => (
|
|
45
|
+
<>
|
|
46
|
+
<Header />
|
|
47
|
+
<Navigation />
|
|
48
|
+
<ActualContentOfPageA />
|
|
49
|
+
<Footer />
|
|
50
|
+
</>
|
|
51
|
+
);
|
|
52
|
+
|
|
53
|
+
export function setup(app) {
|
|
54
|
+
app.registerPage('/page-a', PageA);
|
|
55
|
+
}
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
Now you can write:
|
|
59
|
+
|
|
60
|
+
```js
|
|
61
|
+
export function setup(app) {
|
|
62
|
+
app.registerPage('/page-a', ActualContentOfPageA, {
|
|
63
|
+
layout: 'standard',
|
|
64
|
+
});
|
|
65
|
+
}
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
So if the `standard` layout has been registered like so:
|
|
69
|
+
|
|
70
|
+
```js
|
|
71
|
+
export function setup(app) {
|
|
72
|
+
app.registerPageLayout('standard', ({ children }) => (
|
|
73
|
+
<>
|
|
74
|
+
<Header />
|
|
75
|
+
<Navigation />
|
|
76
|
+
{children}
|
|
77
|
+
<Footer />
|
|
78
|
+
</>
|
|
79
|
+
));
|
|
80
|
+
}
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
Then it would just work. Otherwise, it will always fall back to the `default` layout, which is also the default choice for the `layout` key in the provided metadata of `registerPage`.
|
|
12
84
|
|
|
13
85
|
## Documentation
|
|
14
86
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "piral-page-layouts",
|
|
3
|
-
"version": "0.15.0-beta.
|
|
3
|
+
"version": "0.15.0-beta.4633",
|
|
4
4
|
"description": "Plugin for providing different page layouts in Piral.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"piral",
|
|
@@ -61,12 +61,12 @@
|
|
|
61
61
|
"test": "echo \"Error: run tests from root\" && exit 1"
|
|
62
62
|
},
|
|
63
63
|
"devDependencies": {
|
|
64
|
-
"piral-core": "0.15.0-beta.
|
|
64
|
+
"piral-core": "0.15.0-beta.4633"
|
|
65
65
|
},
|
|
66
66
|
"peerDependencies": {
|
|
67
67
|
"piral-core": "0.14.x || 0.15.x",
|
|
68
68
|
"react": ">=16.8.0",
|
|
69
69
|
"react-router": "5.x"
|
|
70
70
|
},
|
|
71
|
-
"gitHead": "
|
|
71
|
+
"gitHead": "96b950f26e9673595f68518103508dfc76001761"
|
|
72
72
|
}
|