docs: Merge various small fixes (#275)

* docs: add warning in docs about using slim with multiple (#259) #258 * Fix typo in README.md (#274) * docs: fix typo (#257)
LinusBorg · Nov 27, 2019 · 30e6145 · 30e6145
1 parent 6838ac5
commit 30e6145
Show file tree

Hide file tree

Showing 3 changed files with 7 additions and 2 deletions.
diff --git a/docs/README.md b/docs/README.md
@@ -25,7 +25,7 @@ sidebar: false
 <portal-target name="destination">
   <!--
   This component can be located anwhere in your App
-  (i.e. right before the </body> tag, for good for overlays).
+  (i.e. right before the </body> tag, good for overlays).
   The slot content of the above portal component will be rendered here.
   -->
 </portal-target>

diff --git a/docs/api/portal-target.md b/docs/api/portal-target.md
@@ -48,6 +48,11 @@ You should use the `order` prop on the `<Portal>` to define the order in which t
 </div>
 ```
 
+:::warning Usage with `slim`
+`multiple` may not behave as expected when its `<PortalTarget>` is also in `slim` mode because `slim` attempts to 
+assign the content's root node as the `<PortalTarget>`'s root node, thereby _only_ rendering the first of all incoming nodes.
+:::
+
 ### `name`
 
 | Type     | Required | Default |

diff --git a/docs/guide/SSR.md b/docs/guide/SSR.md
@@ -15,7 +15,7 @@ For the aforementioned reasons, starting with <Badge text="2.1.2" />, content wo
 
 We want to display the `<portal-target>` content on the client, though. In order to prevent any hydration mismatches, we can use a _really_ tiny [component called `<no-ssr>`](https://github.com/egoist/vue-no-ssr), written by [@egoist](https://github.com/egoist), which can solve this problem.
 
-We wrap oour `<portal-target>` elements in it, and it will prevent rendering on the server as well as on the client during hydration, preventing the error described above. Immediatly _after_ hyration, it will render the previously "hidden" content, so that the `<portal-target>` will render its content. Usually the user can hardly notice this as the update is near-immediate.
+We wrap our `<portal-target>` elements in it, and it will prevent rendering on the server as well as on the client during hydration, preventing the error described above. Immediatly _after_ hyration, it will render the previously "hidden" content, so that the `<portal-target>` will render its content. Usually the user can hardly notice this as the update is near-immediate.
 
 Example: