Page MenuHomePhabricator

Allow consumers to customize the default editor UI representation for an option
Open, LowPublic

Description

The client editor Community configuration provides can only display a limited set of data types and with a conventional representation. That representation might not be adequate for some consumers needs.

We should allow consumers to get the benefits of using the Community configuration built-in editor but customize the representation of one or more options in their schema.

The way of doing this would be by adding a Vue component on their extension and defining the script file or RL module in the desired provider configuration, under the "form" key. eg:

 "form": {
        "type": "jsonform",
        "args": [
                "ext.communityConfiguration.GrowthExperiments"
        ]
},

Developer story
As a MW developer I would like to have an easy way of using CC2.0 editor
with custom UI representation of one or more options

Acceptance criteria

  • CC2.0 consumers are allowed to register a custom control to overwrite the default control for a particular type or scope.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
KStoller-WMF moved this task from Inbox to Up Next on the Growth-Team board.

Change 1005831 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] Editor: allow providers to register a custom option control

https://gerrit.wikimedia.org/r/1005831

Sgs edited projects, added Growth-Team (Sprint 8 (Growth Team)); removed Growth-Team.
Sgs updated the task description. (Show Details)
Sgs moved this task from Incoming to Doing on the Growth-Team (Sprint 8 (Growth Team)) board.

I was thinking about the proposed approach in sync meeting with @Urbanecm_WMF of only allowing to register Vue SFC files, eg:

[
	{
		"vueComponentPath": "Sth.vue",
		"rankingRule": (...)
	}
]

I find this approach restrictive for complex cases. The reason is the amount of things that may require to be configured for a given JS script to work. The script can have dependencies, translation messages or external less resources associated. Restricting this to a vue component path would require the developer to know very well what could be used or not, and foreseeing the use cases here is hard.

Another inconvenient is we cannot export two "things" from a Vue SFC component with the mediawiki CommonJS setup. If we had the power of ES6 export, we could export both a component as the default export and a tester function alongside with a named export "tester". I find that setup quite ideal for what we want to accomplish, but since we cannot use it right now I'm unsure of what approach to take (see current proposal in next paragraphs).
Also I don't see the benefit of having the ranking rule written as a json serialization over a pure JS function. I will keep on thinking on a simpler setup than two different files for the renderer and its ranking.

My concern with sticking with RL module as the configuration unit for custom renderers is promoting the creation of RL modules while this is not desired (I haven't been able to find the relevant task but I think the total number of RL modules has an impact on performance loading right?). Alternatively we could stick with the single script approach and mimic config options from RL: messages, dependencies, styles, etc.

tl:dr;
Proposal 1: stick with RL module
Proposal 2: use single Vue file and mimic RL config options for messages, styles, etc.

Let me know what you think @Urbanecm_WMF and if you have any alternative proposal. Ty!

This was discussed during the CC technical meeting, and it looks like we agreed on registering Vue SFC files, but via a RL module. This approach looks good to me. I think the CC meeting resolved the blocker, so I am moving this back to Doing.

Change #1015357 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] CommunityConfiguration: show radios instead of checkboxes

https://gerrit.wikimedia.org/r/1015357

Moving to Doing, as the patch currently fails CI.

I believe this task is still valid but maybe we ain't gonna need it at this stage of the project depending on the outcome of T362044: Community configuration: Decision about how to display the boolean controls in Special:CommunityConfiguration/Mentorship.

Change #1005831 abandoned by Sergio Gimeno:

[mediawiki/extensions/CommunityConfiguration@master] Editor: allow providers to register a custom option control

Reason:

Per "product" decision in T362044, allowing to configure a single control is not necessary for handling the unconventional boolean radio buttons.

https://gerrit.wikimedia.org/r/1005831

Change #1015357 abandoned by Sergio Gimeno:

[mediawiki/extensions/GrowthExperiments@master] CommunityConfiguration: show radios instead of checkboxes

Reason:

Per "product" decision in T362044, allowing to configure a single control is not necessary for handling the unconventional boolean radio buttons.

https://gerrit.wikimedia.org/r/1015357

Sgs removed Sgs as the assignee of this task.Tue, Apr 16, 12:39 PM
Sgs lowered the priority of this task from High to Low.