Yesterday I fixed an issue where, if a numeric value was passed into the graphql interface via a generic Map type (which is converted into map[string]interface{} in go), it would be persisted in the settings as a string. This meant that that value would be presented back as a string instead of a number.
This was occurring because the graphql processing code would encode these numbers as json.Number, which is internally a string, but could represent an integer or a float. I needed to explicitly convert it into the applicable type based on whether the string contained a . or not.
Strangely enough, I encountered the same bug in the custom fields feature, since it too accepts a generic map, and needs to coerce values into their correct types.
With some valuable user testing, it was reported that it wasn’t possible to create a performer in the custom fields feature branch. It’s rather embarrassing that this isn’t a use case that I tested. 
This was a UI-side issue and occurred because of gaps in the type definitions used in the PerformerEditPanel component. It returns either a PerformerCreateInput or PerformerUpdateInput object. These types have a very similar structure, but the update input accepts either a full or partial set of fields, and the create input accepts just a map of custom fields. I’d made the changes with only the update use-case in mind.
During the testing for these fixes, I noticed a rather glaring usability issue with custom field inputs. See the below screenshot:
If I was to submit this, only the aa field would be saved, since it requires the user clicking the + button to actually persist the value. My justification for this design was so that I could validate the field name value and disable the + button if the field is empty. In this current state, users are going to lose data because of the assumption that the value entered will be persisted.
My current thinking is that the + button should be on its own row, and whatever is entered will be persisted. The initial view should include an empty row (as if the user already clicked the + button. The + button should be disabled if the field field is invalid. It should also be a validation error if the last value field is non-empty but the field is empty.
This really highlights the value of user testing and feedback. I focus on getting the basic functionality in there, but I often don’t spend much time actually using the functionality in a production-like manner.