This ticket describes what I think is an architecture bug causing downstream symptoms. Ideally we come to a consensus about how we want to treat these falsy values and possibly split some working tickets off from that.
IP Info prefers to treat all falsy values the same, which is causing problems now that falsy values can come back and are valid values (see {T293639}). There are a few symptoms I've noted while working on IP Info:
- If `null` is returned, it's unclear if it's because the reader wasn't found or the data wasn't found and it's not clear which
- `getProxyType` returns `false` if it's actually `false` in the database but also if it's not found
- non-specific treatment of falsy values gets bubbled to the renderer, where `if ( propertyValue )` is evaluated to determine whether or not the API returned data
Some possible solutions:
- be specific about what `null` and `false` mean and explicitly check `propertyValue === null` in `IpInfoWidget#generatePropertyMarkup`
- throw an error if a reader isn't found*
- don't return values if they don't exist**
*I don't know if we did this intentionally and if we did, why
**The Info type classes are all fairly rigid in what they expect to come back which is why you'll see failures return as `null` in some cases or `[]` in others. I don't know why they don't support "info does not exist" values like `false`
-Add to README.md