search

stockpile-co / api

The API for Stockpile, an app that manages stuff for organizations.
0 stars 1 forks source link

Add a field type to custom fields #294

Closed emroussel closed 7 years ago

emroussel commented 7 years ago

As a user, I want to be able to specify the right type of inputs when using custom fields, So that it is easier to fill the input and have consistent formatting

The types of inputs should be:

AdamVig commented 7 years ago

One solution for this is to create three value columns, one for each type (VARCHAR for text, INTEGER for number, and DECIMAL for money) and then determining which column to get the value from based on a "type" column.

One alternative is to cast the value to string and store the value in a VARCHAR column regardless of the type, then use the "type" column to cast the value back to its appropriate type before sending it. The downside of this is that there may be a loss of accuracy in decimals converted to string. The upside is that the processing step between the database and response would not have to determine which column to use, but instead would simply run a Number.parseInt() (number) or Number.parseFloat() (money) on the value.

It would be useful to store a currency alongside money values. This would require an extra column that should only be sent with responses if the type of the value is money.

Alternatively, the custom field value type column could be VARCHAR and its possible values could be text, number, or a currency, such as usd or euro. It would be simple to write a conditional that uses that value as a currency type if it is not either text or number. The downside of this is that it doesn't feel very relational, and doesn't provide a clean way to add more possible value types.

It would be better for the type column to reference a table of possible custom field value types. That way, new types could easily be added. With this approach, an extra column for currency type would still be required.

emroussel commented 7 years ago

From the front end's perspective, it doesn't really matter how it's implemented as long as there is a type sent with the custom field (it seems better than determining the type based on the value). This way, it'd be easy to determine which type of keyboard to show the user and if there is extra formatting to do (like adding a $ before the number, or rounding at two decimals for currencies).

That being said, in my opinion, having a single column storing the value as a VARCHAR and having another column determining the type seems cleaner than having three different columns.