Hilla应用中Vaadin Grid异步数据绑定与Promise处理指南

本文深入探讨了hilla应用中在使用vaadin grid展示异步数据时常见的`promise`类型错误。通过分析ui组件数据绑定、mobx状态管理和promise异步操作中的常见误区，提供了详细的解决方案，包括正确绑定grid数据源、合理使用`await`关键字处理promise，以及优化store中的异步数据获取逻辑，旨在帮助开发者构建稳定高效的hilla应用。

Hilla应用中Vaadin Grid异步数据绑定与Promise处理指南

在Hilla框架中开发Web应用程序时，将后端数据通过Endpoint异步加载并展示在前端UI组件（如Vaadin Grid）中是常见的需求。然而，由于JavaScript的异步特性以及Hilla/Vaadin组件对数据源的特定要求，开发者在处理Promise和数据绑定时常常会遇到类型错误，例如Type 'Promise<void>' is missing the following properties from type。本教程旨在详细解析这类问题的原因，并提供一套系统的解决方案和最佳实践。

Hilla中Vaadin Grid异步数据绑定常见陷阱

当尝试将后端获取的产品类别数据展示在vaadin-grid中时，如果处理不当，可能会遇到类似Type 'Promise<void>' is missing the following properties from type的错误。这个错误通常发生在UI组件期望一个具体的数据数组，但实际接收到的却是一个未解析的Promise对象，甚至是一个Promise<void>，表明Promise最终不会返回任何有用的值。

其核心根源在于对异步操作（Promise）的理解不足以及数据流管理上的混淆。vaadin-grid的items属性期望绑定到一个可迭代的数据集合（如ProductCategoryDataList[]），而不是一个异步方法或者一个Promise本身。

逐步解决：Hilla数据流与UI绑定优化

我们将从问题出现的各个层面，即UI组件绑定、Store层面的异步处理，以及数据获取逻辑，逐一进行优化。

优化一：Vaadin Grid的数据源绑定

问题描述： 原始代码中，vaadin-grid的items属性直接绑定到了一个方法调用：

<vaadin-grid theme="row-stripes" .items="${categoryListRegisterViewStore.loadProductCategory}" >
    <!-- ... columns ... -->
</vaadin-grid>

loadProductCategory是一个异步方法，它返回一个Promise。vaadin-grid的items属性期望接收一个数据数组，而不是一个方法或一个Promise。因此，当loadProductCategory被调用时，它返回的Promise对象被直接赋给了items，导致类型不匹配错误。

解决方案：items属性应该绑定到Store中实际存储数据数组的属性。在我们的例子中，这个属性是categoryListRegisterViewStore.categoryList。

修正后的HTML代码：

<vaadin-grid theme="row-stripes" .items="${categoryListRegisterViewStore.categoryList}" >
    <!-- ... columns ... -->
</vaadin-grid>

通过这种方式，vaadin-grid将直接监听categoryList数组的变化，当categoryList被异步数据填充后，Grid会自动更新显示。

优化二：Store中异步数据加载的Promise处理

问题描述：CategoryListRegisterViewStore中的loadProductCategory方法试图将一个Promise赋值给categoryList属性：

MacsMind

电商AI超级智能客服

131

查看详情

export class CategoryListRegisterViewStore {
    categoryList: ProductCategoryDataList[] = [];

    // ... constructor ...

    loadProductCategory() {
        const prodCategory = appStore.tricampCrmProductStore.fetchProductCatgeory(); // prodCategory 是一个 Promise
        runInAction(() => {
            this.categoryList = prodCategory; // 尝试将 Promise 赋值给数组
        });
    }

    // ... saveProductCategory ...
}

fetchProductCatgeory()方法返回的是一个Promise<ProductCategoryDataList[]>。在loadProductCategory中，prodCategory变量接收到的是这个Promise对象本身，而不是Promise解析后的实际数据。随后，runInAction内部尝试将这个Promise对象赋值给this.categoryList，而this.categoryList的类型是ProductCategoryDataList[]，这就造成了Promise类型与ProductCategoryDataList[]类型之间的不匹配。

解决方案： 在loadProductCategory方法中，需要使用await关键字等待fetchProductCatgeory()返回的Promise解析，获取到实际的数据数组后，再将其赋值给categoryList。同时，由于使用了await，loadProductCategory方法本身也需要声明为async。

修正后的CategoryListRegisterViewStore代码：

export class CategoryListRegisterViewStore {

    categoryList: ProductCategoryDataList[] = [];

    constructor() {
        makeAutoObservable(
            this,
            {
                categoryList: observable.shallow,
            }
        );
        this.loadProductCategory(); // 确保在构造函数中调用加载数据
    }

    async loadProductCategory() { // 声明为 async
        const prodCategory = await appStore.tricampCrmProductStore.fetchProductCatgeory(); // 使用 await 等待 Promise 解析
        runInAction(() => {
            this.categoryList = prodCategory; // 将解析后的数据赋值给 categoryList
        });
    }

    saveProductCategory(categoryDetails: CategoryDetails) {
        return appStore.tricampCrmProductStore.saveProductCategory(categoryDetails);
    }
}

优化三：Endpoint调用结果的正确返回

问题描述：ProductStore中的fetchProductCatgeory方法存在缺陷：

export class ProductStore {
    // ... constructor ...

    async fetchProductCatgeory() {
        const prodCatData = await ProductEndpoint.fetchAllProdCategory();
        runInAction(() => {
            return prodCatData; // 这里的问题：runInAction内部的 return 不会影响外部方法的返回值
        });
    }
}

尽管方法内部使用了await获取了prodCatData，但runInAction内部的return prodCatData语句并不会导致fetchProductCatgeory方法本身返回prodCatData。实际上，runInAction是一个副作用函数，它的返回值通常被忽略。因此，fetchProductCatgeory方法最终隐式返回了一个Promise<void>，因为它的显式返回路径中没有return语句，导致上层调用者（CategoryListRegisterViewStore.loadProductCategory）接收到一个无用的Promise。

解决方案：fetchProductCatgeory方法应该直接返回ProductEndpoint.fetchAllProdCategory()调用的Promise，或者如果需要等待结果，直接返回await后的结果。由于runInAction主要用于MobX状态的同步更新，在这里包裹整个异步操作是不恰当的。

修正后的ProductStore代码：

export class ProductStore {
    constructor() {
        makeAutoObservable(this);
        // this.fetchProductCatgeory(); // 可以在需要时再调用，或在其他地方初始化
    }

    async saveProductCategory(prodCategory: CategoryDetails) {
        const responseData = await ProductEndpoint.saveCatgeory(prodCategory);
        return responseData;
    }

    // 直接返回 Promise
    fetchProductCatgeory() {
        return ProductEndpoint.fetchAllProdCategory();
    }

    // 或者，如果需要处理 await，但通常直接返回 Promise 更简洁
    // async fetchProductCatgeory() {
    //     const prodCatData = await ProductEndpoint.fetchAllProdCategory();
    //     return prodCatData;
    // }
}

进一步简化： 考虑到ProductStore.fetchProductCatgeory仅仅是简单地转发了ProductEndpoint.fetchAllProdCategory()的调用，可以考虑在CategoryListRegisterViewStore.loadProductCategory中直接调用Endpoint，从而移除ProductStore中的这个中间方法，进一步简化代码。

Hilla异步数据处理与MobX最佳实践

1. 理解Promise与await： 当调用一个返回Promise的异步函数时，你得到的是一个Promise对象，而不是最终的数据。要获取数据，必须使用await关键字（在async函数内部）来等待Promise解析。
2. vaadin-grid数据绑定： 始终将vaadin-grid的items属性绑定到一个已经包含实际数据的数组（或可迭代对象），而不是一个异步方法或Promise。
3. runInAction的恰当使用： runInAction是MobX中用于确保状态修改在同一个事务中执行的工具，它主要用于同步地修改可观察状态。它不应该用来包裹整个异步操作，尤其不应该用来包裹Promise的返回。异步操作本身（如await）发生在runInAction之外，一旦数据准备就绪，再在runInAction中更新状态。

   async fetchDataAndMutateState() {
       const data = await someAsyncOperation(); // 异步操作在 runInAction 之外
       runInAction(() => {
           this.someObservableState = data; // 在 runInAction 中同步更新状态
       });
   }

   登录后复制
4. 清晰的数据流： 确保从后端Endpoint到前端UI组件的数据流清晰明了。Endpoint返回Promise，Store层处理Promise并更新状态，UI组件绑定到Store中的状态。

总结

解决Hilla应用中Vaadin Grid异步数据绑定问题，关键在于正确理解和处理JavaScript的Promise机制以及Hilla/MobX的数据流。通过确保vaadin-grid绑定的是已解析的数据数组，并在Store中正确使用async/await来等待Promise的解析，同时避免滥用runInAction，可以有效避免Promise<void>等类型错误，构建出健壮且响应迅速的Hilla应用程序。遵循这些最佳实践，将有助于开发者更高效地管理异步数据和状态。

以上就是Hilla应用中Vaadin Grid异步数据绑定与Promise处理指南的详细内容，更多请关注php中文网其它相关文章！