-
Notifications
You must be signed in to change notification settings - Fork 15
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 Vertex, TaxJar, Avalara #59
Add Vertex, TaxJar, Avalara #59
Conversation
oliverheywood451
commented
Feb 1, 2022
- VertexOCIntegrationCommand.cs with two methods for calculating tax. The functionality of the actual integration. Also lots of models and mappers.
- 4 general exceptions to handle various types of errors inside an integration
- A guide for adding integrations, a table with a list of integrations, and guide specifically for the vertex integration
- Unit tests that mock vertex api responses using flurl
library/OrderCloud.Catalyst/Integrations/Exceptions/IntegrationAuthFailedException.cs
Outdated
Show resolved
Hide resolved
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.
Hi @oliverheywood451, please check the comments and let me know if we need a separate call, thank you in advance!
library/OrderCloud.Catalyst/Integrations/Exceptions/IntegrationErrorResponseException.cs.cs
Outdated
Show resolved
Hide resolved
library/OrderCloud.Catalyst/Integrations/Exceptions/IntegrationNoResponseException.cs.cs
Outdated
Show resolved
Hide resolved
public static VertexCalculateTaxRequest ToVertexCalculateTaxRequest(this OrderWorksheet order, List<OrderPromotion> promosOnOrder, string companyCode, VertexSaleMessageType type) | ||
{ | ||
var itemLines = order.LineItems.Select(li => ToVertexLineItem(li)); | ||
var shippingLines = order.ShipEstimateResponse.ShipEstimates.Select(se => |
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.
What do you think of avoiding using the var
? Because it's not clear for reviewers which type is it and decreases the speed of reading and understanding the code. The IEnumerable gives more information in this case :)
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.
Using var
is a pattern that's pretty engrained in me from all the C# projects at four51. I do see how it makes reviewing code hard if you're not viewing in the VS editor (where hovering shows you the type).
I'm willing to consider this. It would be a rather large code change throughout the project. Do you know what the OC platform code does? That's often what we model these other tools on.
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.
My personal opinion is to use it only if the type can't be easily inferred by its context/usage. Adds a lot of clutter which in my opinion actually makes it harder to read (more mental load) and is unnecessarily verbose in many situations
ie:
Car car = new Car();
library/OrderCloud.Catalyst/Integrations/Implementations/Vertex/Mappers/VertexRequestMapper.cs
Outdated
Show resolved
Hide resolved
library/OrderCloud.Catalyst/Integrations/Implementations/Vertex/Mappers/VertexRequestMapper.cs
Outdated
Show resolved
Hide resolved
library/OrderCloud.Catalyst/Integrations/Implementations/Vertex/Mappers/VertexRequestMapper.cs
Outdated
Show resolved
Hide resolved
library/OrderCloud.Catalyst/Integrations/Implementations/Vertex/Mappers/VertexRequestMapper.cs
Outdated
Show resolved
Hide resolved
{ | ||
public class VertexCalculateTaxRequest | ||
{ | ||
public string saleMessageType { get; set; } |
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.
Just curious, why do we have the public properties which start with a lower case? Do we have a code notation standard for the OC Catalyst?
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.
They are lowercase because when they are serialized to JSON they need to be lower case to match the property names the Vertex API is expecting.
We don't have a code notation standard for the OC Catalyst - I can create an issue for that. If you want to work on it that would be awesome.
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.
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.
If we really cared, we could use JsonProperty to determine how something is serialized. For example
[JsonProperty("saleMessageType")]
public string SaleMessageType {get; set;}
But it seems like an abstraction just for the sake of abstraction. I personally like that the property names match exactly what the vertex properties are.
library/OrderCloud.Catalyst/Integrations/Implementations/Vertex/Models/VertexException.cs
Outdated
Show resolved
Hide resolved
library/OrderCloud.Catalyst/Integrations/OCIntegrationConfig.cs
Outdated
Show resolved
Hide resolved
…an intermediate model. unit tests are broken now.
…iuations call for different account credentials.