Skip to content

feature: type_from_name #4

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.

Sign up for GitHub

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

Merged
mikkoh merged 4 commits into from
Mar 21, 2017
Merged

feature: type_from_name #4

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
6c835a7
Added function type_from_name to schema
mikkoh Jan 18, 2017
032f461
Implemented creating a lookup table that maps typename to type
mikkoh Jan 18, 2017
64ab007
Removed type_from_name and instead just exposed @types_by_name
mikkoh Mar 20, 2017
775f185
Fixed an issue from merging
mikkoh Mar 21, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions lib/graphql_schema.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,10 @@ def types
@types ||= @hash.fetch('types').map{ |type_hash| TypeDefinition.new(type_hash) }.sort_by(&:name)
end

def types_by_name
Copy link
Copy Markdown
Contributor

@swalkinshaw swalkinshaw Mar 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had misunderstood your question before, I was suggesting exposing a type method:

def type(name)
  types_by_name.fetch(name)
end

Just like what exists in the tests

Copy link
Copy Markdown
Contributor Author

@mikkoh mikkoh Mar 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @dylanahsmith had some good comments here #4 (comment)
It's nice if a hash is exposed because you have all the extra functionality that hashes provide.

As for naming I'm ok calling it whatever.

Copy link
Copy Markdown
Contributor

@swalkinshaw swalkinshaw Mar 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hash can still be exposed. I just think the method adds a nicer API.

Copy link
Copy Markdown
Contributor

@dylanahsmith dylanahsmith Mar 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A previous iteration of this method used would return nil if the type isn't found and now you are proposing the convenience method to raise a KeyError if the type isn't found. I don't think it is clear what the behaviour should be for this convenience method and just using the hash will make it clearer what the behaviour is if the type isn't found.

@types_by_name ||= types.map { |type| [type.name, type] }.to_h
end

module NamedHash
def name
@hash.fetch('name')
Expand Down
5 changes: 5 additions & 0 deletions test/graphql_schema_test.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,6 +134,11 @@ def test_fields_by_name
assert_equal nil, type('QueryRoot').fields_by_name['does_not_exist']
end

def test_type_by_name
assert_equal type('SetIntegerInput'), @schema.types_by_name['SetIntegerInput']
assert_equal nil, @schema.types_by_name['IDoNotExist']
end

def test_description
assert_equal 'Time since epoch in seconds', type('Time').description
assert_nil type('StringEntry').description
Expand Down