-
Notifications
You must be signed in to change notification settings - Fork 256
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.
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
Add update on classes #125
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -151,7 +151,7 @@ def batch_update!(companies) | |
end | ||
Hubspot::Connection.post_json(BATCH_UPDATE_PATH, params: {}, body: query) | ||
end | ||
|
||
# Adds contact to a company | ||
# {http://developers.hubspot.com/docs/methods/companies/add_contact_to_company} | ||
# @param company_vid [Integer] The ID of a company to add a contact to | ||
|
@@ -165,6 +165,18 @@ def add_contact!(company_vid, contact_vid) | |
}, | ||
body: nil) | ||
end | ||
|
||
# Updates the properties of a company | ||
# {http://developers.hubspot.com/docs/methods/companies/update_company} | ||
# @param vid [Integer] hubspot company vid | ||
# @param params [Hash] hash of properties to update | ||
# @return [Hubspot::Company] Company record | ||
def update!(vid, params) | ||
params.stringify_keys! | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need to call There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Seems unnecessary as it looks like |
||
query = {"properties" => Hubspot::Utils.hash_to_properties(params, key_name: "name")} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Interesting, I've only looked at a handful of examples but it seems the HubSpot v1 endpoints use "property" and the v2 endpoints use "name". Good to know. |
||
response = Hubspot::Connection.put_json(UPDATE_COMPANY_PATH, params: { company_id: vid }, body: query) | ||
new(response) | ||
end | ||
end | ||
|
||
attr_reader :properties | ||
|
@@ -185,8 +197,7 @@ def [](property) | |
# @param params [Hash] hash of properties to update | ||
# @return [Hubspot::Company] self | ||
def update!(params) | ||
query = {"properties" => Hubspot::Utils.hash_to_properties(params.stringify_keys!, key_name: "name")} | ||
Hubspot::Connection.put_json(UPDATE_COMPANY_PATH, params: { company_id: vid }, body: query) | ||
self.class.update!(vid, params) | ||
@properties.merge!(params) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think this is a blocker for this PR since we didn't have this behavior already but we're only updating the properties with the changes from Thoughts? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Interesting catch 🎣 I agree that this isn't a blocker for this PR. Based on your description, I'm imagining something like:
** Updated ** There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As noted by @fonji below, the HubSpot just returns a 204 so there isn't really anything in the response to refresh from is there? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The Hubspot APIs are inconsistent with their return results from updates. Some only return a 204, some return a partial record with the changed fields, and others return the entire record. I’ve mostly worked this functionality out on the master branch but I’ve not yet pushed it since I didn’t finish the tests yet. |
||
self | ||
end | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -163,6 +163,14 @@ def merge!(primary_contact_vid, secondary_contact_vid) | |
body: { vidToMerge: secondary_contact_vid } | ||
) | ||
end | ||
|
||
# Updates the properties of a contact | ||
# {https://developers.hubspot.com/docs/methods/contacts/update_contact} | ||
# @param params [Hash] hash of properties to update | ||
def update!(vid, params = {}) | ||
query = {"properties" => Hubspot::Utils.hash_to_properties(params.stringify_keys!)} | ||
Hubspot::Connection.post_json(UPDATE_CONTACT_PATH, params: { contact_id: vid }, body: query) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not consistent with the other added There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem is that this endpoint
https://developers.hubspot.com/docs/methods/contacts/update_contact So if you want to return a new instance, you'd have to fetch it, which makes two calls instead of one. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @fonji Good point. For reasons like this, I think we are headed in the direction of always returning a |
||
end | ||
end | ||
|
||
attr_reader :properties, :vid, :is_new | ||
|
@@ -197,8 +205,7 @@ def is_new=(val) | |
# @param params [Hash] hash of properties to update | ||
# @return [Hubspot::Contact] self | ||
def update!(params) | ||
query = {"properties" => Hubspot::Utils.hash_to_properties(params.stringify_keys!)} | ||
Hubspot::Connection.post_json(UPDATE_CONTACT_PATH, params: { contact_id: vid }, body: query) | ||
self.class.update!(vid, params) | ||
@properties.merge!(params) | ||
self | ||
end | ||
|
This file was deleted.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit trivial but what do you think of calling this method
update
without the!
? I tend to avoid the use of!
unless there is a safe version of the function. For example,stringify_keys!
has the alternativestringify_keys
.I find that avoiding defining bang (!) methods leads to more descriptive function names. Since
!
is a rather debated topic, I find it's use doesn't hold much value, except in the event where!
means there's an alternative option.Better Naming example: Sending an invite email to a user. Instead of writing
invite!
to warn the reader something will happen,send_invite
is a clearer message that informs the reader that an invite will be sent.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other classes in the gem seem to use the
!
on persistence style method calls. I was assuming this was following the ActiveRecord convention of bang versions of persistence methods raising exceptions whereas the non-bang version returns true/false.