LE Customer Portal

Development

yarn install
cp .env.example .env
cp cypress.env.json.example cypress.env.json
Optional: set PRE_COMMIT_HOOK=1 in .env
yarn dev

Sever Side Rendering (SSR)

This application utilises Server Side Rendering for better preceived performance on the web. However, this feature in a development environment can be a hinderance as our SSR server does not get any hot-reload changes applied to it where as the web version will. Often this causes the SSR to be out of sync with the web render as you develop more.

The solution to this is to turn off SSR via the environment variable SSR_DISABLED=true.

NOTE: SSR_DISABLED=false does not turn it off! You have to clear the value.

Development with local HTTPS server

Using https-localhost - check you have the required dependencies for your OS.

This only works if you have configured APIs also running on localhost (see here).

yarn dev:https

Formatting

Eslint is used as a formatter for this project. Please see the eslint config (eslintrc.json) for details.

Test

yarn test:watch
yarn test:snaps
yarn lint

or just:

yarn test

End to end tests

See:

• https://github.com/lux-group/www-le-customer/tree/master/cypress
• https://github.com/lux-group/www-le-customer/tree/master/test/e2e_deprecated

Cypress

Dev tests

Sometimes you want to write some e2es for features not yet in production that may break frequently (due to unstable APIs) and you don't want to block merging to master. You can use devIt and devDescribe so your tests will only be run when "DEV": true is set in cypress.env.json. This means you can run these tests locally, but they will be skipped in PR/master tests.

Feature tests

If you'd like to group your tests behind a specific environment variable, featureIt & featureDescribe allows you to specify a environment variable which will toggle all your tests on/off in different environments. Useful similar to the above, except its easier for you to go live and rollback with a simple env variable. Variable needs to be defined in .env with CYPRESS_ prefix. For example

// .env
CYPRESS_TRIP=true
CYPRESS_TOURS=true

// cypress/utilities/common.js
export type testSuiteTypes = 'TRIP' | 'TOURS'

// spec.ts
featureIt('TOURS', ....)

Running E2Es via WSL2

For Cypress or Nightwatch tests to work via WSL2, you need the X server installed in Windows and the DISPLAY env var pointing to it. See this article for details.

Testing selectors

If you need a selector for testing purposes add a data-testid to the component because we are moving towards react-testing-library for testing

More info here here

Example:

data-testid="increment"

Static files

An env var, STATIC_FILES_DIRECTORY, indicates a directory of static files that will be served from the server. e.g. static/test, static/prod. Files such as robots.txt can be set up this way. Different deploys can be set up to use different directories.

There is also a directory called images, anything put here will be served under /images by the server.

Analysing the bundle size

To find out why the bundle is so big, here is what you can do. Run yarn stats to generate stats.json in the project root. Then go here and drag the file onto the page.

Alternatively, in your .env file set "WEBPACK_ANALYSE" to true and run a production browser build. This will run webpack analyzer plugin and open in your default web browser upon completion.

copy WEBPACK_ANALYSE=true to .env Run yarn build:prod:browser

Storybook

We currently use Storybook as a way of previewing components in our design system. This is hosted on Chromatic and rebuilt on every master merge. Use your github credentials to login then click the "View Storybook" button.

https://www.chromatic.com/library?appId=6058033943ab64002196aa55

You can also run storybook locally via yarn storybook

Experiments

To test an Optimize experiment locally, set the appropriate environment variable to ENABLE:n in your .env file, where n is the experiment variant that you want to enable.

This approach also allows the experiment to be enabled for everyone in any environment.

Working with Icons

Guidelines are provided here

Resources

• Google tag manager integration https://developers.google.com/tag-manager/quickstart
• Conventions https://github.com/lux-group/www-le-customer/blob/master/docs/index.md

Available environments

| Environment | Description | Url | | ----------------------------- | --------------------------------------------------------------------------------------- |-----------------------------------------------------------| | Review app | Used to test the work you are trying to merge into master when you open a pull request. | https://{shortened branch name}-preview.luxuryescapes.com | | canary-test-le-www-customer | Used to test features that are not 100% ready or rely on a feature toggle. | https://canary-test.luxuryescapes.com | | test-le-www-customer-syd | Used to test and to run the remote e2e. | https://test-customer.luxuryescapes.com | | canary-le-customer-www | Test with prod data. | https://canary.luxuryescapes.com | | prod-le-www-customer-syd | Production app. | https://luxuryescapes.com |

Sentry

In test and production, unhandled errors are logged in Sentry: https://sentry.io/organizations/luxury-escapes-9m/issues/?project=1488479

Hall of fame

Eddie woz here - 2019-06-24

Troubleshooting

Why do my commits take so long!?

Linting is enabled pre-commit which should typically take ~3-10 seconds to complete. However if you've never run eslint before on this machine, the cache needs to be built which can take over 100 seconds. Manually run yarn lint:js to build this cache ahead of time. If your Adamant on skipping linting, you can run git commit with the --no-verify argument. If you want to permenantly disable pre-commit hooks set PRE_COMMIT_HOOK=0 in your .env.

Preview App

Preview apps are not automatically created for every branch. To preview the changes before merging the branch to Master add a comment to your PR with /deploy text in it. Within 10 seconds you should see a rocket emoji for the comment - it means that release process has started. Deployment process includes building the app, creating and uploading docker image with it, then creating a number of infrastructure components required for the app to function. In my tests it took ~20 minutes.

When it finishes - you'll see a link in the deployment block of the PR. Open it to see the preview app.

Preview apps will be deleted when PR is closed or merged. We also delete Preview apps that are older than 2 days. New changes pushed to your branch won't automatically redeploy the new version to preview-app - you can always update/recreate Review app with /deploy comment though.

To troubleshoot failed deployments you can open 'Actions' tab and see the details.

Adding env vars to review apps

Right now to add an env variable to review app you need to put it to cloud formation file ContainerDefinitions.Environment with the rest of env vars.