Overview

This utility is designed to transform the MDMS configuration into FormComposer and InboxFormComposer configurations. Typically, every UI configuration relies on certain parameters. These parameters might include dropdown dependencies or custom classes determined at runtime based on specific logic. However, since the configuration is in JSON format stored within MDMS, direct usage of variables is not feasible. To address this requirement, we've developed a utility capable of converting this JSON into a parameter-based JSON structure.

Steps

This utility serves as an engine that accepts MDMS configurations along with dependent parameters. It then processes this data to generate a parameter-enabled configuration. This resultant configuration can be utilized by FormComposer and InboxFormComposer to render the UI elements accordingly.

Below is the method used to configure the MDMS -

{
             "isMandatory": true,
             "key": "noSubProject_ward",
             "type": "radioordropdown",
             "label": "PDF_STATIC_LABEL_ESTIMATE_WARD",
             "disable": false,
             "preProcess": {
               "updateDependent": [
                 "populators.options"
               ]
             },
             "populators": {
               "name": "noSubProject_ward",
               "optionsKey": "i18nKey",
               "error": "WORKS_REQUIRED_ERR",
               "required": false,
               "optionsCustomStyle": {
                 "top": "2.5rem"
               },
               "options": []
             }
           },

1. Pass the JSON path of the dependent key that requires runtime updates. In the example above, the target is on “populators.options”.

2. Update the options at runtime based on certain logic.

1. Once the configuration is complete, this will be added to MDMS. So, the next thing is to pass this config and its dependencies to the Pre-Process utility. The Namespace to access this utility :

Digit.Utils.preProcessMDMSConfig(t, MDMSObject, dependencyObject);

The dependency Object contains multiple actions which the pre-process function runs for us.

1. Translate - This targets the JSON path and does translation for the passed data.

2. updateDependent - This targets the JSON path and update the dependencies.

3. convertStringToRegex - This targets the JSON path and converts the String RegEx to RegExp based Regex.

Refer to the sample example below -

const config = useMemo(
     () => Digit.Utils.preProcessMDMSConfig(t, createProjectConfig, {
       updateDependent : [
         {
           key : 'withSubProject_project_subScheme',
           value : [withSubProjectSubSchemeOptions]
         },
         {
           key : 'noSubProject_subScheme',
           value : [noSubProjectSubSchemeOptions]
         },
         {
           key : 'noSubProject_subTypeOfProject',
           value : [subTypeOfProjectOptions]
         },
         {
           key : 'noSubProject_ulb',
           value : [ULBOptions]
         },
         {
           key : 'noSubProject_ward',
           value : [wardsAndLocalities?.wards]
         },
         {
           key : 'noSubProject_locality',
           value : [filteredLocalities]
         },
         {
           key : "citizenInfoLabel",
           value : [showInfoLabel ? 'project-banner' : 'project-banner display-none']
         },
         {
           key : "noSubProject_endDate",
           value : [!isEndDateValid ? (() => isEndDateValid) : (()=>{})]
         },
         {
           key : "basicDetails_dateOfProposal",
           value : [new Date().toISOString().split("T")[0]]
         },
         {
           key : "basicDetails_projectID",
           value : [!isModify ? "none" : "flex"]
         }
       ]
     }),
     [withSubProjectSubSchemeOptions, noSubProjectSubSchemeOptions,
      subTypeOfProjectOptions, ULBOptions, wardsAndLocalities, filteredLocalities, showInfoLabel, isEndDateValid]); 

In the example above, we are using the action “updatedependent” from pre-process utility.

• “Key” targets the input key name. This will help preprocess to target the right input field.

• “Value” - Each input within the configuration is associated with a JSON path, with each path targeting a dependent object. As previously demonstrated, we passed the JSON in a specific order within an array. Similarly, we must pass the corresponding dependent values in the same order to ensure alignment with the correct targets.

A similar utility is also developed for InboxSearchComposer. Refer to this same document for both utilities.

Overview

This document provides the steps on how to integrate another UI into the DIGIT UI using iframe.

Steps

1. Enable the module.

   • configurations to enable the Utilities module.

   • Add the s in your web/src/App.js and web/package.json to enable the module in the Build.

2. Once the Utilities module is enabled, add the following changes to the master (file path given below).

Master details: data/pg/commonmasters/uiCommonConstants.json

Here -

• shg is the path name to access inside digit-ui;

• home is the route to access it;

• whatever is mentioned inside routePath should be the Application/Pod name that is expected to be shown inside the digit-ui;

1. Once the MDMS changes are applied, access the new application using the following route - <SERVER_URL>/digit-ui/employee/utilities/iframe/<PATH_NAME>/<ROUTE_NAME>

Examples: New Web Application (UI - any framework)

DIGIT UI

Overview

This document provides the customisation details for DIGIT UI. Customisation can be classified broadly into two types -

1. Overriding the Component/Hooks/CSS

2. Overwriting the required changes directly into the Micro-ui-internals

Overriding

Overriding involves making all customization changes exclusively within the micro-ui/web directory.

For CSS

Within the custom CSS module, define customized CSS using the same class name or ID. Afterward, publish the changes. Ensure to reference this custom CSS file in the index.html to reflect the modifications on the website.

For Components/Hooks

For overriding any components, re-register the same component in the same name in the customization folder. The latest changes are reflected.

Overwriting Changes

Overwriting involves directly modifying the micro-ui-internals directory. This is slightly more challenging method to incorporate changes. Make sure the docker file is updated as per the code below and includes the install-deps.sh script.

The workspace in the web/package.json should be updated as below:

Overview

This page explores the steps to publish CSS if there are any CSS Customization/changes. While customising, if any changes are made In the CSS folder it has to be compiled and published to npm.

Steps

Currently, the CSS is published in npm as @egovernments/digit-ui-css

Refer to the NPM link here - .

So any changes to the CSS folder locally must be published in different organisations and in the same or different package name. For example - @xyz/digit-ui-css and version 1.0.0 then the following changes have to be made in the code to reflect in the digit-ui

​ - file location

frontend/micro-ui/web/public/index.html

The style sheet link must be updated as follows,

<link rel="stylesheet" href="https://unpkg.com/@xyz/digit-ui-css@1.0.0/dist/index.css"/>

Use either of the following commands to publish the CSS

• In the frontend/micro-ui/web/micro-ui-internals folder run yarn run publish:css or

• In the frontend/micro-ui/web/micro-ui-internals/packages/css folder run yarn run publish --access public

There are two ways to customize the CSS -

1. Override the required CSS only without changing in the CSS folder and making changes only in the custom CSS folder. Both CSS will be present in the index.html the order of the package mentioned in the HTML determines which CSS needs to be taken ie the box mentioned in the last will have more precedence. example of overriding CSS as follow -

2. Overwrite the complete existing CSS.

Reference doc for publishing any package to npm -