ChilliCream / ChilliCream/graphql-platform

DefaultFieldBindingFlags.Default filtering and sorting inherit via ObjectType

Open
#6,314 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

🌶️ hot chocolate Area: Data
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.