Portal By Config

danger

This is a concept that has been under development, conceptually for some and there are some code supporting the concept. the following section will explain the concept and show the already implemented code and som more explanations.

Discovery of the Fusion Ecosystem

Read more and link to miro board her!

Let's use Fusion to make our business applications more efficient. Fusion brings everything together in one place so we can easily launch our apps. As our needs grow, we can customize features to fit our unique processes.

Dealing with different requirements from various teams can be tough, but there's a lot of potential here. Picture a situation where a team needs specialized apps that work seamlessly together. With Fusion, we can create these apps quickly and use its services.

But what happens when we have too many apps? We might lose track of them. What if there was a way for users to ask for a custom portal? A team could set it up, giving developers and product owners the tools to shape it to their needs. They could even choose pre-made templates or design a page from scratch.

Portal Config Module.

As mentioned the work here has stated ad this section will intro dus the work already done. I all evolves around the portal-config module, witch can be enabled like this.

enablePortalConfig(config, (builder) => {
            builder.setConfig({
                portalId: '5b43c3fd-77e3-4072-0aa1-08db310ee26d',
                portalEnv: "ci",
            });
});    

This is all configuration needed for the portal when all features are done. But at the moment most of them are on the drawing board so the concept is implemented utilizing a configuration backdoor.

Portal Flow and State

The configuration and state of a portal are intertwined, where much of the configuration remains static and unchanging. However, this is contingent upon the portal's specific configuration settings.

The configuration of the project portal follows a context-firs approach. This is achieved by specifying the configuration for the supported context types. In cases where no context types are configured, the system defaults to treating the portal with an application-first approach.

This is exemplified in the structure of the portal object:

/**
 * The state of the portal.
 */
export type Portal = {
    id: string;
    icon?: string;
    name: string;
    shortName?: string;
    subtext?: string;
    contexts?: ContextType[];
};

export type ContextType = { type: string };

If the context is undefined or the length of the array is 0, then the portal operates under an application-first paradigm. and applications will be provided with the initial portal config request. The portal config will then never change across the the current application session.

here is teh structure of the portal-config request:

/**
 *  The portal state.
 *
 */
export type PortalRequest = {
    id: string;
    icon?: string;
    name: string;
    shortName?: string;
    subtext?: string;
    contexts?: ContextType[];
    apps?: AppManifest[];
    routes?: PortalRoutes;
    extensions?: Extensions;
};

At this state stage the apps, routes and extensions are not supported. As mentioned above the routes can be configured and apps will come at a later stage.

info

The only reason the tis is mentioned here is that tis describes the application when al features are implemented, but at tis point in time hardcode implementation is teh only way to achieve this.

export type PortalState = {
    portal: Portal;
    routes: PortalRoutes;
    apps?: AppManifest[];
    extensions?: Extensions;
    error?: {
        message: string;
        type: string;
    };
};