Closed remy727 closed 11 months ago
Good idea 👍
What happened with this? Is it still the same argument in that Struct is fast and OpenStruct is slow? Is it really just that choice? It seems like we'd never alter the results, just consume them, so Struct does make sense and is faster?
Just a quick question on this, that has come into play a few times. Sometimes you have to return Struct attributes that have no value. As in
source: edge.node.featuredImage&.source
So when consuming this in a Ruby sense, we'd end up with data.source perhaps being nil. Which is fine. But checking on nil is a thing, and then there is straight-up returning an empty string, which can be useful. Or a default value. So for example, say you wanted to return some default image here in the struct.
How do you look at that? I like the code! I am just finding that when I use it a lot, I run into these issues and they grow out into support code that becomes almost indispensable. Any thoughts?
I think you can use ||
operator.
source: edge.node.featuredImage&.source || default_image
@kirillplatonov, this is ready for review. I also tested and all passed.
@remy727 I dived a bit deeper into this idea. The majority of OpenStruct
use is happening during Graphql response parsing:
JSON.parse(response.body.to_json, object_class: OpenStruct)
https://github.com/kirillplatonov/shopify_graphql/blob/main/lib/shopify_graphql/client.rb#L20
Unfortunately, switching parser object class to Struct
is not possible as it will lead to TypeError: allocator undefined for Struct
error. And I don't know how to implement auto-conversion of responses without OpenStruct
.
With this in mind, changing OpenStruct
to Struct
in response wrappers doesn't makes much sense. It will decrease code readability without significant performance impact.
@kirillplatonov, that makes sense. Thanks for diving into it.
Motivation / Background
Struct
is faster thanOpenStruct
generally.