Sub form component needs to be represented in the URL

[HauklandJ]

Part of the Underskjema Epic.

When having navigated to a sub form, we need a way to persist state if the browser is refreshed and a logical navigation when the browsers back button is pressed.
This may be solved by giving the sub forms a relative path.

Today the URL looks like this:

[app]/#/instance/[party-id]/[instance-id]/[task]/[page]

General extension of url:

[app]/#/instance/[party-id]/[instance-id]/[task]/[page]/[componentId]/[data-element-id]/[component-page]

Sub form specific:

[app]/#/instance/[party]/[instance-id]/[task]/[page]/[subform-component-id]/[subform-data-element-id]/[subform-page]

The sub form component must be able to add, parse and identify multiple elements (componentId and id) from the URL.

[danielskovli]

The current URL schema looks roughly like this:

[app]/#/instance/[party]/[instance-id]/[task]/[page]

Where page refers to a layout schema.

Proposed new schema:

[app]/#/instance/[party]/[instance-id]/[task]/[page]/[subform-component]/[subform-page]

This approach would make it very clear where a user came from, and which context they are in related to the parent form.

Alternatively we could do something like this:

[app]/#/instance/[party]/[instance-id]/[task]/[subform-page]?returnto=somewhere

Which would play better with "future requirements" related to sub-apps and external round trips, but at the same time that's decidedly out of scope for this initial implementation.

Thoughts? Debate?

(ping @HauklandJ @olemartinorg @bjosttveit ... other interested parties?)

[olemartinorg]

@danielskovli As the support for sub forms inherently means support for multiple data elements of the same data (model) type, we'd also have to put some kind of identifier for which data element you're looking at in the URL. Only putting [subform-page] (or [subform-component]/[subform-page]) in the URL is not specific enough - you also need the [which exact subform] part.

Me and @HauklandJ just discussed a potential solution - implementing a sub-system in app-frontend for "letting certain components hijack the full form page rendering". So, with examples:

• [app]/#/instance/[party]/[instance-id]/[task]/[page] <-- Existing URLs
• [app]/#/instance/[party]/[instance-id]/[task]/[page]/[component-id]/[anything] <-- Allows component with the given ID to override the full page to potentially render something else (thus skipping all other top-level components).
• [app]/#/instance/[party]/[instance-id]/[task]/[page]/[subform-component-id]/[subform-data-element-id]/[subform-page] <-- Example where the subform component takes over full page rendering and provides the subform instead of other top-level components (displays [subform-page] instead of [page], but lets you click a button to exit the subform and go back to [page], essentially)

I hope such an abstraction and sub-system would make sense and scale with future functionality. We've talked before about exposing certain app-frontend state in the URL, such as which row you're editing in a repeating group, or which tab you have open in the Tabs component (so that you can maintain that state in navigation history and return to the same place when going backwards), but we haven't landed on anything there, so both repeating groups and tabs keep their state in the components themselves and loses it when you navigate away from them.

[bjosttveit]

As the support for sub forms inherently means support for multiple data elements of the same data (model) type, we'd also have to put some kind of identifier for which data element you're looking at in the URL.

This, Ole Martin beat me to to it 😅

[danielskovli]

@olemartinorg The need to refer to a specific data element makes sense. It also looks like I was writing my comment here while some of you came to mostly the same conclusion in another meeting. So I think that is a good sign, overall :)

[HauklandJ]

Proposed new schema:

[app]/#/instance/[party]/[instance-id]/[task]/[page]/[subform-component]/[subform-page]

Updated issue to include subform page in url

[HauklandJ]

We should keep in mind the future feature request to support multiple layout-sets per task

[danielskovli]

This has been implemented in feature/subform.