Recap on up-to-date priorities

[tcompa]

• Can we decrease font size a bit? For now (at least until we have a better solution for not showing whole descriptions), it would help to make the page content a bit lighter and give less of a text-wall feeling.
• Update internal args data upon save #215 is still there (but @rkpasia says he knows the fix)
• We are not planning to fully fix Discussion about null vs [] (for arrays and objects in task arguments) #209 now, but there is at least one issue that is currently blocking - see below.
• Fixing Display key, for key-value items in object arguments #201 would be very useful.
• Fixing For arguments defined via definitions, show the correct description #198 would be very useful.

---

Re: #209

Consider this schema:

{
            "title": "NapariWorkflowsInput",
            "description": "A value of the ``input_specs`` argument in ``napari_workflows_wrapper``.",
            "type": "object",
            "properties": {
              "type": {
                "title": "Type",
                "enum": [
                  "image",
                  "label"
                ],
                "type": "string",
                "description": "Input type (supported: ``image`` or ``label``)."
              },
              "label_name": {
                "title": "Label Name",
                "type": "string",
                "description": "Label name (for label inputs only)."
              },
              "channel": {
                "$ref": "#/definitions/Channel",
                "description": "Channel object (for image inputs only)."
              }
            },
            "required": [
              "type"
            ]
          }

where channel is not required.
When we prepare the payload for the server, if the user does not enter any attribute for channel, then the (unstripped) data have channel={}. This leads to errors downstream, because later on the fractal tasks try to validate the channel content ({}) and it is not valid (because it lacks some required arguments). Note that ajv does not complain, and lets the validation go through. This is because this kind of "validation" is Python-only, and it is not part of the JSON Schema.

Question: can we modify our removeEmptyObjectsAndArrays function (the one leading to stripped data to be sent to the server) and make sure that all empty objects {} are replaced by null, and then stripped from args. This should happen recursively, and not only for first-level arguments.

I would say that the same behavior is expected for empty arrays [].

Current status:

fractal-web/src/lib/components/common/jschema/schema_management.js

Lines 388 to 402 in 628107e

	/**
	* Remove empty objects and arrays from an object and its nested objects
	* @param obj
	* @returns {*}
	*/
	function removeEmptyObjectsAndArrays(obj) {
	Object.keys(obj).forEach(key => {
	if (obj[key] && typeof obj[key] === 'object') {
	// Next line would enable removing empty objects and arrays from nested objects
	// removeEmptyObjectsAndArrays(obj[key]);
	if (Object.keys(obj[key]).length === 0) delete obj[key];
	}
	});
	return obj;
	}

I currently don't remember why we commented the line enabling recursive behaviors. I am not aware of any tasks where we typically want to pass an empty object or array and that should be preferred over a null.

[jluethi]

Sounds great, fully agree with these priorities!

If we have those, finding additional ways to make the nested parameters take less space would be great! Smaller descriptions, descriptions that are hidden by default (or only show e.g. first 10 words), some iterations on layout given e.g. the Create OME Zarr task would all be great. We can deploy without, but let's iterate a bit on the display of it :)