Open vbgm opened 5 years ago
Same here, the meteor.property is being run at least once when the page is rendered regardless of whether it is used in the template or not, even with $lazy='true'.
What's worse, it can result in unexpected errors if the meteor.property relies on props or data which might be invalid in that situation. e.g:
<template>
<div>
<div v-if="user">{{user.profile.name}}</div>
<div v-else>
all users:
<ul><li v-for="u in allUsers" :key="_id">{{u.profile.name}}</li></ul>
</div>
</div>
</template>
<script>
export default {
props: ['user', 'query'], // we only need one of these
meteor: {
allUsers() {
return Meteor.users.find(this.query, {fields: {"profile.name"}: 1);
}
}
}
</script>
(this is a contrived example, but I have some real world experience of this bug in more complicated components.)
Here the allUsers
property isn't required if a user object is passed a prop, in which case the component might reasonably be called without the query
prop at all. This would cause this.query
to be undefined in allUsers()
, even though allUsers
isn't necessary.
My work-around is to do this instead:
export default {
props: ['user', 'query'], // we only need one of these
computed: {
allUsers() { return this.$autorun(() => {
if (!this.query) console.error('component called without any valid props');
return this.query ? Meteor.users.find(this.query, {fields: {"profile.name"}: 1}) || [];
})}
}
}
Now the allUsers
property isn't called unless it is actually needed (in which case the parent component should hopefully have passed the query
prop instead.
@Akryum are there any chances you could pay attention to issues with Meteor integration? To me (and hopefully to many), native Meteor (with Tracker and MiniMongo) has more advantages than Apollo.
@vblagomir @wildhart
Hello, guys! I decided to look under the hood and try to fix this. It turned out that we have two separated issues here: when $lazy
is true and when it isn't.
The behavior of $lazy
may not be a bug at all: @Akryum added it in a single commit and I guess the idea is that $lazy
disables reactivity but still provides initial values.
I created two PRs: #60 and #61. I'm not sure any of them will/could be merged but I hope they will be at least reviewed.
In the above example:
Expected behaviour: The 'test2' should not trigger at all when '$lazy' is enabled, or be triggered only once when $lazy is disabled.
Notes: 'Vue.config.meteor.freeze = true' does not fix it either.