我正在使用一个TypeScript和GraphQL系统，其中一些GQL请求的结果可以通过用户对系统的权限级别进行修改。我们将以引号和行项的简化视图为例。
用户可以请求查看报价，报价的一部分是包含价格和数量的一组行项目。有些用户可以看到价格，有些则看不到。目前我们通过允许大多数字段为空来管理这里的可选性。但事实证明，这很难管理，也不能很好地代表整个系统。我们希望使用TypeScript和GraphQL类型系统对我们更有帮助，更能代表系统。
我们的一个想法是创建类型来表示可以在每个权限级别返回的数据。例如,
interface LineItemWithPricing {
id: string;
name: string;
description: string;
cost: number;
taxable: boolean;
quantity: number;
}
interface LineItemWithoutPricing {
id: string;
name: string;
description: string;
quantity: number;
}
... (there's more to a line item than this and other combinations of fields are possible)
type LineItem = LineItemWithPricing | LineItemWithoutPricing | <other options>;
(我们可以对Pick和Omit等做一些事情来共享结构，但为了清晰起见，我省略了它。)
我的主要问题是，对于可以通过权限级别修改数据值和API返回类型的系统，使其成为类型系统的一部分似乎是一个明智的选择。有更标准的表示方法吗?还有更好的选择吗?
我们已经实现了一些类型选项，当然可以使用像这样的类型集来表示我们的系统。最大的未知数是我们是否会遇到长期维护问题。
不——我使用过类型化和非类型化语言——类型本质上加强了业务规则和清晰度。这样想，如果你的类型系统有问题，你的应用生成的数据也会有问题。随着组织的发展，类型只会在您的专有代码库中作为软件特性而变得越来越重要。所以，以后再谢谢我
在软件中几乎总是有更好的选择——一个是在数据栈的最底层(通常是DB层)强制执行业务逻辑——结合类型将给你一个强大的组合，导致更好的生成数据