Analysis: Template for app frontend

[nkylstad]

Description

Decide on needs/scope for a template for app frontend

In scope

What's in scope of this analysis?

React app template

• What is the minimum requirement

Out of scope

What's out of scope for this analysis?

• Templates using other technologies

Constraints

Constraints or requirements (technical or functional) that affects this analysis.

How should the app developers include/host the generated .js-file so that it can be referenced from the .netcore app? Can we include it as a static file in the .netcore app? This works ok locally, but we would need to figure out how to handle f.ex .routing when the apps are deployed.

Analysis

Creating a template can be done in several steps.

Step 1: A stripped down version of app frontend

Unnecessary functionality/functionality that is strongly connected to the standard app frontend implementation, is removed. This should still then be a working react application, with basic functionality like

• instantiation
• party selection
• receipt
• fetch initial data like
  • profile
  • instance ?
  • languages/texts

already available, as well as some helper functionality like

• get/submit form data
• update validations?

Process-specific views will be removed, and replaced by a generic custom view, that a developer can build on/replace. Developers need to make their own implementation of the different process step views.

Build scripts should be set up and working.

Step 2

Split app frontend into multiple parts

Split out the parts that might not be so relevant for customization to begin with:

• instantiation
• party selection
• receipt

Outlining some alternatives to do this:

Alternative 1: Sub-apps

In Designer, we use the sub-app concept to combine several react applications into one at build time. We could structure the app template in the same way, with a top-level application to control standard functionality like fetching profile/texts/etc, and sub-apps for things like:

• instantiation/party selection
• instance/process
• receipt

This would still mean a lot of code is included in the template, but the app developer would only have to focus on the subapp(s) that are relevant to their needs, simplifying the structure significantly.

Alternative 2: Dynamically load js at runtime

Split the frontend into several projects, each of which generate their own .js-file.
Use a top-level application to load relevant .js-files runtime. Not sure if this would actually work, would need to do a POC.
As with sub-apps, this would allow developers to only focus on the relevant parts of their custom app. However, we would not be able to share things like profile/user data accross, each "app" would have to handle that themselves. Might cause some duplicate api-calls.
Would potentially allow us to load smaller chunks of .js at a time. However, we would need to address any security concerns about loading js at runtime.

Alternative 3: Multiple .netcore views

Could also potentially help with loading times as we would reduce the size of each .js-file that is loaded at the different stages. However, the same issues regarding duplicate api-calls would be present here.

Step 3

Publish reusable components/functions to a component library that can be imported, both by custom app frontends and the standard app frontend.

• Form components
• Components in Altinn Shared
• Themes
• Utils

Conclusion

Short summary of the proposed solution.

A basic template for app frontend can be created by simplifying the existing standard app frontend and removing code that is unnecessary for a more generic custom implementation.

This can then be extended, both by reducing the template even further by splitting the app frontend into multiple parts, and by moving code/components that are reusable across apps out to npm libraries (or similar) to be imported.

Tasks

• Is this issue labeled with a correct area label?
• QA has been done

[JanAage99]

OED har behov for custom eksternt GUI. OED sin brukerhistorie:
Altinn/oed#140