ChilliCream / ChilliCream/graphql-platform
DefaultFieldBindingFlags.Default filtering and sorting inherit via ObjectType
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 5.8k
- Forks
- 810
- Avg merge
- 15h 39m
- Merged PRs (30d)
- 98
Description
Product
Hot Chocolate
Is your feature request related to a problem?
I like the concept of allowing you to override the DefaultFieldBindingFlags to define which members will be by inferred as GraphQL fields. I tend to use the Default option to allow me to opt-into what fields I want to expose via the api. It's saved me a lot of time needing to create a whole heap of DTOs then remembering to project to them, where I can rely upon the ObjectType descriptors which come with a lot more flexibility.
The issue I'm running into is that I've got a basic schema setup, it exposes a single User entity where in the ObjectType I just want to expose their basic fields (id, name), I don't want to expose fields such as their password, email etc. It does the job and only includes those fields that I have defined, the catch is that I can filter and sort via fields that I have not exposed via the ObjectType. I don't want to allow users to filter or sort by these fields (eg; finding users via an email address).
The solution you'd like
I was hoping that the FilterInputType and SortInputType types that are generated would be based on the fields exposed via the ObjectType, or at least have an easy way to opt-into something like this.
If I were then want to exposes a field to sort or filter on that is not exposed via the ObjectType, I could then override the FilterInputType or SortInputType and specify it there. Instead I'm needing to do the opposite, and always override the filter and sort types to ignore each field that's not exposed in the ObjectType.
I know you can set the DefaultBindingBehavior to Explicit, then define what fields are filterable, sortable etc, although in almost all cases anything that's exposed via the ObjectType I want to be able to sort and filter on, it's creating a lot of boilerplate I was hoping to avoid. It's also prone to inconsistencies or issues if you were to remove or add a field to the ObjectType and forget to add or remove it from the corresponding sort and filter types.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how FilterInputType and SortInputType are generated from the ObjectType descriptor and how DefaultFieldBindingFlags.Default is applied. The change is complete when generated filter and sort fields follow the fields exposed by ObjectType, while explicit FilterInputType and SortInputType overrides can still add fields.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100