taylorbrooks / closeio

A Ruby wrapper for the Close.io API
http://developer.close.com
MIT License
45 stars 57 forks source link

Lead is returning hash instead of object #45

Closed zeeshangulzar closed 6 years ago

zeeshangulzar commented 6 years ago

Please follow these steps to regenerate this scenario. client = Closeio::Client.new("api_key") lead = client.find_lead("lead_xxxxxxxxxxxxxx") lead.data

undefined method `data' for #

if we check lead.class it will display Hash. As per this gem documentation we are fetching contact using

lead.data.contacts

It should be an object. Please if you can confirm is it a bug or guide me in right direction If I am wrong.

zeeshangulzar commented 6 years ago

I changed my version to 2.6.10 and it worked as per documentation i.e lead.contacts

taylorbrooks commented 6 years ago

Sorry about that the README docs were outdated as of the 3.x version.

Responses in 3.x return a hash instead of a Hashie::Mash object used previously.

synth commented 4 years ago

Why move from Hashie::Mash to hash? This significantly breaks our integration if we upgrade to 3.x and is preventing us from upgrading until we have a chance to revert to the uglier hash syntax. In fact, its not just dot notation that's an issue. We use symbols as hash keys which worked with Hashie::Mash. Now, Close returns a hash with string keys.

If it's just to remove the dependency on Hashie::Mash, it would be nice to let us opt in as we already have this dependency on our application.

taylorbrooks commented 4 years ago

@synth Yep, it was to remove the dependency. We're following SemVer so it shouldn't be a surprise there are breaking changes.

synth commented 4 years ago

Too bad. This is a regression in usability imo. Also, SemVer doesn't mean that just because you can have breaking changes across major versions, that we should expect them all the time. I didn't see any documentation on this anywhere - so yea, it was a surprise that took digging through this libraries source to figure out.

taylorbrooks commented 4 years ago

Yeah, I could've probably done a release that deprecated Hashie, but still left an option to use it as response middleware. Then fully removed it in the next release -- that would've been a good usability experience.

You're also right there is not any documentation in CHANGELOG.md, I apologize for that and will ensure future releases are documented properly.

I'm trying to think back to my original intent as to why I removed it -- it was two years ago, so hard to remember... I think it was a knee-jerk reaction to these:

Plus my experience in memory bloat in the applications I was maintaining at the time. I know it's not helpful for the situation you're in, but hopefully it provides some context.

synth commented 4 years ago

Gotcha, thanks for the explanation.