创建一个内含方法的计算属性是否合法?

huangapple go评论72阅读模式
英文:

Is it legit to create a computed property with a method inside?

问题

我需要我在计算属性中使用的逻辑两次。由于存在竞态条件,我不能使用计算属性本身。因此,我的想法是将功能放在一个方法中,并像这样重写计算属性:

const filterProjectOptions = () => {
    let options = [];
    if (propData.value.contact_company.projects.billable.length) {
        propData.value.contact_company.projects.billable.forEach((element, index) => {
            options[index] = cloneDeep(element);
            options[index].select_value = element.id;
            options[index].select_label = (element.name ? element.name : "Kein Name");
        })
    }
    return options;
}

const billableProjects = computed(() => {
    let options = filterProjectOptions();
    return options;
});

我想知道计算属性是否仍然像以前一样具有响应性,或者提取逻辑是否可能会产生副作用?

英文:

I need the logic I use inside a computed property twice. I can't use the computed property itself because of a race condition. So my thought was to put the functionality inside a method and re-write the computed property like this:

const filterProjectOptions = () => {
    let options = [];
    if (propData.value.contact_company.projects.billable.length) {
        propData.value.contact_company.projects.billable.forEach((element, index) => {
            options[index] = cloneDeep(element);
            options[index].select_value = element.id;
            options[index].select_label = (element.name ? element.name : "Kein Name");
        })
    }
    return options;
}

const billableProjects = computed(() => {
    let options = filterProjectOptions();
    return options;
});

I wonder if the computed property still is as reactive as before or if extracting the logic might have side effects?

答案1

得分: 4

在你的代码中,filterProjectOptions 函数被在计算属性 billableProjects 中调用。只有在其响应式依赖发生变化时,计算属性才会重新计算其值。

在这种情况下,由于 filterProjectOptions 在计算属性中被调用,filterProjectOptions 的响应式依赖发生变化将触发 billableProjects 的重新计算。但是,如果 filterProjectOptions 的响应式依赖不发生变化,计算属性 billableProjects 将不会重新计算。

如果你将整个逻辑直接写在计算属性中,那么该逻辑中的响应式依赖的任何变化都会触发计算属性的重新计算。然而,如果响应式依赖在 filterProjectOptions 中使用,而不是直接在计算属性中使用,那么只有 filterProjectOptions 的结果发生变化时,计算属性才会重新计算。

总之,如果 filterProjectOptions 内部的逻辑依赖于可能发生变化的响应式依赖,并且希望在这些依赖发生变化时重新计算计算属性,那么在计算属性内部调用 filterProjectOptions 是正确的方法。

英文:

In your code, the filterProjectOptions function is called within the computed property billableProjects. The computed property will only recompute its value when one of its reactive dependencies changes.

In this case, since filterProjectOptions is called within the computed property, any changes in the reactive dependencies of filterProjectOptions will trigger recomputation of billableProjects. However, if the reactive dependencies of filterProjectOptions do not change, the computed property billableProjects will not be recomputed.

If you were to write the entire logic directly inside the computed property, any change in the reactive dependencies within that logic would trigger recomputation of the computed property. However, if the reactive dependencies are used within filterProjectOptions but not within the computed property directly, the computed property would not be recomputed unless the result of filterProjectOptions changes.

In summary, if the logic inside filterProjectOptions relies on reactive dependencies that may change, and you want the computed property to recompute when those dependencies change, calling filterProjectOptions within the computed property is the correct approach.

huangapple
  • 本文由 发表于 2023年5月26日 13:39:27
  • 转载请务必保留本文链接:https://go.coder-hub.com/76337929.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定