Skip to content
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

Added get list of contact lists #63

Merged
merged 8 commits into from
Jan 14, 2021
Merged

Added get list of contact lists #63

merged 8 commits into from
Jan 14, 2021

Conversation

davymirfin
Copy link
Contributor

@davymirfin davymirfin commented Jan 12, 2021

To request a contact list prior to this change it was necessary to know the list's listId. This change enables the API user to discover which lists are available - the information it returns about each list does not include the lists' contents but it does include their names and listIds along with other information about each of the lists.

This is the functionality that this change implements:
https://legacydocs.hubspot.com/docs/methods/lists/get_lists

Closes #62

Copy link
Contributor

@nover nover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

praise overall I think it looks good - and thanks for your first PR here on this repo.

There's a few suggestions and issues I think we should get resolved before merging.

src/ListOfContacts/Dto/ListOfContactListsHubSpotEntity.cs Outdated Show resolved Hide resolved
src/ListOfContacts/Dto/ListOfContactListsHubSpotEntity.cs Outdated Show resolved Hide resolved
src/ListOfContacts/Dto/ListOfContactListsHubSpotEntity.cs Outdated Show resolved Hide resolved
src/ListOfContacts/Dto/ListOfContactListsHubSpotEntity.cs Outdated Show resolved Hide resolved
Add DataMember attributes, use PascalCase for names and replace generic names with more specific ones to avoid confusion - these are recomendations of @nover
Change DateTime properties to string because deserialization of .NET type DateTime in WCF requires some more work e.g. the use of attributes [IgnoreDataMember], [OnSerializing] and [OnDeserialized] along with a private property - see https://stackoverflow.com/questions/18511147/change-default-date-serialization-in-wcf. String datestamps can be easily translated to DateTime explicitly by the caller as necessary. Adding DataMember attributes revealed the problem of deserialization of the DateTime properties (but not before runtime) - it caused exceptions where as without the DataMember attribute, the deserialization failure was not notified.
@davymirfin
Copy link
Contributor Author

I think this covers all the changes requested by @nover.
The property "MetaData" remains in the class ContactListsItem but I have changed its type to ContactListsMetaData. I hope that is sufficient to remove ambiguity.

@davymirfin davymirfin closed this Jan 13, 2021
@nover nover reopened this Jan 13, 2021
Copy link
Contributor

@nover nover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good now. Some functional tests and documentation would also be great but those can be added later via another PR.

Copy link
Contributor

@nover nover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, just now noticed that the CreatedAt is a string rather than a DateTime.

What's keeping us from using a proper DateTime ? @davymirfin

@davymirfin
Copy link
Contributor Author

Sorry, just now noticed that the CreatedAt is a string rather than a DateTime.

What's keeping us from using a proper DateTime ? @davymirfin

After adding the renaming DataMember attributes I got a runtime error for each of the DateTime properties. I guess it revealed a problem that had always been there but never noticed in my testing. The value comes across as a "ticks" string. I refer to the problem here:
6570617

I think I must have always used default DateTime serialization/deserialization in the past - I don't remember having problems.

I know how to fix it. There are suggestions in this link:
https://stackoverflow.com/questions/18511147/change-default-date-serialization-in-wcf

So a solution would be something like this:

[IgnoreDataMember]
public DateTime? CreatedAt { get; set; }

[DataMember(Name = "createdAt")]
private string createdAtDateString { get; set; }

[OnSerializing]
void OnSerializing(StreamingContext context)
{
if (this.CreatedAt == null)
this.createdAtDateString = "";
else
this.createdAtDateString = this.createdAt.Ticks.ToString();
}

[OnDeserialized]
void OnDeserializing(StreamingContext context)
{
if (this.createdAtDateString == null)
this.CreatedAt = null;
else
this.CreatedAt = new DateTime(this.UpdateDateString);
}

Do you know of a better way to to it (I know I can use the getter/setter approach that is also described in the stackoverflow article)?

Anyway, to avoid the added complexity I decided to make the properties strings (whose value is the image of the ticks value) and worry about type conversion in the client call. Do you want me to fix it?

@nover
Copy link
Contributor

nover commented Jan 14, 2021

Okay I see - do you have an example response from HubSpot we could have a look at?

edit
just checked the documentation you linked to, it seems like they are sending the dateTimes back as unix epoc timestamps. Then I would suggest changing the prop to long CreatedAtTimeStamp to make it clear to consumers that it is a unix timestamp.

Then one can use DateTimeOffset.FromUnixTimeSeconds to get back a DateTimeOffset/DateTime:
https://docs.microsoft.com/en-us/dotnet/api/system.datetimeoffset.fromunixtimeseconds?view=net-5.0

@davymirfin
Copy link
Contributor Author

Okay I see - do you have an example response from HubSpot we could have a look at?

edit
just checked the documentation you linked to, it seems like they are sending the dateTimes back as unix epoc timestamps. Then I would suggest changing the prop to long CreatedAtTimeStamp to make it clear to consumers that it is a unix timestamp.

That is a super suggestion - very quick and very safe.

This is an example of the JSON that comes back from HubSpot incidentally:

{
"offset": 100,
"lists": [{
"portalId": 9153870,
"listId": 1,
"internalListId": 1,
"createdAt": 1610455208290,
"updatedAt": 1610455208290,
"name": "TestListCreatedInPortal",
"listType": "STATIC",
"authorId": 13042916,
"filters": [
[{
"operator": "EQ",
"filterFamily": "PropertyValue",
"withinTimeMode": "PAST",
"type": "string",
"property": "hs_email_domain",
"value": "primasoftware.co.uk"
}]
],
"metaData": {
"size": 2,
"lastSizeChangeAt": 1610455222439,
"processing": "DONE",
"lastProcessingStateChangeAt": 1610455222400,
"error": "",
"listReferencesCount": null,
"parentFolderId": null
},
"archived": false,
"teamIds": [],
"dynamic": false
}],
"has-more": false
}

…ged each of their names to inclide the postfix "TimeStamp" to imply to the user that unix epoch is the value.
@davymirfin
Copy link
Contributor Author

Then one can use DateTimeOffset.FromUnixTimeSeconds to get back a DateTimeOffset/DateTime:
https://docs.microsoft.com/en-us/dotnet/api/system.datetimeoffset.fromunixtimeseconds?view=net-5.0

I've made the change and commited it.
d085ce9

Copy link
Contributor

@nover nover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯

@nover nover merged commit 016fda1 into skarpdev:master Jan 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Get list of all contact lists
2 participants