This is the Anika client intake form frontend.

It is a React/Redux single page app, deployed as a static site which is hosted on AWS S3 at intake.anikalegal.org.au. The app depends on a backend API at anikalegal.org.au.

Clients visit the webapp from the Anika website, looking to get help with their rental repairs issue. They have to answer a bunch of questions so that we can begin their case. When they submit their answers, the webapp sends them to the backend, which then stores their case info and alerts Anika staff.

If you are using Windows ensure that git is setup to use LF not CLRF

git config core.autocrlf false
git rm --cached -r .
git reset --hard

Envars are stored in .env and encrypted using transcrypt. You can see encryoted files with transcrypt --list.

To intialise the repository on cloning run

transcrypt -c aes-256-cbc -p $TRANSCRYPT_PASSWORD

The values of these secrets will be provided to you if you need them. They should be available in the Tech team Bitwarden account.

You will need Node (prefer v11+) and yarn installed locally.

yarn install

You can then start the development server and webpack compilation:

yarn html  # Build HTML from Handlebars template
yarn dev  # Run dev server on http://localhost:3000

There are two environments, each of which has a corresponding backend:

• test frontend, talks to test backend
• prod frontend, talks to prod backend

Each of these environments correspond to a similarly named S3 bucket in the Anika AWS account. DNS is managed using Anika's CloudFlare account.

These branches are used for deployment:

• develop deploys to the test
• master deploys to prod

When making a change or bugfix, you should:

• create a feature branch from develop called feature/my-branch-name and test it locally
• merge the branch into develop and push to GitHub to trigger a release to the test environment
• check your changes in the test environment
• merge the develop into master and push to GitHub to release your change to prod

Deployment is run on demand via GitHub Actions using the bash scripts in /scripts. Deployment can also be run manually using the bash scripts in /scripts/release/.

Errors logged using Sentry can be viewed here.

Sentry is used via @sentry/browser. The ErrorBoundary component is used to catch and handle these errors. The logException utilities method can be used in both dev and prod to handle errors and report them to Sentry.

The general idea is that the root app App renders the routes from routes/. Each route, defined in routes/routes.js renders a view, which can then render components and containers.

├── .circleci               CircleCI config
├── .storybook              Storybook config
├── dist                    build artifacts (not in version control)
├── public                  static files to be deployed (in version control)
│   └── static
│       ├── fonts           fonts
│       ├── images          images
│       ...
├── scripts                 Bash scripts for deployment
└── src
    ├── analytics           analytics setup and events
    ├── api                 interface for all HTTP API calls
    ├── consts              constants
    ├── containers          "smart" React components (older way of organising code)
    ├── features            components split up by feature (newer way of organising code)
    |   ├── form            components for the questionnaire form
    |   └── generic         generic, resuable components
    ├── questions           form question definitions
    ├── routes              routes and utilities for React Router
    ├── state               Redux stuff (state / actions / reducers)
    ├── styles              global SCSS stylesheets
    ├── utils               "helpful", reusable tools
    ├── views               view React components
    ├── app.js              root React component
    ├── globals.js          global FlowJS type definitions
    ├── index.js            app entry point
    ├── index.hbs           Handlebars HTML template
    ├── types.js            FlowJS type definitions
    ...

This project use FlowJS for type checking. See more details in .flowconfig.

You can run a type check as follows:

yarn flow check src # Typecheck JS code

You can setup FlowJS support in VSCode, which is much better than using the CLI.

Linting is done with Prettier. Config lives in .prettierrc. We also use eslint in addition to Prettier, config lives in .eslintrc.js. ESlint is not used in CI builds - it's just for developer convenience.

yarn format  # Format JS code (recommended)
yarn lint  # Lint JS code (run in CI jobs)

You can setup VSCode to auto-format files on save. This is recommended.

There are no unit tests or integration tests.

Ths project has Storybook setup to allow us to build components independently of their UI. Config lives in .storybook.

View the prod storybook here.

Run storybook on http://localhost:3001 with

yarn story

It's OK to break stories and fix them later.