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 sample.js file.
To check the different types of configurations, refer to the fieldSelector 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 - ViewProperty.js.
The hook details for the same is mentioned in useGenericViewProperty.js
The service configuration details are available in Search.js
To create any inbox screen, use the InboxComposer and add the following configurations:
Main file: EdcrInbox
Check the folder which contains other configs like filter, table, search, and mobile responsiveness.
The hook for the same is defined in useEDCRInbox.js
Use the latest InboxSearchComposer (InboxV2)
Both Inbox and Search screens can be shown based on the input configurations passed to that component - BillInbox.js
Configuration are mentioned in InboxConfig for local reference and it is fetched from the MDMS BillInboxConfig.
An example for Search screen is available in SearchConfig.
There are two common components for workflow related actions and timeline management.
WorkflowActions - WorkflowActions
WorkflowTimeline - 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 ApplicationDetailsContent 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.
A significant part of this component is another component called the WorkflowPopup. This is the popup that renders whenever the user clicks on a specific action. This popup is fully configurable through this configuration file Popup Config. 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.
Approach to render Inbox and Search screen content based on config passed via MDMS data.
This page provides the approach details for -
rendering the Inbox screen or Search screen based on the config
calling the API dynamically based on API details passed via config
This is a container component for inbox and search screens. It consists of 4 children components which can be rendered conditionally.
| Prop Name | Description |
|---|
This component is used to render titles and links in the inbox.
| Prop Name | Description |
|---|
This component is used to render search or filter forms with ‘clear’ and ‘search’ buttons.
This component is used to render a table with searched results.
This component is used to render form fields passed in the 'fields' parameter in the config
To fetch inbox details, ‘useCustomAPIHook’ is used which takes all the API details like URL, query params, body, config etc. from config (defined in MDMS).
Create config based on the sections that need to be displayed on the screen. The basic structure for 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
| Prop Name | Description |
|---|
| Prop Name | Description |
|---|
| Prop Name | Description |
|---|
configs | Config fetched from MDMS data |
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 |
This page provides the steps to configure the FormComposer.
For complex configuration or screen details refer to documentation on Utility - preprocess
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 DIGIT-WORKS repo.
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 Config Link.
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.
Access Configuration link.
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.
