Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: ability to attach custom attributes to field definitions. #1671

Open
Warxcell opened this issue Feb 16, 2025 · 3 comments · May be fixed by #1672
Open

Feature: ability to attach custom attributes to field definitions. #1671

Warxcell opened this issue Feb 16, 2025 · 3 comments · May be fixed by #1672

Comments

@Warxcell
Copy link
Contributor

Warxcell commented Feb 16, 2025

Hey, I'm writing custom Executor, optimized for my needs (basically I need per coordinate cache) - so my idea is to attach custom cache resolver which will be called prior original one to check from cache. The issue is that it's very hard to do that - because I need to fork basically whole lib - it would be awesome if it's possible to attach custom attributes to field definition so I can check them later in my custom Executor.

Or even better - if we can incorporate that cache into ReferenceExecutor ?

What do you think?

@spawnia
Copy link
Collaborator

spawnia commented Feb 17, 2025

it would be awesome if it's possible to attach custom attributes to field definition

You can, the array $config passed in \GraphQL\Type\Definition\FieldDefinition::__construct is stored in a public property unchanged.

I don't really understand what else you are describing.

@Warxcell
Copy link
Contributor Author

Its fine, but there are 2 issues

  1. That array is not transferred during SchemaExtend - everything else besided known props for the graphql are lost.
  2. The config itself is strongly typed with specific keys - so phpstan will complain that custom indexes doesn't exists.

@spawnia
Copy link
Collaborator

spawnia commented Feb 17, 2025

Perhaps you can propose a pull request to fix 1.? And in regards to 2., strong typing won't be possible either way - you can ignore PHPStan errors though.

@Warxcell Warxcell linked a pull request Feb 17, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants