This task serves to define how should the Editing form component of //Community configuration 2.0// project work like. For a high-level technical overview of //Community configuration 2.0// (including description of other components), please see {T341884}. This task assumes high-level familiarity with other components the feature is consisted of.
==== Description
To ensure admins who are not tech-savvy can use the Community configuration, we should have an editing form (similar to Special:EditGrowthConfig). Usage of the configuration form needs to be optional; any configuration user needs to be able to introduce their own editing interface should be able to do so. If possible ({T332849} is research spike), the configuration form should auto-generate itself based on the schema (T342575).
==== Status quo
The current EditGrowthConfig page uses the MW OOUI HTMLForm to generate all the form fields for a given configuration (or set of configs). For GrowthExperiments use cases data types have been mapped to corresponding HTMLFormFields See:
| Data type | HTMLFormField | Example| Notes |
| boolean | HTMLRadioField | GEMentorshipEnabled |
| int | HTMLIntField | GEMentorshipMinimumAge |
| text | HTMLTitleTextField | GEHelpPanelHelpDeskTitle |
| array<int> | HTMLTitlesMultiselectField | GEInfoboxTemplates |
| array<int> | HTMLNamespacesMultiselectField | GEHelpPanelExcludedNamespaces |
| array<int> | One HTMLIntField | GELevelingUpKeepGoingNotificationThresholds | Thresholds is an array of two numbers, eg [1,7], only the second element is editable|
| array<object>| Several HTMLTitleTextField | GEHelpPanelLinks | Each link has title, text, id |
Some of these mappings require ad-hoc logic to set the field value from the source data and to process the submitted data before storing it in JSON.
==== Proposal 1: MW HTMLForm
A simple way of providing a field mapping for each JSON schema property would be to add a field description key along with the property definition, eg: "widget". The value of the property is one of the available HTMLForm fields.
```lang=json
{
"$schema": "https://json-schema.org/draft-07/schema#",
"$id": "http://example.com/communityconfiguration/test/1.0.0",
"type": "object",
"properties": {
"CCExampleBackgroundColor": {
"type": "string",
"minLength": 1,
"widget": "text"
}
},
"required": ["CCExampleBackgroundColor"],
"additionalProperties": false
}
```
Additional widget properties could be also added, eg: `"widget": { "type": "text", "disabled": true }`. If no widget information is provided a default type mapping could be applied ( int => HTMLIntField ). Special cases like Growth's GELevelingUpKeepGoingNotificationThresholds or GEHelpPanelLinks would require special treatment.
==== Proposal 2: Codex
This is an **exploratory** proposal. Similar to the example above, the "widget" property can target valid Codex component names, eg: `"widget": "TextInput"`.
```lang=json
{
...
"properties": {
"CCExampleBackgroundColor": {
"type": "string",
"minLength": 1,
"widget": {
"type": "TextInput",
}
}
},
...
}
```
The problem with this approach is the lack of MW specific widgets like HTMLFormFields. CommunityConfiguration or the consumers of CommunityConfiguration could provide some higher level components since we don't have a conventional place in MW core or aside to host this kind of components. eg:
```lang=json
"widget": {
"type": "ColorPicker",
"module": "ext.growthExperiments.Form",
}
```
Another caveat of this approach is it would require to rebuild some of the features HTMLForm/FormSpecialPage already do like preserving data across re-authentication.
==== Open questions
- [] Which JSON data types should the MVP support?
- [] Do we need to support Javascript-less experience?
- [] Is client side validation required? Desired?
- [] What UI library should we use?
==== Latest designs
[[ https://www.figma.com/file/bT1O4TChNV5TpwF5JHgKAK/Community-Configuration-2.0?type=design&node-id=581%3A15840&mode=design&t=JhMkRB9ABfkESF8t-1 | Figma designs ]]
------
Timebox: two days