Form and Ribbon TypeScript

Introduction

This repo consists of the typescript implementation of the event handlers in Form and Ribbon Components (i.e. OnLoad, OnChange events, Ribbon Commands/Rules) and their respective unit tests.

Repo Hierarchy

The following section will give an overview of the repo hierarchy. A comment is included next to folders/files detailing the type of data being saved here.

FormAndRibbonComponents
|-- src
|   |-- Account
|   |   |-- Form - [Classes of all Event Handler runnable classes which will call the corresponding Implementation classes.]
|   |   |-- Ribbon - [Classes of all runnable classes which will call the corresponding Implementation classes.]
|   |   |-- Account.ts - [Implementation Classes for form or field events.]
|   |   `-- RibbonAccount.ts - [Implementation classes for commands or rules in Form Ribbons.]
|   |-- Appointment
|   |-- Engagement
|   |-- MeetingPlanner
|   |-- Enums
|   |   `-- Global + Specific Enums for classes
|   `-- AccountForm.ts - [Top level functions which can be directly accessed from the solution..]
|-- test
|   |-- helpers
|   |   `-- general
|   |       `-- AlertHelper.helper.ts - [Stub Classes for the AlertHelper methods.]
|   `-- AccountFormTests.test.ts - [Unit test cases for the Account form.]
|-- package.json
`-- webpack.config.js

Libraries Used

• @types/xrm
  • Repo for high quality Typescript XRM definitions.
  • https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/xrm
• @d365ce/common-functions
  • KPMG Repo which contains common features we can re-use across our TS/JS packages.
• xrm-mock
  • xrm-mock is a fake implementation of the Dynamics 365 Client API and Xrm object model. Written in TypeScript against @types/xrm definitions.
  • https://github.com/camelCaseDave/xrm-mock
• sinon
  • Standalone and test framework agnostic JavaScript test spies, stubs and mocks
  • https://github.com/sinonjs/sinon

Generating output JS code

Development purposes: npm run dev

Production purposes: npm run build

On the successful completion of these scripts, the output JS code will be saved in the folder "build" in its corresponding file.

• Calling one of the functions in the CRM system follows the following format:
  • "KPMG.CE." + [NAME OF CLASS] + "." + [NAME OF METHOD]
  • eg: KPMG.CE.AccountForm.onLoadForm

Current Features

Webpack is being used to build the files for deployment, at present it creates the following as shared files -

• Configuration.js
  • Provides access to the various configuration functions from the common-functions library, i.e. cached configuration and user settings
• Helpers.js
  • Provides access to a number of helpers such as the alert functionality and form helper

The above are exposed as global variables and can be accessed under the KPMG.CE namespace

We've also separated the source maps out to a different file to keep file sizes to a minimum, this should be included in the release.

Note: When deploying in CE please ensure virtual folder structures are used.

Unit Testing

Library Used: Sinon JS

All unit tests related to the current repo are stored within the "test" folder. The contents of this file are stored as follows:

- "test\helpers"
    + Contains any setup helper TS files pertaining to each entity being tested.
- "test\helpers\general"
    + Generic helper files which will be used to stub common methods of the following interfaces
        - IAlertHelper
        - IFormHelper
        - ISettings
        - IUserSettings
    + XrmData

To generate code coverage summary, run one of the following scripts: - npm run dev - npm run build

The Test Coverage result will be generated in a folder named "coverage" in the solution directory. By installing the VS Extension "Live Server" from the Marketplace, you can open the "index.html" for an in-depth look at the Test Coverage result.

Further explanation on how to read the coverage report can be found in the link below. - https://krishankantsinghal.medium.com/how-to-read-test-coverage-report-generated-using-jest-c2d1cb70da8b

Contribute

When implementing a new change, ALWAYS create a new branch from the branch "origin/project/development". New branch names should follow the following naming format: - "project/feature/" + [implementation name] - eg: project/feature/this-is-a-test-name

All changes should utilise pull requests to enter the main branch.

All code which is included in this repo MUST be unit tested. For mocking the Xrm features, use xrm-mock

TODO

• Migrate and refactor existing Account OnLoad to new ways of working
• Migrate and refactor existing Account Form Ribbon controls
• Migrate additional records
• Implement Unit Testing for migrated code