[PROPOSAL] UI: `Form` compatibility for `Interruptive` modals.

[thibsy]

Current Situation

Reusability

Interruptive modals have no client-side functionality which enables the reusability of them. Consider the following scenario: There is a table with multiple entries (or rows), which all have an action Dropdown. Several Buttons of each Dropdown will trigger a "dangerous" action.

The current implementation of this scenario will render an Interruptive modal for each of these dangerous actions for each entry. We can already slim down the implementation by rendering "dummy" Interruptive modals, which are replaced by their withAsyncRenderUrl, instead of actual ones, so they can share an endpoint which provides (sort of) the same Interruptive on each request. This still leads to much HTML needing to be rendered, since every modal could potentially be requested. The new Data table already does reuse one modal for all actions, but it still makes requests to replace the modal content.

This produces more network traffic, which would be fine, if it weren't unnecessary. The solution to this problem is not quite trivial though, but if the component provided client-side functionality to fill an Interruptives affected items, this could get rid of asynchronous rendering altogether for this scenario.

Submissions

An Interruptive modal contains several affected items (InterruptiveItems), which are identified by an ID. These items will be submitted via POST. Currently, there is no way of knowing how the affected items must be retrieved from the request-body, right now the key interruptive_items is hardcoded. Therefore, current implementations cannot define their own key for the request-body and use some magic string that could change at any time and break the endpoint.

The component can also not be provided with a ServerRequestInterface, like Forms, to obtain the submitted items with e.g. getData(). Thus, making implementations somewhat fragile.

Solution

The first problem (reusability) points into the direction of dynamic inputs (HasDynamicInputs), which allows the client to render a template of an input on-demand. A template in this case would be an InterruptiveItem, whose ID would be used for submission. This also leads to the latter problem, which points to the behaviour of a Form. If Interruptive modals behaved like Forms, it would be way more robust because the consumer would not need to worry about retrieving the affected items from $_POST.

A possible solution would be:

• InterruptiveItem extends Input\HasDynamicInputs, so a template for client-side rendering can be used.
• Interruptive extends Form\Standard, so the modal can be treated in the same manner.
• Interruptive becomes a decorator for a FormWithNoSubmitButton, just like Roundtrip.
• Interruptive does only accept InterruptiveItems as inputs, which need to be provided in the constructor.
• modal.js is extended by a public function to trigger the rendering process of a dynamic inputs (InterruptiveItems)

There is currently an open discussion about displaying multiple InterruptiveItems inside the modal, which can be selected or not with an according Checkbox. The checkbox would decide whether the item should be considered on submission or not. If the InterruptiveItem already extends the HasDynamicInput and therefore Input interface, this looks also quite approachable:

• Checkbox is extended to accept another Component (or something more explicit) with e.g. withAdditionalContent(), which is displayed besides the checkbox-element.
• SelectableItem as new InterruptiveItem which returns a Checkbox::withAdditionalContent() as getTemplateForDynamicInputs().

[thibsy]

Please not that I have created this PR merely to document the current situation, which I'd like to improve very much. The reusability-aspect (with HasDynamicInputs) can certainly be discussed, but I do insist on the Form part.

This PR is also somewhat related to #5203.

[klees]

Hi @thibsy,

I have started to look into this, but as you noticed yourself: This doesn't seem to be an easy problem. Do I understand correctly that this is not urgent? I would then postpone this for about another month and solve some other hard problems before looking into this. There's only limited space in my RAM... Is this ok for you?

Thanks for your patience!

[thibsy]

Hi @klees

No problem. I think it's not very urgent. However, I want to point out that as part of the LUI project there might be many new Interruptive modals in use soon, which would all need to be touched again since this improvement will most likely mean changes for consumers.

Kind regards, @thibsy

[klees]

@thibsy I think this is superseeded by the approach in #6309, so we could close this. Would you agree? If not, we should maybe discuss both approaches in person, maybe together with @Amstutz and @nhaagen (and whoever is interested too...). If yes, please close this. Thanks!

[thibsy]

@klees I don't think this PR tackles the same issue, since this one specifically tackles Interruptive modals and the referenced PR does not really improve them, right?. Maybe we can reuse some functionality of dialogs though. I am happy to discuss this on Discord sometime.

[klees]

Hi @thibsy,

I stumbled upon this PR while doing the regular checks for old PRs for the Technical Board. I apologize that it took me so long to move this forward. I will look into this again soon.

Kind regards!

[dsstrassner]

Hi @oliversamoila, I think you should discuss this with @thibsy :see_no_evil: