Skip to content

Discrepancy, minor mistake, and inconsistency in the documentation and between similar functionnality #145

@lionel-bijaoui

Description

@lionel-bijaoui

radios's radiosOptions is mandatory but flexible, and checklist is optional but strict.

While checklist support values as an array of string or an array of objects, radios only support the object format if radiosOptions is defined.
If you forget to add radiosOptions:

TypeError: this.schema.radiosOptions is undefined

What should be going on here in my opinion:

  • both radios and checklist should take simple array or array of objects as values (name for display and value for internal/model value)
  • both radios and checklist should have options (radiosOptions and checklistOptions) to define the name of each key used by the object

Also when using the object the documentation say that it should save only the id in the model, but it save everything:

// what it does
"checklistlistbox":
[
    {
        "name": "Javascript",
        "value": "Javascript-123"
    }
]
// instead of what the doc say it should do
"checklistlistbox": ["Javascript-123"]

None of this is very bad by itself, but I think core fields should be more coherent in their options and functionalities. It will help users and it will help us making unit test without headaches.

So what should be the basic behavior of these kind of fields ? ***Options mandatory to use array of object ? Basic array and array of objects (with name and value) available, and only use ***Options to customize the name of keys ?

If you have found other small problems like those, please leave a comment !
We should fix them before the v2.0.0

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions