Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Key components of DIGIT-UI
This page provides the architecture and key features of the DIGIT UI. Click on the broader headings below to find the details.
Broadly, the DIGIT UI frontend components are categorized as below:
The CSS Library contains all the classes both in the module and compiled form.
This can be imported using import "@egovernments/digit-ui.css/Button"
or full CSS import using import "@egovernments/digit-ui.css"
The Component Library contains a set of all required components defined in it.
The libraries and utils contain the following:
Localization workflows
API Handling Strategies - Centralize API caching and handling strategies within shared functions, accessible by all modules. This ensures consistency and efficiency across the application.
Localisation
The module is a closed system for states, allowing access only to node_modules or CDNs. State-specific components can be provided during the module's initialization in the employee or citizen application.
Below is an illustration of how the module structure looks like:
Modules contain the following inbuilt
Theme - this may change if we later decide to use any css-in-js
library, like styled-components
.
Components
Routes
State management
Business logic
API integrations
The first line contains the Architecture Component name or info
The second line contains an npm package and a template in brackets for creating the component.
Easy-to-use CLI
Handles all modern JS features
Bundles commonjs
and es
module formats
create-react-app for example usage and local dev for React-based libraries
Rollup for bundling
Babel for transpiling
Supports complicated peer-dependencies
Supports CSS modules
The templates have the following folder structure: Components related to the template are inside the src
folder. An example is provided to demonstrate the app created by the template.
We have two main React Apps:
micro-ui-internals
This is meant for the eGov development team to build components and default modules.
It contains the following modules:
CSS Library
UI Components (presently react-components
)
Utils Library: Contains Services, Localization handling and React Hooks.
UI Modules
Core - containing login, routing and global state.
PGR
FSM
PT
Payment
etc ...
micro-ui
This is meant for the state team to manage, make changes, and deploy
It allows the import of digit-ui-internals
modules
Customizations
View
Services
Build and deploy scripts
Dockerfile & nginx.conf
build-config.yaml
The app imports the developed module.
In the next phase, we can merge the Employee and Citizen apps into one app with role-based permissions and content.
DIGIT UI development guide
After the backend development and deployment of DIGIT, as per the steps detailed in the Backend Developer Guide, it is time to start building the UI screens. For illustration purposes, we will build the citizen and employee screens for the Sample module.
This guide offers a systematic view of creating the application screens on DIGIT.
Developer code: Download the UI code from the link here Sample-Registration.
DIGIT UI basics to browse through before initiating the frontend development.
Follow the cards below to build and deploy the DIGIT UI.
Custom UI development depends on specific user requirements. We have listed common scenarios (listed below) - follow the steps outlined for each to set up DIGIT UI as per requirements.
Run Sample Module - Once the setup is complete, run the sample module provided in this guide. Test run the module and deploy it using CI/CD to your development environment.
Visit our FAQs section to troubleshoot -
Migration guide to aid users in shifting from the "react-components" package to the "components-core" package
Topics covered:
This document details the essential modifications needed in the modules for smooth integration of components from the "components-core" package. It offers precise guidelines on utilizing FormComposerV2 and InboxSearchComposer, along with updates made in the configs.
In the components-core package, several enhancements have been implemented to improve code clarity and address issues related to pixel inconsistencies. Previously, there were challenges associated with pixel-based sizing, leading to inconsistencies across different devices and screen resolutions. To mitigate this, the codebase has been updated to utilize rems as the primary unit of measurement. This transition to rems offers several advantages over pixels, including improved scalability and responsiveness across various viewport sizes.
Adopting rems ensures the components' styling is more consistent and adaptable, providing a seamless user experience across different platforms and devices.
Furthermore, TextInput, TextArea, Radio, Button, Checkbox, Toggle, Dropdown, Multiselectdropdown, InfoCard, and Toast offer different variants. Adding variants for these components makes them more flexible, serving a wider range of purposes and meeting different design needs effectively.
These are some of the updates made in the components-core package.
Atom | Variants | State |
---|
To install:
Add the dependency in the frontend/micro-ui/web/package.json
Syntax for importing any components:
Syntax for importing FormComposerV2:
In the micro-ui/web/micro-ui-internals/packages/modules/Project/src/pages/employee/CreateProject/CreateProjectForm.js:
In the micro-ui/web/micro-ui-internals/packages/modules/Project/package.json :
Add “@egovernments/digit-ui-components-core”:”0.0.1” in the dependencies.
And when you import any component the syntax for the import statement is:
In the micro-ui/web/micro-ui-internals/packages/modules/Project/src/pages/employee/ProjectWMSSearch:
Verify the components in the sample module:
These are some of the modifications that need to be done in the modules to use the components from the components-core package.
Buttons are used for specific user actions. These clickable UI components allow the users to interact with the system.
Primary Variant
Secondary Variant
Tertiary Variant
Link Variant
Icons are sent as a string added before the label. To add it as a suffix, set the isSuffix parameter to true.
The Input field enables users to interact with the application through content input and data. The component allows users to input responses or data based on specific requirements.
Type: text
Below are the details for the type: text:
Example Usage of TextInput Component
Type: date
The date can be selected from the date chart. If editableDate is set to true, the date can be edited without using the date chart; otherwise, it cannot be edited.
Type: time
The time can be selected from the time chart. If editableTime
is set to true
, the time can be edited without using the time chart; otherwise, it cannot be edited.
Type: geolocation
Click on the geolocation icon to call and activate the onIconSelection function. Otherwise, the location details are captured by default.
Type: numeric
The numeric value by default increases and decreases by step value 1. But it can be configured using the step value sent as a prop in the config.
With Prefix and Suffix
Type: password
Type: search
There are two variants for the textarea - one has a resize option and the other is resizeSmart which auto-adjusts the height based on the input content.
This page outlines methods to reduce UI/UX audit bugs post-development by enhancing a UI library. Key improvements include:
These enhancements aim to streamline development and ensure a consistent, user-friendly interface.
To resolve UI/UX audit issues, we will implement new components featuring enhanced functionality, modern design, and superior performance. These elements should adhere to current design trends and meet user expectations to improve the user experience. Below is the list of DIGIT Components
Standardising design principles ensures consistency across the UI library, reducing the likelihood of UI/UX audit bugs. This involves establishing design guidelines, naming conventions, and component usage patterns.
Enhancing the stability of the UI library is crucial for reducing UI/UX audit bugs. This includes optimizing code quality, implementing robust testing strategies, and monitoring performance to identify and address potential issues.
Transitioning from px to em units improves scalability and accessibility, reducing UI/UX audit bugs related to inconsistent text sizes and layouts across different devices and screen resolutions.
Storybook provides a development environment for testing and documenting components, helping to identify and address UI/UX audit bugs early in the development process.
Implementing colour and text size constants ensures consistency in styling across the UI library, reducing UI/UX audit bugs related to colour contrast, readability, and visual hierarchy.
Introducing newer component variants enhances flexibility and caters to diverse user requirements, reducing UI/UX audit bugs related to limited functionality or options.
Creating Flutter widgets extends the UI library's reach to mobile platforms, reducing UI/UX audit bugs related to inconsistent user experiences across different devices and operating systems.
Implementing the improvements discussed here ensures the UI library is better equipped to reduce UI/UX audit bugs after development. These enhancements promote consistency, scalability, accessibility, and cross-platform compatibility, resulting in a more polished and user-friendly experience for end-users.
For more information:
For more information:
For more information:
For more information:
Label | Label for text field |
---|
For more information:
For more information:
For more information:
For more information:
For more information:
For more information:
For more information:
DIGIT UI Components
Learn all about the architecture and key features of the DIGIT UI
DIGIT UI Pre-requisites Checklist
Find the technical resources and knowledge required to develop a user interface on DIGIT
DIGIT UI Predefined Screens
Find the details of the DIGIT predefined screens.
UI Configuration
DIGIT UI configuration required to enable it in any environment
Local Development Setup
Set up the UI development environment locally
Run Front End App
Run the front end application locally
Build & Deploy
Deploy the DIGIT-UI module
import {FormComposerV2} from "@egovernenets/digit-ui-components-core" |
placeholder | Placeholder for the text field |
isMandatory | Whether field is mandatory or not |
disable | To disable the text field (no interaction will be possible if disabled) |
nonEditable | To make text field readOnly |
infoMessage | Information to be shown when hovered on the info icon beside the label |
description | Help text for the text field |
charCount | Number of characters in the input value |
withoutLabel | Default will be false, if sent as true then label won't be shown |
populators | Name : Mandatory field Error : Error message to be shown Validations: if required like maxlength, minlength etc customIcon: to show any icon inside the text field (can be sent as a string) onIconSelection: IconSelection function Prefix: To show prefix Suffix: to show suffix |
wrapLabel | Can wrap label to the next line in desktop and tablet screens |
A dropdown UI component is a user interface element that allows users to select one option from a list of choices. When the dropdown is clicked, it expands to reveal the list of options, and the user can click an item to select it. This component is often used in forms and navigation menus to save space and organize options efficiently.
Simple Dropdown
To show the icons beside each option, set the showIcon prop to true. Send the icons as a string along with the required options. The dropdown is searchable but can be configured using the isSearchable prop.
To reset the option after selecting it, clear the option and click enter.
For more information: StoryBook for simple dropdown
Nested Dropdown
For the type dropdown with the "nesteddropdown" variant, options can be configured as shown above. Icons are optional but can be included if needed. The search results are displayed as per the main category names.
For more information: Storybook for nesteddropdown varinat
Tree Dropdown
Here's a simplified version of your explanation:
For the type dropdown with the "treedropdown" variant, options can be configured as shown in the configuration above. Currently, the treedropdown does not support icons. Clicking on the parent option displays the child options. The final child options are enabled for selection.
This version maintains the necessary details while being clear and concise.
For more information: Storybook for treedropdown
NestedText Dropdown
For the type
dropdown with the variant nestedtextdropdown
, use the above configuration details to define the options.
Use this variant when you need to describe each option.
For more information: StoryBook for nestedtext dropdown.
Profile Dropdown
For the type dropdown with the "profiledropdown" variant, use the configuration details above to define the options.
You can set any image as a profileIcon as shown in the configuration.
For more information: Storybook for profiledropdown
Profilenestedtext Dropdown
For more information: Storybook for profilenestedtext dropdown
Simple MultiSelect Dropdown
For a multi-select dropdown, set options in the format given in the above configuration.
Ignore these If icons are not needed. Else, set the showIcon to true. Set the isDropdownWithChip parameter to true to show chips once the options are selected.
Configure the clearLabel param to ensure the chips are cleared from the label.
For more information: Storybook for multiselect dropdown
Nested MultiSelect Dropdown
Multiple options can be selected for each category.
For more information: Storybook for nested multiselect dropdown
Tree MultiSelect Dropdown
In a tree multiselect dropdown, you can select both parent and child options. Choosing a child option does not automatically select the parent option. When only some child options are selected, the parent option will show in an intermediate state.
Selecting any parent option will automatically select all its child options.
For more information: Storybook for treemultiselect dropdown
NestedText MultiSelect Dropdown
For more information: Storybook for Nestedtext Multiselect Dropdown
The Toast component is used to provide users with temporary notifications. It does not require any user action.
Success Toast
Warning Toast
Error Toast
The default transitionTime for any variant of toast is 5 seconds. However, this is configurable using the transitionTime prop (in milliseconds).
For more information: Storybook for Toast
The InfoCard component has four variants: default, success, error and warning. The default labels for these variants are Info, Success, Error and Warning.
However, the label can be configured using the label prop. The configuration enables users to set the array of elements for display in the info card component.
By default, the elements are shown in the vertical direction. To show the elements in the horizontal direction set the inline prop to true.
With Additional Elements:
For more information: Storybook for infocard
Text Date Time Geolocation Numeric Prefix Suffix Password Search | Default Filled Disabled NonEditable Focus Error Label Character Count Inner Label Info Help Text/ Description |
Default Filled Disabled NonEditable Focus Error Label Character Count Inner Label Info Help Text/ Description resizeSmart |
Radio Selection | Default Disabled Selected PreSelected |
Toggle | Default Disabled Selected PreSelected |
Primary Secondary Teritiary Link | Active Disabled Label Interactions |
Default Nested Tree select Profile Profile with nested text Nested Text | Default Disabled Selected Interactions |
Default Nested Tree Multiselect Nested Text Multiselect | Default Disabled Selected Interactions |
Default Checked | Active Disabled Label Interactions |
Success Warning Failure |
Default Success Warning Error |
The Toggle Buttons component in DIGIT UI presents a list of interactive toggle buttons, providing users with the ability to select an option. Each button is equipped with callbacks for both mouse-down and hover effects, ensuring a responsive and engaging user interface.
The widget contains the following required parameters:
Below are some additional parameters:
Usages
Add the following lines of code:
DIGIT UI components include various text input fields with optional features such as character count display, inner labels, and help text. These fields also come with built-in validation support for improved data integrity.
Text Input Field: A text input field for general alphanumeric data.
Text Area Input Field: For multi-line text input.
Search Input Field: Designed for search queries or search-related inputs.
Password Input Field: A secure input field for password entry.
Numeric Input Field: This field is suitable for numeric input.
Date Input Field: An input field designed to capture dates.
Time Input Field: Use this field to input time values.
Location Input Field: Specifically for geographic location data, such as coordinates.
These are some common props which can be sent inside all the input fields:
TextAreaScroll
Usages
Usages
Usages
Usages
Usages
Usages
Usages
Usages
This widget is a versatile and customizable checkbox component. It provides a checkbox with an associated label and allows users to toggle between checked and unchecked states. This widget supports various customisation options, including the ability to customise the checkbox icon colour, label, padding, and disabled state.
The widget provides a hover state, visually indicating when the user hovers over the checkbox. This is useful for enhancing the user experience.
This widget contains the following required parameters:
These are some option parameters:
Usages
Add the following lines of code:
DIGIT UI components is a collection of common Flutter widgets designed to simplify UI development. These components offer easy-to-use and customizable features to enhance UI design and streamline the development process.
Add this to your pubspec.yaml file:
Then run:
Import the package in your Dart code:
Atom | Variants | States |
---|
DIGIT UI components provide a variety of buttons with optional suffix and prefix icons, contributing to a cohesive and visually appealing UI.
Button Type
Primary: Represents the primary action. It features a prominent colour, and its appearance can change on hover or click.
Secondary: Offers a secondary action. It has a different colour scheme than the primary button.
Tertiary: Provides a tertiary action with a distinct visual style.
Link: Resembles a hyperlink, suitable for navigation or linking to other parts of the application. It typically includes an underline.
Hover and Disabled State
The DigitButton widget handles hover effects and a disabled state. When the button is hovered over, it can exhibit visual changes depending on its type. The disabled state prevents interaction and adjusts the button's appearance accordingly.
Icon Placement
The widget supports the placement of icons both before and after the label text. This allows for flexibility in button design.
Properties
It contains the following required Parameters:
These are some optional parameters:
To use the primary button add the below lines of code:
With suffix Icon:
With prefix Icon:
To use the secondary button add the following lines of code:
Prefix and Suffix icons can be added to the secondary button using the same code as given for the primary button.
To use the tertiary button add the below lines of code:
To use a link, add the following lines of code:
DIGIT UI components offer various drop-down menus, including single-select, multi-select, and tree-select options.
The Single Select drop-down in Digit UI Components provides a drop-down menu for users to make a single selection. It supports various features such as item filtering and selection handling. This intuitive component supports options with additional features such as images, icons, and descriptions, complemented by hover and mouse-down effects.
Sub-Types
Default drop-down
Nested drop-down
Tree drop-down
Below are some required parameters:
These are some additional customisation parameters:
DropdownItem
Inside the dropdown item, we can pass additional parameters to include the drop-down like description, image and icons.
There are the customisations available inside the drop-down item:
TreeNode
Inside the tree node we can pass a list of children associated with a node:
Usages
Default drop-down
With description and profile image:
Nested drop-down
Tree drop-down
The Multi-Select drop-down in DIGIT UI components offers a user-friendly interface for selecting multiple options simultaneously. This clean and intuitive component is equipped with built-in chips and provides responsive mouse-down and hover effects.
Sub-Types
Default drop-down
Nested drop-down
Tree drop-down
Below are some required parameters:
These are some additional parameters:
Usages
Default Drop-down
Nested Drop-down
Tree Drop-down
The Radio Buttons component in DIGIT UI empowers users to make a single selection from a list of options. This intuitive interface provides a smooth user experience with hover and mouse-down effects. It is designed to handle both horizontal and vertical layouts based on the screen width.
Below are some required parameters inside the radio list:
The following are additional parameters:
Usages
Add the below lines of code to configure the radio button:
The Toast widget provides a customizable toast notification for Flutter applications. It is designed to display short-lived messages, alerts, or notifications to users in a visually appealing and informative manner.
The ToastType enumeration defines different types of toasts, including:
success: Indicates a successful operation.
error: Indicates an error or failure.
warning: Indicates a warning or caution.
The Toast widget provides a static method for displaying toasts. This method includes the following parameters:
Usage
Success Toast
Error Toast
Warning Toast
Once the local setup is completed, the next step is to run the application locally. This document provides the steps on how to run the digit-ui on a local machine.
Step 1: To run the application in the local environment, add the .env
file in the example
folder -
Step 2: Copy the following content and add it to the .env file. If the user is a citizen, configure the .env file as shown below:
Step 3: To run the application as an employee, update the value of the param to - REACT_APP_USER_TYPE=EMPLOYEE.
Step 4: To direct the front end to different environments, update the REACT_APP_GLOBAL
variable and add the GlobalConfig environment file corresponding to that environment.
Update both REACT_APP_PROXY_API
and REACT_APP_PROXY_ASSETS
to the environment URL.
Before initializing the frontend app locally, ensure that you are in the specified directory.
Step 1: To initialise the Yarn execute the below command -
Step 2: Once the yarn initialization is successful execute the below command -
Step 3: Running this command will start the application.
There are two types of login -
Employee: If you log in as an employee, the below screen is displayed.
HomePage Employee: Once the employee is logged in, users are redirected to the employee home page.
HomePage Citizen: Once the citizens are logged in successfully, users are redirected to the citizen homepage.
if you do not have a global config and AWS credentials are not present, then create a temporary local config under the path:
Include this between the head tags
UI configuration for the application
This page offers details of the DIGIT UI configuration required to enable it in any environment. Browse through the configuration details listed below:
eGov recommends before developing on top of DIGIT. This ensures that new modules can be developed and deployed in a streamlined way. DIGIT ships with CI as code as part of the DevOps repository. Please run the before developing on DIGIT.
Step 1: Add entry in build-config.yaml file in the master branch of the forked repository. This will set up the job pipeline in Jenkins. Make sure to add the same config to the feature branch you are working on. Refer
Add the below content for digit-ui.
Step 2: Go to the Jenkins build page, select "Job Builder" and click on "Build now". This will pull the config from build_config.yaml and identify all modules that need to be built.
Step 3: Once the build is done, go to your Jenkins build page. The service will appear under the repository path in which it has been added, i.e. if the service is added under frontend, it will show up in the frontend section as below,
Step 2: Deploy-as-code/helm/charts/frontend/digit-ui
Step 1: Locate the following "deploy-as-code/helm/environments/works-dev.yaml" i
n the DevOps repository of your organization.
Step 2: Add the below code block within the environment YAML file used to deploy the Works platform -
This section contains the configuration that applies globally to all UI modules. These need to be configured before the configuration of service-specific UI.
Create a config file (globalconfigs.js) with the below-mentioned config (refer to code below).
Configure all the images/logos required in the S3 and add links as footerBWLogoURL , footerLogoURL.
Mention the state tenant ID as stateTenantId.
If any User roles have to be made invalid add as invalidEmployeeRoles.
Then push this global config file into your S3 bucket as globalconfigs.js
The S3 bucket has to be configured by the DevOps team, to store all the assets being used in the application like Logos, globalConfigs, etc.
Steps to create a new AWS Bucket -
Create a new AWS S3 Bucket
Update the Bucket Policy with the following content, to make the bucket public
Update the Cross-Origin Resource Sharing (CORS) configuration with the following content
To proxy the same bucket in any environment and make the necessary changes in the environment.yaml
file located in the DevOps repository's configmaps
under egov-config
, follow the steps below:
Add the s3-assets-bucket: "pg-egov-assets"
After adding the proxy in the environment file, restart the s3-proxy
build in the environment with config enabled.
This page provides the steps to configure the FormComposer.
For complex configuration or screen details refer to documentation on
There are 3 new use cases added to the FormComposer in addition to the default one where the whole form was rendered in a single card. Those 2 are the following:
Multiple cards
Cards with navigation menu
Multiple cards with navigation menu on a single card
The following use cases are covered in the .
URL to access:/works-ui/employee/works/sampleForm
This can be done by setting the showMultipleCards
prop to the FormComposer as true. In this case, every object in the formConfig will be treated as a separate Card and will be rendered accordingly.
Access .
FormComposer provides the option to activate a navigation menu that appears on top of the card. Each link in the menu corresponds to a specific card. To enable this feature, provide an array configuration for the navigation menu as a prop to the FormComposer component. Then, map each card with a link from the navigation menu configuration array using a designated key named "navLink", associating it with a value in the Navigation Menu Config.
This use case is the same as above. The only difference is the navLink
property in the config. If this property is present and valid for a card config, the corresponding card will be mapped to a navigation menu link. On the other hand, if navLink
is not present or invalid, the corresponding card will be rendered as a separate Card.
Multiple options can be selected.
Steps to add new screens in DIGIT-ui
This document provides the steps for creating new screens in the DIGIT-UI.
Creating a screen in DIGIT UI involve simple steps and is classified into 4 different screen -
To create any new screen of the Create type, use the FormcomposerV2 and transmit the configuration as specified in the file.
To check the different types of configurations, refer to the function.
To use any view screen, create the hook for initiating API calls and structure the configurations for the View section.
Refer to the integrated screen with ApplicationDetailsTemplate - .
The hook details for the same is mentioned in .js
The service configuration details are available in
To create any inbox screen, use the InboxComposer and add the following configurations:
Building and deploying the digit-ui module
Follow the instructions to set up the job pipeline. Ignore the steps not applicable to the frontend.
Instructions here are provided assuming CD/CI has been set up using the DIGIT ci-as-code module.
All content on this website by is licensed under a .
This page lists the technical resources and knowledge required to develop a user interface on DIGIT.
Prior knowledge of React JS
Prior knowledge of HTML / CSS
Prior knowledge of Redux/Hooks
Prior knowledge of SCSS/React StoryBook
Prior knowledge of Git
Prior knowledge of Queries and Mutations
Knowledge of the DIGIT UI framework
Check the page to access help documents on the tools required for UI development.
This widget is a versatile and customizable information card designed inside a digit ui widget. It provides a visually appealing way to display information, with options for different types of information.
The Info Card supports different types of information, each with its distinct visual style:
Info: Default information card with a blue background and an information icon.
Success: This represents a successful operation, featuring a green background and a check-circle icon.
Error: Indicates an error or unsuccessful operation with a red background and an error icon.
Warning: Represents a warning or caution, featuring a yellow background and a warning icon.
Developers can include additional widgets beneath the description for extra information or interactive elements. The inline property controls whether these widgets are displayed horizontally or vertically.
Info cards contain the following required parameters:
There are some additional customisation parameters:
Usages
Info Card
Success Card
Error Card
Warning Card
There are two common components for workflow related actions and timeline management.
WorkflowActions -
WorkflowTimeline -
Both of these components are available on each View Screen. The WorkflowTimeline component is responsible for presenting the workflow history at the bottom of the View Screen. Similarly, the WorkflowActions component renders an action bar at the bottom of the view screens, showcasing pertinent actions based on the logged-in user's role and workflow configuration.
This component is directly integrated with the component that renders all the relevant data in view screens. WorkflowTimeline component is called in this component like this:
It expects a few props:
BusinessService -> Name of the businessService from workflow configuration
applicationNo -> Idgen generated application number
tenantId
timelineStatusPrefix -> prefix used in localisation of every checkpoint in timeline
statusAttribute -> here we can pass the attribute(either status/state) that is the key in the workflow process instance response, whichever we want to show in the checkpoint.
This component internally calls the workflow APIs to fetch the process instance of the application and renders the history accordingly. It also makes a check for the current state of the application. If the current state is not terminated state then it will show an extra checkpoint at the top with statusAttribute as status to show pending states checkpoint. If the current state is terminated state then it will not show pending states.
Refer to the below snapshots, notice they both have 4 checkpoints. Approved refers to terminate state.
This component is rendered on every View component separately to render the action bar with relevant actions.
Sample code Snapshot:
It expects a few props:
BusinessService -> Name of the businessService from workflow configuration
forcedActionPrefix -> for localization
applicationNo -> Idgen generated application number
tenantId
applicationDetails -> same data returned from hook used on view screen
Url -> update API url to hit
setStateChanged -> when update is successful this is called. Hence search apis will be called again and workflow history and workflow actions will be updated without screen refresh
moduleCode
editApplicationNumber -> Used in case of edit/modify action
This component internally calls the update apis and shows a relevant toast on success/failure or a response screen in case of edit action.
This page outlines the steps to set up the UI development environment locally.
Before setting up: Install the tools listed below before development. Make sure the specific versions are installed. In case no version in listed, install the latest version.
Install Visual Studio Code. VS Code Extensions to be installed from the marketplace:
Install NodeJS 14.20.0
version 1.22.19
Install Python version 2.7
Clone the repository locally from your organization's umbrella. This contains the frontend code under the frontend folder.
To learn how to install yarn on Linux, follow .
Approach to render Inbox and Search screen content based on config passed via MDMS data.
The is an event-based service designed to:
Fetch pre-aggregated data of municipal services and workflows.
Perform complex search operations.
Return applications and workflow data in a paginated manner.
Provide the total count of entries matching the search criteria.
This page outlines the following:
Rendering the Inbox or Search screen based on configurations.
Dynamically calling APIs using details provided in configurations.
InboxSearchComposer is a container component for the inbox and search screens. It consists of four child components, which can be rendered conditionally.
Prop Name | Description |
---|
The InboxSearchLinks component is used to render titles and links in the inbox.
The SearchComponent is used to render search or filter forms. It includes 'clear' and 'search' buttons for user interaction.
The Results table component is used to render a table with searched results.
The RenderFormFields component is used to render form fields specified in the 'fields' parameter of the configuration.
To fetch inbox details, the useCustomAPIHook
is utilized. This hook takes all necessary API details such as URL, query parameters, body, and config from the configuration (defined in MDMS).
Create config based on the sections to be displayed on the screen. The basic structure for the Inbox and Search screens is given below.
Based on the flag given for each section its visibility is controlled. If the ‘show’ flag is true, then the section is visible, else it is hidden.
Add API details in the top section, this API will be called via useCustomAPIHook and return the data. This consists of the below details.
Add search form config which can be used in both inbox/search screen. It consists of UIconfig containing label info, styling info, default form values, and fields which need to be rendered in the form. Refer below
Add Links config consists of link info, logo to be shown and title. Refer below
Add Filter form config which is similar to the search form. Refer below
Add Table (Search result) config consists of labels, column data and related jsonpaths to access the data passed. Refer below
To add any customisations on query params, request body, table columns or to add any custom validations in forms, related code can be added in the UICustomisations file as below
Once the above config is defined, created an index file/ Component in the pages folder. Fetch the config from MDMS and pass it to the inboxSearchComposer component as below
This approach is followed only in Inbox and Search screens currently.
Only one API can be called dynamically based on given configurations.
To use the latest Inbox search composer it has to be imported from the React components or Utilities
React components
package
Utilities:
package
We can develop custom React hooks like useCustomAPIMutationHook
to fine-tune the application API interactions. The custom hooks allow us to control how data is fetched and managed, aligning it perfectly with our requirements.
This custom hook, useCustomAPIMutationHook
, simplifies API calls for mutation operations in React applications using react-query
. It allows parameter and body customization for requests to a specified URL, seamlessly managing loading indicators and states. This hook streamlines API interaction and state management within components.
Create useCustomAPIMutationHook
under the following path:
To override the useCustomAPIMutationHook
, create a new custom hook with the desired enhancements. When considering overriding useCustomAPIMutationHook
, identify specific modifications required, such as adding additional parameters or altering data processing logic. Create a new custom hook, preserving the original functionality while incorporating these modifications to suit specific application needs.
We need to replace the usage of the original hook throughout the codebase with the new custom hook. This ensures that wherever the original hook is used, the modified functionality of the custom hook is applied instead.
There is a hook called useCustomMDMSV2
, which is used to get data from a Multi-Domain Master Service (MDMS) API. This hook makes it easier to request data, handle load, and prepare the received data for React applications.
useCustomMDMSV2
Create the hook under the following path:
Front-end module project structure
Before starting with the Module code, ensure your local development environment is set up. You can refer to the local development setup guide link given below for detailed instructions.
Download the UI code from the link here . if not done earlier
Follow the steps given below to create the project structure.
Once you have cloned the repository from Digit-Frontend, do the following.
Go to micro-ui-internals → packages → modules
.
Create a new folder with module's name , For example (Sample).
Create a folder called src and add the components , configs, hooks and pages inside that.
The project structure should be as in the image below:
After creating the new Sample
module, we need to create a package.json
file for the module, specifying the module name, version, scripts, and required dependencies.
To learn more about global config visit .
On the home page, users can see the cards mCollect, HRMS, NOC, Property Tax, etc These cards need to be added. Refer to the instructions on the to create an employee card.
Click on the to create a card for your module on the home page under "Citizen Services".
Refer to section to learn about globalConfig file.
Link to .
To learn more about the and process visit
Step 1: Add an entry in the helm chart of the frontend directory in the master branch of the forked repository.
Step 3: Modify the development environment as per requirements.
Mention the globalconfig file URL in your .
Access .
Main file:
Check the which contains other configs like filter, table, search, and mobile responsiveness.
The hook for the same is defined in
Use the latest (InboxV2)
Both Inbox and Search screens can be shown based on the input configurations passed to that component -
Configuration are mentioned in for local reference and it is fetched from the MDMS .
An example of a Search screen is available in .
A significant part of this component is another component called the . This is the popup that renders whenever the user clicks on a specific action. This popup is fully configurable through this configuration file . Popup configs are defined in this configuration file which are organised as per the businessService of the workflow configuration. Refer to the configMap object in this file for more details.
Prop Name | Description |
---|
Prop Name | Description |
---|
Prop Name | Description |
---|
Prop Name | Description |
---|
Reference of using this hook on a view screen:
Refer to the file here:
Refer to the file here -
The next step is to initialise the Dependency, refer to learn more about the setup
selectedOptions List of DropdownItem, which will be selected by default |
headerText | Config fetched from MDMS data |
links | Links to navigate to other screens |
customClass | Class to update styling |
logoIcon | Icon name and class to render in component |
uiConfig | Config to render search/filter form |
header | Title of form |
screenType | Type of parent screen, can be either ‘inbox’ or ‘search’ |
fullConfig | Entire config of screen which also includes API details |
config | Config to render table |
data | Search results need to be populated in table |
isLoading | Flag to pass to handle loading state |
isFetching | Flag to pass to handle loading state |
fullConfig | Entire config of screen which also includes API details |
fields | Config to render all form fields |
control, formData, errors, register, setValue, getValues, setError, clearErrors | Props to handle all form actions like collectibe data, setting errors, clearing errors etc. |
apiDetails | Includes all API details required to fetch data |
configs | Config fetched from MDMS data |
Once the project structure is ready, it is time to install and configure the module dependencies in the Master Data Management Service (MDMS). Follow the steps below to finalise these.
After creating the Sample
module and its package.json
file, you need to ensure that this module is enabled in the citymodule.json
file in the MDMS (Master Data Management Service) configuration. If it is not enabled, you need to update the MDMS configuration accordingly. You need to add this module to the root tenant in your environment from your branch.
file location
for reference: citymodule.json.
For illustration here, add the following module (sample) as given below:
Register the Sample UI module in three places so that it will be available to the developer at runtime as well as at the time of deployment. Below are the three places where the module needs to be registered:
micro-ui/web/micro-ui-internals/package.json
micro-ui/web/micro-ui-internals/example/package.json
Micro-ui-internals:- Open the micro-ui-internals
package.json
file and add the following inside the scripts:
In the example/package.json, add the following line:
In the web/package.json, add the following line:
The next step is to initailise the module.js, refer here to know more about the setup
DIGIT comes with common re-usable libraries that can be imported for use in a new module. Follow the steps below to import the required components.
We are reusing certain React components from our libraries, such as InboxSearchComposer
, FormComposerV2
, SubmitCard
, CardText
, and others. Refer to the link below to learn more about these components.
Learn more about our React components
All components are available in the link below. Digit-UI-Components
Steps to build a citizen portal for a module
This section of the guide enables developers to create their front-end citizen module from scratch which they can deploy on top of DIGIT UI. The new module will be visible as a "card" in the DIGIT citizen portal.
Steps to build the citizen portal for a module
This guide provides examples and illustrations on how to set up and integrate the most commonly used DIGIT UI libraries.
The sample screens are available here.
Customisation options for DIGIT UI
This document provides the customisation details for DIGIT UI. Customisation can be classified broadly into two types -
Overriding the Component/Hooks/CSS
Overwriting the required changes directly into the Micro-ui-internals
Overriding involves making all customization changes exclusively within the micro-ui/web directory.
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 overriding any components, re-register the same component in the same name in the customization folder. The latest changes are reflected.
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:
This page provides details about how the Banner image and Citizen Services Card are rendered.
The link to banner images and the labels and links of citizen services on the citizen services card are defined in the below MDMS file.
egov-mdms-data/data/pb/common-masters/uiHomePage.json at DEV · egovernments/egov-mdms-data
For mobile and desktop we have different banner images link. We can change the images link on the below object
Here we have two objects citizenServicesCard
and informationAndUpdatesCard
. Both of them have sideOption
object which is a link to View All page.
props
object contains the objects that we want to show on these two cards.
Change the label of the cards and add the navigation URL for each prop. Click on the card redirects users to the respective screen.
Similar to Banner image, for WhatsApp Banner Image, we have two objects for mobile and desktop view. On click of the image it will redirect to WhatsApp bot. The redirection URL is defined in the navigation URL param.
Multiple options can be selected.
Details about how the module cards are rendered in the Citizen Home screen and how to add a new Card.
All the modules that are enabled are defined in this file
DIGIT-Dev/frontend/micro-ui/web/micro-ui-internals/example/src/index.js
This array contains a list of modules that are enabled in DIGIT-UI. This array is passed down to DigitUIWrapper Component defined here: frontend/micro-ui/web/micro-ui-internals/packages/modules/core/src/Module.js. Here this array is passed down to this hook:
Now initData.modules will be containing an array of modules containing the following details about each module. Example object is shown here as PT module:
This array is further passed down to the CitizenHome component present in the file
frontend/micro-ui/web/micro-ui-internals/packages/modules/core/src/components/Home.js
This component will render a CitizenHomeCard component for every module that is present in the passed-down array of modules according to some conditions that are explained below.
As you can see in the home screen of Citizen, every module card has some links for it. Details of those links is stored in MDMS so that it becomes configurable. In the UI those details are fetched and accordingly module cards are rendered with the information fetched from the MDMS.
This module card data is stored in this file data/pb/ACCESSCONTROL-ACTIONS-TEST/actions-test.json. The format of the link data is described in such a way that every link object will have these key properties among others:
url → every link in the citizen side has this property set to “digit-ui-card”. It is used to filter all the links that belong to Citizen side
parentModule → describes to which module this link belongs
navigationURL → describes the destination url
In the UI this above mentioned data is fetched using this hook which calls this API egov-mdms-service/v1/_search
.
This hook call is made in this file frontend/micro-ui/web/micro-ui-internals/packages/modules/core/src/pages/citizen/index.js
After some processing in the UI this linkData will be an array in which every key will be module name and its value would be an object containing the links array and iconName and module Header, it will look like this:
Using this data every card along with it’s icon, header and links will be rendered in Citizen Home.
This rendering is done in this component frontend/micro-ui/web/micro-ui-internals/packages/modules/core/src/components/Home.js using CitizenHomeCard component.
Icon Configuration / Naming Convention
Every module icon is stored as an svg component in this file svgindex.js. Name of every svg component follows a common format which is the name of the module followed by Icon string. For instance, PTIcon is the icon name for PT module. This icon name details are also stored in the MDMS file, which is used to display appropriate icons on the module cards.
Now that we are aware of how the module cards are rendered with their respective data , let’s discuss how to add a new module Card.
To add a new module card , we need to add the name of the module in the list of enabled modules. The details of this module will be fetched using this same hook as explained above:
const { isLoading, data: initData } = Digit.Hooks.useInitStore(stateCode, enabledModules);
By doing this a new module card will be rendered but it’s header, links, and icon will not be rendered because we need to add this data in the MDMS. We need to add this data in this file as explained above actions-test.json and accordingly add matching ids in this file roleactions.json with rolecode property set to ‘CITIZEN’
Sample actions-test and roleactions object
Sample actions-test object
Sample roleactions Object
Multiple options can be selected.
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.
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 -
Pass the JSON path of the dependent key that requires runtime updates. In the example above, the target is on “populators.options”.
Update the options at runtime based on certain logic.
Note :
Make sure to pass the JSON path in an array.
The order in which these JSON path are passed is important. Later on, this order will be used to target the respective dependent object.
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 :
The dependency Object contains multiple actions which the pre-process function runs for us.
Translate - This targets the JSON path and does translation for the passed data.
updateDependent - This targets the JSON path and update the dependencies.
convertStringToRegex - This targets the JSON path and converts the String RegEx to RegExp based Regex.
Refer to the sample example below -
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.
Note: Ensure that the preprocessing call is optimized for performance. It should only be invoked when there is a change in the dependent values. As our dependent values are component states, the preprocessing should occur whenever the state changes, triggering a re-render of the component. To mitigate potential over-iterations, we employ useMemo to cache the result, ensuring efficient processing and minimizing unnecessary recalculations.
A similar utility is also developed for InboxSearchComposer. Refer to this same document for both utilities.
A new component called KibanaCard.js
has been introduced to render Kibana DSS based on the configuration provided in dashboardConfig
. This document outlines the steps to integrate the Kibana Dashboard with the DSS module.
In the dashboardConfig
, a new configuration has been added to render Kibana DSS. The configuration includes details that specify which Kibana dashboards to render.
So here moduleName refers to the module name in uiConstants master and pageName refers to the iframe routes route information.
Based on the configuration, we render the KibanaCard
component, passing moduleName
and pageName
as props.
Within KibanaCard
, we utilize the IFrameInterface
component. This component receives the following props passed from KibanaCard.
We can define kibana dashboard URL in common-masters in uiCommonConstants.json config. Below are the examples of the structure
This component calls MDMS-V2
common-masters to fetch the URL of the Kibana dashboard and render it using an iframe.
Additionally, if a date range filter is set by the user, we update the Kibana URL to reflect this. The following logic is applied to construct the contextPath
:
API to fetch common constants
URL: https://health-demo.digit.org/mdms-v2/v1/_search?tenantId=mz
Payload:
Response:
|
|
|
Text Date Time Geolocation Numeric Password Search TextArea | Default Filled Disabled NonEditable Focus Error Label Character Count Inner Label Info Help Text/ Description |
Radio Selection | Default Disabled Selected PreSelected |
Toggle | Default Disabled Selected PreSelected |
Primary Secondary Tertiary Link | Active Disabled Label Interactions |
Single Select Multi Select Sub type: Default Nested Tree | Default Disabled Selected Interactions |
Default Checked | Active Disabled Label Interactions |
Success Warning Failure |
Default Success Warning Error |
The next step is to register SampleModule
in module.js
, the module's entry file. To demonstrate rendering, display "Sample Module" using a simple <div>
element within the SampleModule
component. This creates a basic screen setup for the module, which can be customized or expanded as needed.
Add the below code in the Module.js file which is already created.
Initialize the module's custom hooks, configurations, and register components using initSampleComponents()
here.
Refer to the file here: Module.js
If there is a local server running, make sure to stop it. Restart by running yarn install
followed by yarn start
at the micro-ui-internals
level.
Hurray! Now, the screen is displayed below on visiting the given URL:
Refer to the below sections for a deeper understanding
This guide provides a step-by-step approach to creating an employee module screen with essential functionality. Learn how to set up the module, create a sample card, and integrate links for individual search and create pages. Following these steps ensures modularity and reusability in your code, making it easier to manage and scale.
Create a Sample card within the Sample module. This card will display links to pages within the module, such as Individual Create and Individual Search.
Create a SampleCard.js file under the following path:
Refer to the file here: SampleCard.js
Register the SampleCard
inside the Module.js
file.
Hurray! Now you can see the Sample Card with 2 links on the screen as visible in the below screenshot:
Nothing is rendered when clicking on the label. We need to set up the routes to fix this.
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.
Currently, the CSS is published in npm as @egovernments/digit-ui-css
Refer to the NPM link here - digit-ui-css.
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
index.html - 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 -
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 - index.html
Overwrite the complete existing CSS.
Note: If there is overwriting of the complete CSS, future upgrades will need manual work to take the upgrade/difference changes.
Reference doc for publishing any package to npm -
Steps to integrate external UI with DIGIT UI
This document provides the steps on how to integrate another UI into the DIGIT UI using iframe.
Enable the Utilities module.
Once the Utilities module is enabled, add the following changes to the master (file path given below).
Reference 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;
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
Employee view of the module
Now that we are done with setting up the citizen module, the next step is to build the employee portal on top of the DIGIT UI for the Birth Registration module. The employee portal is designed to support multiple workflows like verifying the information and approving or rejecting the registered details of citizens.
Build the employee portal for a module - Steps
The guide provides examples and illustrations on how to set up and integrate the most commonly used DIGIT UI libraries.
Refer to the sample screens here.
Screenshots of employee and citizen modules
This page provides the steps to resolve issues using the network tab on the browser.
While using the application or while performing some action if something fails we get generic error messages on the UI.
Such as - Something went wrong / Please try again or contact support.
Despite trying again, the same error message pops back up. What else could go wrong? The Network tab enables us to see more information about the Error.
To fetch more information in context to the error message -
Inspect the Page - On the page with the error message, right-click the page and choose Inspect in the dropdown menu.
Select the Network Tab - The browser’s network tab is a way to look directly at what’s happening behind the scenes of a page. It shows us not only the type of data being requested and passed as we interact with the page, but it also let's know if there are any actions that are failing. After selecting Inspect, a new window will appear. In this new window, click the Network tab. Then, select the XHR filter option. This will hide everything except API requests.
Refresh the Page - Click the Refresh button in your browser. Since the Network tab will only show us the requests that occur after the tab has been opened, we’ll need to refresh the page so that we can view the error as it occurs. As the page reloads, you’ll see various API requests populate the panel.
Re-create the Error - In order to understand what’s causing our error, we’ll first need to go through the same steps we took to get the error so that we can watch the request happen in real-time. In this case, to recreate the error we’ll click Update again. By re-creating the error, we’ll see exactly which request is causing the issue.
Find the Red-Line Item in the Network Panel - This is the error that occurs when clicking Update. The status is 400, which is the error code for “bad request.” Everything else has the status 200, which is the code for “OK,” meaning nothing went wrong for those other requests.
Preview the Error Details - Click the red-line item to see the error details. Clicking that line item will open a new frame on the right-hand side, and in this frame, you’ll see a few tabs: Headers, Preview, Response, Cookies, and Timing. In this case, stick with Preview since this contains the basic information.
View the Error Message - While in some cases you won’t see a specific message here, in this case, you’ll see the following:
Thanks to the network panel, you were able to take a look under the hood, diagnose the issue, and put a fix in place.
Monitor and trace user activity
To monitor and trace user activity on the client side, we need to enable telemetry in the local or development environment.
Whichever environment file has been used to deploy DIGIT, please make sure the above code blocks are added to the file. Dev has been used here as an example. This can differ based on the environment.
Redeploy the citizen, employee, and digit-ui modules using Helm. For example, to redeploy the citizen module, identify the docker image ID from the product release charts.
/DIGIT-DevOps/config-as-code/product-release-charts/DIGIT/dependancy_chart-digit-<version>.yaml
If you have deployed DIGIT v2.6, use the 2.6 release chart. If 2.7, use the 2.7 release chart. Search for the docker image ID of the citizen, employee and digit-UI modules and copy those.
Then, run the following commands to redeploy the citizen module with the updated variables in the environment file. This will replace the new values during deployment and configure it appropriately:
Repeat this exercise for the employee module. Redeploy the digit-ui module based on the instructions . Once the deployment is successful, we can track it into the Network tab by filter telemetry.
All content on this website by is licensed under a .
Steps to debug
This page provides the steps to debug the android application using a chrome browser.
Connect your android device to the system.
Go to developer mode in the mobile device and enable USB debugging.
Open the Chrome browser and navigate to the URL chrome://inspect
The browser shows the list of devices connected to the system.
Select the mSeva application and click on inspect.
This opens a new window. Here we can see the mobile preview and the developer tool.
Start debugging the application as we have done in normal web applications.
Configuration of privacy policy component on the login screen
A new feature, the Privacy Component, has been added to the login screen to enhance user transparency. This component displays privacy policy information based on the login configuration. Follow the steps below to configure this component on the login screen.
To render the Privacy Component, you must include specific configurations in the MDMS :
Master Name: commonUiConfig
Module Name: LoginConfig
If these configurations are not present, the configuration will be rendered instead.
The content displayed within the Privacy Component's pop-up will be filtered according to the module code
specified in the schema.
The fields on the login screen are fully configurable. Users can add or remove fields according to their specific requirements.
To ensure all mandatory fields are completed, the login button will be disabled until all required fields are filled. This ensures that users provide all necessary information before proceeding.
Here are some examples of different configurations for the login screen and their corresponding displays:
These configs will help to enable/disable the privacy declaration, at an instance level.
Screen:
Config:
Screen:
Config:
Localisation modules used:
This document will help us generate the APK for Citizen and Employee applications.
Android offers a variety of ways to present content to a user. To provide a user experience that’s consistent with the rest of the platform, it’s usually best to build a native app that incorporates framework-provided experiences, such as or . Additionally, you can use Google Play-based experiences, such as and , where Google Play services are available. Some apps, however, may need increased control over the UI. In this case, a WebView
is a good option for displaying trusted first-party content.
In Egov we create only responsive web apps instead of native apps (Android, IOS). The Android web view is used to render the out web application.
Generate APK for citizen application
Go to build. Gradle file there we have created multiple environments(UAT and PROD), please select the environment where you want to generate APK and put your web application URL.
Update the web application URL as required Application URL.
buildConfigField 'String', 'url', '"https://uat.digit.org/citizen/user/register"'
also, specify the citizen gateway hostname if not using Mastercard,
buildConfigField 'String', 'gatewayHost', '"migs.mastercard.co.in"'
3. Save the file on the left side of the Android studio. Click Build Variants and select the applicable build variant.
4. Click on Build menu, select Build APK(s) submenu.
It will take some time to generate and it will show generated location.
Generating APK for employee application
1. Go to build. Gradle file there we have created multiple environments (UAT and PROD), please select the environment where you want to generate APK and put your web application URL.
2. Save the file, left side of the android studio click Build variants, and select build variant.
3. Click on the build menu, and select Build APK(s) submenu.
It will take some time to generate and it will show generated location.
Follow the 3rd and 4th steps mentioned above.
Click on the Build menu and select Generate Signed Bundle / APK.
Select 1st radio button - Android App Bundle.
Enter the information presented in the form and click on Next.
Upload the APK generated by the 4th step and upload it to the play store.
4) How to Register New Module in Digit UI? Creating config into mdms:-
If you are creating a new module then, first we need to enable that module as true in citymodule.json and .
Suppose your module name is BR(Birth-Registration) then change the module and code as BR. and update the citymodule.json file. or
If the User is a citizen then we will configure the .env file as follow:-
If the User is an Employee then we configure the .env as follows:-
6) In Digit UI Where do we need to add the .env file when we run the react app from micro-ui/web?
Add the .env file in the micro-ui/web/src/
__All content on this website by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Data Customisation: The data can be modified through MDMS and localization updates. MDMS Path: to access the privacy component file.
Clone the repo.
Open the below location in the .
5) In Digit UI Where do we need to add the .env file? Add the .env file in the example folder -
All content on this website by is licensed under a .
Create Form Screen
Create and integrate a form within a micro-frontend architecture using the DIGIT framework.
Write Employee Module Code
Create an employee module screen with essential functionalities
Reusable Components
Reusable Hooks
Employee Module Setup