Analysis: Template for app frontend

## 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