conversion-flow v1.18.1

Conversion Flow

AVON Recruitment Program - Conversion Flow

Conversion flow is a web application that an Avon applicant is redirected to via email or SMS to verify their information and accept Avon terms and conditions.

Available Scripts

    npm run dev
    npm run start
    npm run start:docker
    npm run build
    npm run build:env:dev
    npm run build:env:prod
    npm run storybook
    npm run storybook:build
    npm run test
    npm run test:coverage
    npm run test:clear
    npm run lint
    npm run lint:fix
    npm run create-component

Install

npm i

Run local dev server

First update your .env.development file with a valid API URL and default Access Token.

npm run dev

Build production ready app and run it

npm run build npm run start -p $PORT

Run storybook locally

Using storybook you can take a look at all the different components we have created for Avon Grow. -> With storybook you can interact with a component and see how it works -> Using knobs you customise the components and see how different scenarios will act out

`npm run storybook`

Once storybook is running you can access it through port 6006 - http://localhost:6006/

Run linting checks (without and with fixing errors)

npm run lint # Done by ESLint
npm run lint:fix # Done by ESLint

## Git

update your local branch with master and replay your changes on top. makes for cleaner git history.

git pull --rebase origin master

Development mode.

Conversion flow needs to receive certain querystring parameters

Open http://localhost:3000/RU/ru?link=8734534543 to view it in the browser.

• market, language, and device are the same as PRP/MRA
• link is the unique email token provided by RGA

Dockerised setup

We have created a docker-compose within this repo that will spin up both MRA and RGA within Docker. It supports hot reloading of the code, and uses a lightweight container approach for local development.

Run using:

docker-compose up

Kill using:

docker-compose down

We have also created a dockerfile that will be used for deployments throughout the different Azure environments.

You can build it using:

docker build -t conversion-flow .

and run it using:

docker run -p 3000:3000 conversion-flow

We're currently investigating using environment variables at runtime, which will vastly speed up the deployment and pipeline process, and make it much more stable.

### runtime env vars

verify docker-compose config

docker-compose -f docker-compose.yaml config

to start from the address step visit: http://localhost:3000/RU/ru?link=877773a9-b6e8-47f9-a8a8-157f0a853987

Husky and lint-staged

Git good at git:

pre-commit hook working with .git partially staged files and hunks via lint-staged

Commit only part of a file

lint-staged

Testing

This project mainly uses React Testing Library to create the Unit Tests. The tests run through the Jest testing framework. Note: Some Enzyme testing is used for certain tests that aren't applicable for RTL.

You can run the tests by using npm run test. You can run the test and get coverage at the same time by using npm run test:coverage.

• If you do this, you can see a report of the percentage of test coverage inside:
  • coverage -> lcov-report -> index.html

In this project we have a requirement for 100% test coverage.

Each file or component needs to have been tested completely before you can commit code to the repo.

Local DNS

To simulate the domain location (.ru, .co.uk etc.) you will need to add a host mask to your etc host file

This can be done by doing the following in your terminal: sudo nano /etc/hosts

Below all of the current entries, add the following line: 127.0.0.1 reg.nabor.avon.ru. Make sure the local.reg.avon.ru bit lines up with the other items in the column.

Now go to http://reg.nabor.avon.ru:3000/RU/ru?link=877773a9-b6e8-47f9-a8a8-157f0a853987. This will allow you to test locally with .ru in the url.

UI Guideline

UI Guidelines, styleguide and examples are available at: https://app.zeplin.io/project/5cc068f9866b9b265424dddb/dashboard

Branch naming

This repository consists only of a master branch, with no develop branch. All new code should be merged straight to master from the branches.

Branch names should follow the [feature]/[category]/[jira ticke tnumber]-name-with-dashes convention. The names should explain the purpose of the branch.

The categories are:

• major - Breaking changes, large new features
• minor - Features being added or expanded
• patch - Resolving bugs or broken functionality

For example: feature/minor/avrp-1-button-component