Document view groups #627
Merged
Document view groups #627
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jesusreal
requested review from
bszwarc,
hardl,
JohannesDoberer,
kazydek,
marynaKhromova,
maxmarkus,
mmitoraj,
pekura and
tomekpapiernik
as code owners
pekura
suggested changes
Jul 4, 2019
pekura
approved these changes
Jul 4, 2019
maxmarkus
reviewed
Jul 4, 2019
docs/navigation-configuration.md
Outdated
| ## View Groups | ||
| You can use the view groups feature to override the default iframes management policy. Imagine you have in your app the following microfrontend views: `http://mysite.com/a#e` and `http://mysite.com/b#f`. Due to hash routing and the fact the path until _#_ differs, they will be rendered in different iframes by default. Nevertheless both views might have the **same origin** (in the example `mysite.com`) and belong to the **same microfrontend** and you will want to render them in the same iframe. The view groups feature makes that possible just by setting the `viewGroup` parameter in the most upper nodes, as their children nodes are automatically considered part of the same view group. | ||
|
|
||
| View group nodes are always rendered in their own iframe. Nodes not belonging to any view group will default to the same-origin iframe rendering policy. |
There was a problem hiding this comment.
in their own iframe .. means in a view group iframe?
maxmarkus
approved these changes
Jul 4, 2019
bszwarc
reviewed
Jul 8, 2019
docs/navigation-configuration.md
Outdated
| ``` | ||
|
|
||
| ## View Groups | ||
| You can use the view groups feature to override the default iframes management policy. Imagine you have in your app the following microfrontend views: `http://mysite.com/a#e` and `http://mysite.com/b#f`. Due to hash routing and the fact the path until _#_ differs, they will be rendered in different iframes by default. Nevertheless both views might have the **same origin** (in the example `mysite.com`) and belong to the **same microfrontend** and you will want to render them in the same iframe. The view groups feature makes that possible just by setting the `viewGroup` parameter in the most upper nodes, as their children nodes are automatically considered part of the same view group. |
There was a problem hiding this comment.
Suggested change
| You can use the view groups feature to override the default iframes management policy. Imagine you have in your app the following microfrontend views: `http://mysite.com/a#e` and `http://mysite.com/b#f`. Due to hash routing and the fact the path until _#_ differs, they will be rendered in different iframes by default. Nevertheless both views might have the **same origin** (in the example `mysite.com`) and belong to the **same microfrontend** and you will want to render them in the same iframe. The view groups feature makes that possible just by setting the `viewGroup` parameter in the most upper nodes, as their children nodes are automatically considered part of the same view group. | |
| The view groups feature allows you to override the default iframes management policy. | |
| Imagine your application hosts two micro front-end views: `http://mysite.com/a#e` and `http://mysite.com/b#f`. Due to hash routing and a different path up to `#`, they are, by default, rendered in different iframes. However, as they both have the **same origin**, such as`mysite.com`, and belong to the **same micro front-end** you want to render them in the same iframe. To achieve that, use the view groups feature. Define the **viewGroup** parameter for top navigation nodes. The children nodes will automatically be considered as part of the same view group. |
There was a problem hiding this comment.
I commited your suggestion, just replaced "micro front-end" with "micro frontend".
docs/navigation-configuration.md
Outdated
|
|
||
| Nodes belonging to the same view group are always rendered in their own viewgroup iframe. Nodes not belonging to any view group will default to the same-origin iframe rendering policy. | ||
|
|
||
| The view groups feature also offers caching. Caching of view groups is provided out of the box. Everytime you navigate to another view group, either a new iframe is created or if the iframe already exists, it is reused. In both cases, the iframe you are navigating from is not destroyed, but hidden and available to be used again. If you navigate back to the first iframe, and the view in that frame should be updated (e.g. in the second iframe you just added a new entry to a table that should be displayed in the first iframe), you need to set a preload url to any view from the view group to ensure that the view is refreshed when you navigate back to it. |
There was a problem hiding this comment.
Suggested change
| The view groups feature also offers caching. Caching of view groups is provided out of the box. Everytime you navigate to another view group, either a new iframe is created or if the iframe already exists, it is reused. In both cases, the iframe you are navigating from is not destroyed, but hidden and available to be used again. If you navigate back to the first iframe, and the view in that frame should be updated (e.g. in the second iframe you just added a new entry to a table that should be displayed in the first iframe), you need to set a preload url to any view from the view group to ensure that the view is refreshed when you navigate back to it. | |
| The view groups feature also offers out-of-the-box caching. Each time you navigate to another view group, either a new iframe is created or it is reused if already exists. In both cases, the iframe you are navigating from becomes hidden and is available for you to use again. | |
| If you navigate back to the first iframe to update it with new data, such as a new entry in a table in the second iframe that you want to display in the first iframe, you must define a **preloadUrl** parameter for a given view in the view group to ensure that the view is refreshed when you navigate back to it. |
There was a problem hiding this comment.
That is great but I didn't apply it completely because the example part was confusing for me. Please check again.
Co-Authored-By: Barbara Szwarc <[email protected]>
Co-Authored-By: Barbara Szwarc <[email protected]>
Co-Authored-By: Barbara Szwarc <[email protected]>
Co-Authored-By: Barbara Szwarc <[email protected]>
Co-Authored-By: Barbara Szwarc <[email protected]>
Co-Authored-By: Barbara Szwarc <[email protected]>
Co-Authored-By: Barbara Szwarc <[email protected]>
bszwarc
approved these changes
Jul 8, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Changes proposed in this pull request: