JanAage99
commented
4 years ago OED har behov for custom eksternt GUI. OED sin brukerhistorie: https://github.com/Altinn/oed/issues/140
Open nkylstad opened 4 years ago
JanAage99
commented
4 years ago OED har behov for custom eksternt GUI. OED sin brukerhistorie: https://github.com/Altinn/oed/issues/140
Description
Decide on needs/scope for a template for app frontend
In scope
React app template
Out of scope
Constraints
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
already available, as well as some helper functionality like
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:
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:
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.
Conclusion
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