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

refactor(runtime-core): add @internal for instance.proxy #1849

Merged
merged 1 commit into from
Aug 18, 2020
Merged

refactor(runtime-core): add @internal for instance.proxy #1849

merged 1 commit into from
Aug 18, 2020

Conversation

Picknight
Copy link
Contributor

No description provided.

@yyx990803 yyx990803 merged commit 4d51be7 into vuejs:master Aug 18, 2020
@chenjiahan
Copy link
Contributor

How to access the component instance in setup?

Current usage:

import { getCurrentInstance } from "vue";

setup() {
  const instance = getCurrentInstance();
  instance.proxy. // == vm
}

@HcySunYang
Copy link
Member

I still think we should revert it, it's especially useful in third-party libraries such as vue-test-utils-next, also very commonly used in component libraries.

@ChesterBu
Copy link
Contributor

So,How to access the component Public instance in setup for now?

@Picknight
Copy link
Contributor Author

I still think we should revert it, it's especially useful in third-party libraries such as vue-test-utils-next, also very commonly used in component libraries.

Agreed.

posva added a commit to vuejs/router that referenced this pull request Sep 1, 2020
BREAKING CHANGE: `onBeforeRouteLeave` and `onBeforeRouteUpdate` used to
have access to the component instance through `instance.proxy` but given
that:
1. It has been marked as `internal` (vuejs/core#1849)
2. When using `setup`, all variables are accessible on the scope (and
   should be accessed that way because the code minimizes better)
It has been removed to prevent wrong usage and lighten Vue Router
posva added a commit to vuejs/router that referenced this pull request Sep 1, 2020
BREAKING CHANGE: `onBeforeRouteLeave` and `onBeforeRouteUpdate` used to
    have access to the component instance through `instance.proxy` but given
    that:
    1. It has been marked as `internal` (vuejs/core#1849)
    2. When using `setup`, all variables are accessible on the scope (and
       should be accessed that way because the code minimizes better)
    It has been removed to prevent wrong usage and lighten Vue Router
@yyx990803
Copy link
Member

Why are people trying to get instance.proxy in setup? What is the use case for this?

@chenjiahan
Copy link
Contributor

This is our use case: expose some apis for component user

// Form.jsx
export default {
  name: 'MyForm',

  setup() {
    const vm = getCurrentInstance().proxy;

    vm.reset = () => {
      // reset form
    };

    return () => <div class="form"></div>
  },
};
<!-- App.vue -->
<template>
  <MyForm ref="form" />
</template>
<script>

export default {
  mounted() {
    this.$refs.form.reset();
  }
}
</script>

@Picknight
Copy link
Contributor Author

@chenjiahan You can achieve your purpose like this:

// Form.jsx
export default {
  name: 'MyForm',
  methods: {
    reset() {
      // reset form
    }
  },
  setup() {
    return () => <div class="form"></div>
  },
};

@chenjiahan
Copy link
Contributor

chenjiahan commented Sep 2, 2020

@Picknight no, we can't.

// Form.jsx
export default {
  name: 'MyForm',

  setup() {
    const vm = getCurrentInstance().proxy;
    const text = ref('foo');

    vm.reset = () => {
      // reset form
      text.value = '';
    };

    return () => <div class="form">{text.value}</div>
  },
};

@yyx990803
Copy link
Member

Ok, so the team actually is discussing an API to explicitly expose public methods, something like

import { expose } from 'vue'

export default {
  setup() {
    expose({
      reset() {
        // ...
      }
    })
  }
}

Either way I don't think it should be done by messing directly with the internal instance.

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

Successfully merging this pull request may close these issues.

5 participants