🐛 Bug: Update base with `meta` data via API doesn't work about nocodb

[salim-b]

Further observations related to this issue, i.e. how peculiarly NocoDB handles a base's meta field:

• A call to the PATCH /api/v2/meta/bases/{base_id} API endpoint to update a base incl. the meta field succeeds¹ iff

  1. meta is specified as a character scalar instead of an actual JSON object, and
  2. meta.iconColor is included.

  Working example:

  curl -X 'PATCH' \
    'https://api.example.com/api/v2/meta/bases/{baseId}' \
    -H 'xc-token: abcd1234' \
    -H 'Content-Type: application/json' \
    -d '{ "meta": "{\"iconColor\":\"#3f4eff\",\"showNullAndEmptyInFilter\":true}" }'

• The POST /api/v2/meta/bases API endpoint to create a new base OTOH accepts meta as a regular JSON object and the result is properly interpreted by the server AFAICT.

  After creating a new base this way, the GET /api/v2/meta/bases/{base_id} API endpoint to retrieve an existing base returns the meta field as a JSON object (like the rest of the JSON body).

  This is what one would expect.

• When config encoded in the meta field is changed via the NocoDB UI, NocoDB seems to store the updated meta config as a character scalar instead of a JSON object. This can be verified by first creating a new base as outlined above, then changing e.g. the base's icon color and finally calling the GET /api/v2/meta/bases/{base_id} endpoint – the meta field in the response body is now a character scalar (containing valid JSON syntax) instead of an actual JSON object.

  On page reload, NocoDB seems to attempt to parse a base's meta field (and throws a JSON.parse error if that fails for some reason).

Why is handling the meta field implemented in this way (writing and parsing JSON text instead of directly using actual JSON)? Besides making it hard to use NocoDB's RESTful API, this also unnecessarily complicates development, I think.

Footnotes

1. Meaning the result is properly parsed by the server. ↩