TypeError: this.$t is not a function in an async method, after component is not rendered anymore #990
Comments
|
Thank you for your reporting! I’ve checked this issue in your reproduction repo. This issue is really weird ... 🤔 I have tried various workarounds, such as saving |
kazupon
added
help wanted
|
Thank you for looking into this! 💟 This could be a vue3 limitation, as I found this comment in the proposal breaking change: As for workarounds, one that could work is using the "global" |
|
Another workaround that seems to be working is the following, but I'm unsure if that is a reasonable enough workaround, and if it will not backfire horribly in some cases? I made a small branch with this change on my repo under Also, I do not know if that is related to this, but inside my real-life application, if I put my current component to the console when i18n's |
|
Thank you for your workaround idea! ❤️ I seem that your ideas work fine if you use global scope in legacy API mode, APIs like |
|
Thank you for the feedback, I'll be using this in my app for now (we only use global scope), and think about using the composition mode later after I manage to migrate to vue3 😄 |
|
Getting a few of these errors coming through lately as well. Its as simple as having an ajax call in a page If I Normal case - when everything works fine, $t, $tc etc are all available: Failure case - |
|
It looks like in legacy mode we use mixin that removes |
|
Hi, Is there any plan to fix this? |
|
I'm facing with this issue too. I created another workaround to by-pass this issue like below. data() {
return {
msg: {
key: this.$t('localizationKey')
}
};
},
methods: {
async someMethod() {
await someAsyncProcess();
alert(this.msg.key);
}
} |
|
The issue is still relevant. Are there any plans to fix this? We are in the process of migrating the app to Vue3, and I guess we'll have to look for such cases throughout the whole app manually, which is not much fun :( UPD: seems that CamilleDrapier's workaround helped; we'll stick to it for now. But I hope it will be fixed at some point. |
|
Hello, i have this exact same issue and i found a fix : let plugin = {
install: (app) => {
let i18nApp = Object.assign({}, app, {
mixin: (m) => {
// We don't want unmounted hook because we want i18n to still work after component unmounting
delete m.unmounted;
app.mixin(m);
}
});
i18n.install(i18nApp);
}
}we simply remove unmounted hook from the i18n mixin, so $t is still available after component destruction i think removing $t and other global properties lead to unexpected behaviours down the line and is a bad idea. In my particular use case, |
|
I've faced with exactly the same issue. Could it be fixed for the async methods without hacks? |
|
This isn't necessarily related to async methods, there shouldn't be any issues using i18n inside of an async method as long as you're not unmounting the current component before accessing component methods, I updated the reproduction to demonstrate this in a stackblitz project here. This edge case is probably not present when using the composition API. I think you may run into other issues if you rely on the component instance after unmount, as described here certain functionality such as reactive effect will be stopped after unmount, so you may run into unpredictable behavior (not just related to vue-i18n). There are a few ways to work around the issue in the reproduction:
This issue is not straightforward to 'fix', I guess instead of deleting the keys on the component they could be replaced with those used by the global/root scope? Maybe this would lead to other confusing behavior but it would prevent erroring. |
Reporting a bug?
I get the following error when I try to call
$t, in an async method that makes the current component not being rendered anymore:More specifically, I think the problematic case can be broken down as follow:
awaitcall (slow) followed by calling$t$tcall to happen and respond normally after theawaitpart is finishedExpected behavior
I think I should be able to run a method without having to care about the fact that the component is not being rendered anymore after an
awaitcall.Please let me know if this assumption is not reasonable, as I'm not completely sure it is fine. Also if you think something is to be fixed on the
vue-coreside and not in this repo, please do tell me as well 🙇Reproduction
Please use the
async-translationbranch in this repository: https://github.com/CamilleDrapier/vue-i18n-test/tree/async-translationClicking on the "Hide and display translation" button triggers an error
System Info
System: OS: Linux 5.15 Manjaro Linux CPU: (12) x64 Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz Memory: 16.48 GB / 30.99 GB Container: Yes Shell: 5.8.1 - /bin/zsh Binaries: Node: 16.14.2 - ~/.nvm/versions/node/v16.14.2/bin/node Yarn: 1.22.18 - ~/.nvm/versions/node/v16.14.2/bin/yarn npm: 8.5.0 - ~/.nvm/versions/node/v16.14.2/bin/npm Browsers: Chromium: 100.0.4896.127 Firefox: 99.0.1 npmPackages: @vue/cli-plugin-eslint: ~4.5.0 => 4.5.15 @vue/cli-plugin-typescript: ~4.5.0 => 4.5.15 @vue/cli-service: ~4.5.0 => 4.5.15 @vue/compiler-sfc: ^3.0.0 => 3.2.33 @vue/eslint-config-standard: ^5.1.2 => 5.1.2 @vue/eslint-config-typescript: ^7.0.0 => 7.0.0 vue: ^3.2.33 => 3.2.33 vue-i18n: ^9.2.0-beta.35 => 9.2.0-beta.35Screenshot
No response
Additional context
At least in my real-life application that was built with vue2 // vue-i18n v8, I was able to do similar things with no problems until I tried upgrading to vue3 // vue-i18n v9.
If this is still supported then maybe the problem is that the translation plugin of the component is unloaded/removed too early in the life-cycle?
Could be related to: #609
Validations
The text was updated successfully, but these errors were encountered: