#146: Fixed key error for gender when parsing user json#147
Conversation
|
Can we adopt this approach for most of the JSON fields? How many of these fields, which are currently treated as required, are necessary for the library's logic? Maybe we should treat any fields that can be treated optionally as optional so we don't run into this issue every time Tidal makes a field optional (or removes it). |
Totally agree. |
Good idea, if we can determine what fields are optional (i.e. fields that may or may not be filled out by the user). In case a field is removed by TIDAL, it should definitely be removed. Fields that can be determined as optional (eg. gender) should have a sensible default value. Otherwise, how can we know if the field is actually initialized or not? |
|
I'm all in for having sensible defaults for API fields that are actually optional. Unfortunately, I'm not sure if anyone here knows the unofficial Tidal API well enough to say which fields are actually optional - or are going to be optional in the near future 😄 If it's ok for you folks I'm going to merge this PR as it would at least fix things on master, and we can then open a separate discussion on figuring out which fields may be likely to break/become optional in the future. |
Agreed, I have made a new issue for this purpose. |
Added a patch for the following issue: #146
It seems that the JSON object returned by the Tidal API not longer contains the gender, maybe because it's not set in the user profile. It could make sense to use the
getmethod for other keys, to mitigate this problem for the case, that data is missing in the JSON return object. For example newsletter, dateOfBirth...