[Feat]: Define Consts for Well-Defined Values

[c9845]

Feature Request Is New

• [X] I have verified that the requested feature does not already exist or has not already been requested.

Description of the feature

Certain fields require one of a few specific, well-defined by Easypost, values. For example, the incoterm field must be one of the following ("EXW", "FCA", "CPT", "CIP", "DAT", "DAP", "DDP", "FAS", "FOB", "CFR", and "CIF"). Currently the fields in structs just accept a string that can be one of the previously provided options or something incorrect.

Defining const would reduce the chances of users of providing unacceptable values since the user would use a const instead. This reduces typos, as well as the need to go back-and-forth between code and the API docs. Code editors would also be able to provide auto-completion hints based on the type of a struct field and the consts defined for that type.

This would not break existing code that uses strings to provide the value. The types defined as type t string would still accept "string" values instead of the consts.

Some places where this would be applicable:

• incoterm ("EXW", "FCA", "CPT", "CIP", "DAT", "DAP", "DDP", "FAS", "FOB", "CFR", and "CIF")
• label_format ("PNG", "PDF", "ZPL", and "EPL2")
• payment.type ("SENDER", "THIRD_PARTY", "RECEIVER", "COLLECT")
• duty_payment.type ("THIRD_PARTY", and "RECEIVER")
• dropoff_type (maybe prefix the const names with FedEx as applicable).
• deliver_confirmation
• ...

Example:

//Define the type.
type incoterm string

//Define list of consts, with comments on separate previous line for code-editor hints, as needed...
const (
  IncotermEXW incoterm = "EXW"
)

//Modify the struct type definition...
type ShipmentOptions {
  //...
  Incoterm incoterm `json:"incoterm,omitempty"`
  //...
}

Use as...

s :=easypost.ShipmentOptions{
  Incoterm: easypost.IncotermEXW,
}

This still works...

s :=easypost.ShipmentOptions{
  Incoterm: "EXW",
}

[nwithan8]

Hello, thanks for the suggestion!

We've been exploring the ideas of using constants/enums in our client libraries for common values as you've suggested. It's good to know that some of our end-users would clearly benefit from their inclusion.

We'll keep you updated on our progress!