Parsing strings

Question Given that the Alpaca API provides dates and numbers as strings, where do you feel the responsibility lies for parsing those values?

Background Right now this package provides types that match the Alpaca API 1:1. For example, in Account, we have buying_power, which is a string. From the developer’s perspective, this is nice because there are no surprises. I can look at the Alpaca Docs and trust that this package will provide me data in the same fashion.

If I want to use buying_power, I need to safely convert it to a number. From a typing perspective, we would ideally have two types: one that matches the Alpaca API and one that has numbers and dates parsed. This package provides the former, but I’m curious about the latter.

Right now I’m basically wrapping your client and doing the mapping myself. For example, I have an AccountParsed type which extends Account and has buying_power_num: number.

Since everyone has to do this, I feel that it should be shared. I would love your feedback this because I’m not sure if it belongs here or in a separate package.

[117]

@KalebMills @lbstr I have been testing the github:117/alpaca#dev version on paper for the last two days, haven’t run into any bugs.

[KalebMills]

Just ran into this issue as well. It seems rather odd that the value return from the Alpaca API for the buying_power property of the account is a string. I’m glad we are handling this in this package. Great job!