graphql-laravel
graphql-laravel copied to clipboard
[feat] Improving Code Readability and Usability with `FieldType` Class Integration
Summary
Hello,
In this pull request, I have added the FieldType
class. In the current version, there are instances where incorrect value types, incorrect keys, etc., are defined. Additionally, the IDE does not suggest keys sometimes. For example:
- I often forget the keys for deprecation (
deprecationReason
), selectability (selectable
), and relations (is_relation
). - Sometimes, I mistakenly pass a string instead of an array for the
always
key. - Incorrect relation types are defined.
In the new version, the IDE assists in defining your types. 😉
If this pull request is accepted, I will update the documentation to reflect the new usage.
before:
public function fields(): array
{
return [
'id' => [
'type' => Type::id(),
'description' => 'id of the user',
'resolve' => function ($root, array $args) {
return encoder($root->id);
},
],
'username' => [
'type' => Type::string(),
'description' => 'username of the user',
],
'bio' => [
'type' => Type::string(),
'description' => 'bio of the user',
],
'website' => [
'type' => Type::string(),
'description' => 'website of the user',
],
'first_name' => [
'type' => Type::string(),
'description' => 'first name of the user',
],
'last_name' => [
'type' => Type::string(),
'description' => 'last name of the user',
],
'fullname' => [
'type' => Type::string(),
'description' => 'fullname of the user',
'selectable' => FALSE,
'always' => ['first_name', 'last_name'],
],
'joined_at' => [
'type' => Type::string(),
'alias' => 'created_at',
'description' => 'created date of the reply',
],
'am_i_this_user' => [
'type' => Type::boolean(),
'description' => 'am i this user?',
'alias' => 'id',
'resolve' => function ($root) {
return $root->id == Auth::guard('api')->id();
},
],
'avatar' => [
'type' => GraphQL::type('FileType'),
'always' => ['avatar_id'],
'description' => 'user avatar type',
'is_relation' => TRUE,
],
];
}
after
public function fields(): array
{
return [
FieldType::make()
->id()
->name('id')
->description('id of the user')
->resolve(function ($root, array $args) {
return encoder($root->id);
}),
FieldType::make()
->name('username')
->string()
->description('username of the user'),
FieldType::make()
->name('bio')
->string()
->description('bio of the user'),
FieldType::make()
->name('website')
->string()
->description('website of the user'),
FieldType::make()
->name('first_name')
->string()
->description('first name of the user'),
FieldType::make()
->name('last_name')
->string()
->description('last name of the user'),
FieldType::make()
->name('fullname')
->string()
->description('fullname of the user')
->selectable(FALSE)
->always(['first_name', 'last_name']),
FieldType::make()
->name('joined_at')
->string()
->alias('created_at')
->description('joined at of the user'),
FieldType::make()
->name('am_i_this_user')
->boolean()
->selectable(FALSE)
->description('is this user me?')
->resolve(function ($root, array $args) {
return $root->id == Auth::guard('api')->id();
}),
FieldType::make()
->name('avatar')
->graphQlType('FileType')
->description('user avatar type')
->always(['avatar_id'])
->isRelation(TRUE),
];
}
Type of change:
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [x] This change requires a documentation update
- [ ] Misc. change (internal, infrastructure, maintenance, etc.)
Checklist:
- [ ] Existing tests have been adapted and/or new tests have been added
- [ ] Add a CHANGELOG.md entry
- [ ] Update the README.md
- [x] Code style has been fixed via
composer fix-style
From a brief look, looks interesting!
Will get back once I've more time.
hello @mfn
Thank you for taking a look at the proposed changes! I'm glad you find them interesting. To streamline the process and make sure we're aligned, I suggest we create a todo list to handle the remaining tasks together. This could include tasks like updating the documentation, refining the examples, and thoroughly checking the input of the builder class for each type.
If you find that you need more time, I'm more than happy to assist in finalizing this change. Just let me know how I can help, and we can collaborate to ensure everything is in place. Looking forward to working together on this PR.