Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$store is undefined when using <MountingPortal> #199

Closed
bgondy opened this issue Apr 17, 2019 · 6 comments · Fixed by #200
Closed

$store is undefined when using <MountingPortal> #199

bgondy opened this issue Apr 17, 2019 · 6 comments · Fixed by #200
Assignees

Comments

@bgondy
Copy link

bgondy commented Apr 17, 2019

When I use <MountingPortal> to render a component outside of the main Vue component, Vuex is not available.

<!-- public/index.html -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <!-- ... -->
  </head>
  <body>
    <div id="app"></div>
    <div id="test"></div>
    <!-- built files will be auto injected -->
  </body>
</html>
<template>
  <div id="app">
    <MountingPortal name="test-component" mountTo="#test">
      <TestComponent/>
    </MountingPortal>
  </div>
</template>

<script>
import TestComponent from "./components/TestComponent";

export default {
  name: 'app',
  components: {
    TestComponent,
  }
}
</script>
<!-- TestComponent.vue -->
<template>
    <div>
        <h1>Hello world</h1>
    </div>
</template>

<script>
    export default {
        name: 'TestComponent',
        mounted() {
            console.log(this);
        },
    };
</script>

The component is rendered but this.$store is not defined.

If I use <Portal> and <PortalTarget>, this.$store exists.

<!-- App.vue -->
<template>
  <div id="app">
    <Portal to="my-portal" append>
      <TestComponent/>
    </Portal>

    <PortalTarget name="my-portal"></PortalTarget>
  </div>
</template>

<script>
import TestComponent from "./components/TestComponent";

export default {
  name: 'app',
  components: {
    TestComponent,
  }
}
</script>

With portal-vue@1 and targetEl, I have access to the store (but with other known issues though).

Is it the expected behavior with the new <MountingPortal> component or am I missing something ?

Please note I've encountered a similar issue with vue-i18n (See kazupon/vue-i18n#184 (comment)).

@LinusBorg
Copy link
Owner

LinusBorg commented Apr 17, 2019

I'll rate this a bug and look into it, thanks for reporting.

Edit: Found the iussue:

https://github.com/LinusBorg/portal-vue/blob/develop/src/components/mounting-portal.tsx#L107

Now the question is, WTH did comment that out?

Will fix it and add a test for it.

@tmorehouse
Copy link

Would you want the generated Portal-Target parent to be the Portal creating it (parent = this), or the parent of the Portal? i.e. parent = this.$parent

@LinusBorg
Copy link
Owner

LinusBorg commented Apr 17, 2019

In the context of this issue, both should work.

However I would tend to the second as that would mean that the number of steps to reach the portal's parent is the same as with a normal portal.

But I have to double check

@tmorehouse
Copy link

Or could do the following:

parent = this.$parent || this

@LeBenLeBen
Copy link

@bgondy Did that fixed your issue?

I'm using 2.1.5 and having the issue with Vue-i18n throwing i18n is undefined every time $t is called.

I'm using it through morkro/vue-a11y-dialog which is using <mounting-portal append :mount-to="portalTarget"></mouting-portal>.

Once I move my child component outside of the Portal, everything works fine.

@bgondy
Copy link
Author

bgondy commented Jul 19, 2019

@LeBenLeBen Yes it fixed the issue with VueX.

On the other hand, I faced the exact same issue with i18n on a previous project and I have had to roll back to v1 to get it working (time was running out…). But I think this is more related to how Vue-i18n works than portal-vue.

Please take a look at my comment here : kazupon/vue-i18n#184 (comment)

Hope it helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants