You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactoring resource interface into Hubspot::Resource (#176)
* WIP: Refactoring resource interface into Hubspot::Resource
* Add support for paged collections
* Add recently created and modified to company
* Add support for fetching and adding contacts to a company
* Support removing contacts from a company
* Add batch update to companies
* Replace Company with the resource implementation
* Update Contact2 with new methods
* Add FactoryBot for generating fixtures
* Rework new method and add tests for base resource class
* Lots of updates and tests for Company and Contact
* Fix delegate_missing_to to work with older activesupport versions
* Add Contact search support
* Add merge support for Contact
* Replace old Contact with new Contact resource
* Update methods to return success
* Update the README with the new resource API
@@ -108,49 +108,159 @@ At this time, OAuth tokens are configured globally rather than on a per-connecti
108
108
109
109
## Usage
110
110
111
-
Here's what you can do for now:
111
+
Classes have been created that map to Hubspot resource types and attempt to abstract away as much of the API specific details as possible. These classes generally follow the [ActiveRecord](https://en.wikipedia.org/wiki/Active_record_pattern) pattern and general Ruby conventions. Anyone familiar with [Ruby On Rails](https://rubyonrails.org/) should find this API closely maps with familiar concepts.
**Note:** Hubspot uses a combination of different names for the "ID" property of a resource based on what type of resource it is (eg. vid for Contact). This library attempts to abstract that away and generalizes an `id` property for all resources
**Note:** Unlike ActiveRecord in Rails, in some cases not all properties of a resource are known. If these properties are not returned by the API then they will not have a getter method defined for them until they've been set first. This may change in the future to improve the user experience and different methods are being tested.
3: from /home/chris/projects/hubspot-ruby/bin/console:20:in `<main>'
196
+
2: from (irb):2
197
+
1: from /home/chris/projects/hubspot-ruby/lib/hubspot/resource.rb:215:in `method_missing'
198
+
NoMethodError (undefined method `name' for #<Hubspot::Company:0x0000561d0a8bdff8>)
199
+
200
+
irb(main):003:0> company.name = "Foobar"
201
+
=> "Foobar"
202
+
203
+
irb(main):004:0> company.name
204
+
=> "Foobar"
132
205
```
133
206
134
-
### Update a contact
207
+
### Collections
135
208
136
-
Given an instanceof `Hubspot::Contact`, update its attributes with:
209
+
To make working with API endpoints that return multiple resources easier, the returned instances will be wrapped in a collection instance. Just like inRails, the collection instance provides helper methods for limiting the number of returned resources, paging through the results, and handles passing the options each time a newAPI call is made. The collection exposes all RubyArray methods so you can use things like `size()`, `first()`, `last()`, and`map()`.
**Note:**These are the currently defined classes the support the new resource API. This list will continue to grow as we update other classes. All existing classes will be updated prior to releasing v1.0.
260
+
261
+
*Contact->Hubspot::Contact
262
+
*Company->Hubspot::Company
263
+
154
264
## Contributing to hubspot-ruby
155
265
156
266
*Check out the latest master to make sure the feature hasn't been implemented or the bug hasn't been fixed yet.
0 commit comments