Load unknown REST resource attributes from data #920
Conversation
| @@ -8,496 +16,499 @@ | |||
|
|
|||
| ## Version 9.5 | |||
|
|
|||
| * [#883](https://github.com/Shopify/shopify_api/pull/883) Add support for Ruby 3.0 | |||
| - [#883](https://github.com/Shopify/shopify_api/pull/883) Add support for Ruby 3.0 | |||
There was a problem hiding this comment.
Everything after this line is just linting auto-fixes to the changelog, please ignore!
lib/shopify_api/rest/base.rb
Outdated
| clean = var.to_s.gsub(/[\?\s]/, "") | ||
| @aliased_properties[var.to_s] = clean if clean != var |
There was a problem hiding this comment.
Some of the fields returned by the API have special characters in them - I don't love this solution, but I couldn't figure out a better way of cleaning up the instance attributes.
There was a problem hiding this comment.
i get it, i also dont like it, but i also couldnt figure out another solution :high-five:
There was a problem hiding this comment.
LGTM
I'm having a hard time reading through some of these methods now that I've forgotten what a resource looks like. I wonder if it makes sense to unit test some of these methods as a way of documentation? For example, I had a hard time seeing what create_instance takes in as data or what to expect method_missing does.
(this seems outside of the scope of this PR)
I think it may. Those methods are all indirectly tested by our suite, but if they're hard to grok having a test is probably useful. |
paulomarg
force-pushed
the
load_unknown_attributes
branch
from
b591c6f
to
239606d
Compare
Description
Sometimes, the API will send back data that's not exactly as documented, such as the
optionXfields in products / variants - those are documented asoption, but they dynamically accept any number of options.The current code only accepts fields that are in the "expected" set when loading API data, but in cases like the above, we should just take whatever the API is sending our way.
How has this been tested?
Via a new unit test.
Checklist: