Have required and NonNull true by default at the project level
还没有人认领这个 Issue。
评估
调研方向
首先跟踪当前如何为字段和列表查询确定 required 和 NonNull 默认值，然后确定请求中所述的项目级配置入口。明确显式的 required=false 以及 nullable 或可选列表类型应如何覆盖新的默认值，并在将该功能视为完成之前为这些情况添加覆盖。
由索引模型根据 Issue 内容生成。
描述
Is your feature request related to a problem? Please describe.
I'm always frustrated when I have to explicitly set required a List field, or any field for that matter. It makes for really frustrating usage of our APIs that rely on typescript types generated by our graphene schema. We have to constantly add unnecessary checks and write more obtuse code just to satisfy our types. On top of that, the way that this typing is done both in python(pyright and I believe others) and in typescript are the exact opposite, you explicitly define that something can be optional. This makes it extremely unintuitive and hard to spot issues until the api starts getting use from our typescript apps.
Describe the solution you'd like
A setting at the root level to have required default to true always se we have to explicitly set required to false. This would also apply to NonNull for list queries which might need a Nullable, or Optional, or allow the required argument for type to work with the list.
Describe alternatives you've considered
I can build new types that extend the existing types and add a linter to make sure none of the original types are being used in future development. It's doable, and I'll end up doing it, but the solution I'm suggesting doesn't feel that farfetched to put in for others who may have this frustration.
Additional context
In typescript if I want to type as an array I can use Array, or [], and it will be an array, it wont expect null and it wont expect undefined. I have to be explicit if the value is nullable or undefined. Similarly in python, with pyright at least, you also have to be making sure to be explicit that the type is optional or nullable.
I'm at the very least curious why required is defaulted to false in the first place.
- 主要语言
- Python
- 星标
- 8.2k
- 派生
- 818
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
graphql-python/graphene 的其他 Issue
-
🐛 bug
难度 2/5 1-3 小时 新手友好度 72/100
graphql-python/graphene#1389 · 5 条评论 · 2 个 reaction ·
-
难度 4/5 3-5 天 新手友好度 68/100
graphql-python/graphene#1606 ·
-
✨ enhancement
难度 2/5 1-3 小时 新手友好度 38/100
graphql-python/graphene#1601 · 2 条评论 ·
-
✨ enhancement
难度 4/5 3-5 天 新手友好度 42/100
graphql-python/graphene#1600 ·
-
🐛 bug
难度 2/5 1-3 小时 新手友好度 55/100
graphql-python/graphene#1593 ·
查看 graphql-python/graphene 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复
-
难度 2/5 1-2 天 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 7 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
lmstudio-ai/mlx-engine#376 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
pyiron/bagofholding#166 ·