Overview

This document is intended for technical users, and is a proposed method of decoupling the formio modules from the CHEFS application. Decoupling will allow maintainers to update components or add new components without having to redeploy CHEFS.

Context

Formio

Form.io allows for user developed feature called modules that alter the behaviour of the formio builder and renderer. A module contains plugins which handle specific behaviour for formio. More information can be found here Modules | Form.io Documentation . For this document, only the components and providers plugin are discussed as those are the only ones used by CHEFS.

CHEFS

Currently in CHEFS, before the front end application (Vue) is created and mounted, the modules for formio are registered with the line Formio.use(BcGovFormioComponents). This ensures that when an end user is using CHEFS, that they're using the components that were deployed with CHEFS. This allows for stability across the application when using formio modules but prevents making quick or minor changes to the formio builder/renderer.

Test

To demonstrate the capability of adding a module to the formio builder post deployment. I created a feature branch containing a change that imports the formio-contrib module after creating the Vue component and registers it with the formio builder. It can be found GitHub - jasonchung1871/common-hosted-form-service at post-init-modules.

Improvements

To build on this, we can use an internal API that stores versioned modules which allows administrators to import external modules which allow form designers/submitters to use old modules as well as new modules. This would also allow form managers to view submissions with their original modules rather than what would be imposed (the latest). If an update is made to change the styling of a component, or the builder itself, that change would be reflected on where that external module is hosted. Not on the CHEFS application itself, CHEFS will only be pulling the production ready build of that module into the application at runtime.

Some downsides to this are that we lose control over what we can do within CHEFS as we would require those external modules to make their features exposed to us. If this stays open source though, we can fork those modules and separate them to allow us finer grained control over behaviour of formio. This will end up becoming more of a feature for formio rather than a feature for CHEFS.

The only users able to import new modules or make changes to existing modules are administrators. Public users and authenticated users will be able to make requests to know what modules a form is using so that they may download them automatically. Each module can have multiple versions but those versions can only be added to a form by the IDP specified by the administrator.

The proposed database changes

A form module is the common plugin name for a module and whether that module is enabled/disabled by the administrator. Each form module has a version which will be used by a form version. This allows a submitter and a reviewer to use a form with the exact same modules that it was created with while newer forms are created with the latest modules. The form designer should be given the option to update their modules to the latest if they have outdated modules.

The IDP may become important in the future once more authentication methods are added. Some users may require IDIR to use government form components, some may require other authentication methods for other modules. We could set the IDP requirement at the form_module_version level so that each version has a set identity provider, but the administrator should just determine which idp a module is designated for and set it globally.