Jetshop Flight

Welcome to your new Jetshop Flight shop! Here's some resources to help you getting started.

Note that more extensive documentation is available at the Jetshop Flight documentation site.

Table of Contents

• Jetshop Flight
  • Table of Contents
  • Folder Structure Overview
  • Available Scripts
    • yarn start
    • yarn test
    • yarn cypress
    • yarn cypress:open
    • yarn build
    • yarn build:analyze
    • yarn serve
    • yarn serve:dev
    • yarn intl
  • Syntax Highlighting in the Editor
  • Debugging in the Editor
  • Translations and localization
  • Adding Images, Fonts, and Files
  • Using the public Folder
    • Adding Assets Outside of the Module System
    • When to Use the public Folder
  • Adding Custom Environment Variables
  • Running Tests
    • Filename Conventions
    • Command Line Interface
    • Writing Tests
  • Cypress Integration Tests

Folder Structure Overview

After running the initialization script, you end up with a lot of files in your project:

my-shop/
  cypress/
  node_modules/
  public/
    favicon.ico
    manifest.json
    robots.txt
  src/
    client.js
    server.js
    // etc...
  translations/
  .eslintrc
  .gitlab-ci.yml
  .graphqlrc.yml
  cypress.json
  index.html
  jsconfig.json
  linaria.config.js
  package.json
  README.md
  schema.graphql
  yarn.lock

For the project to build, these files must exist with exact filenames:

• index.html is the page template used to render all pages on the server
• src/client.js is the entry point for the client
• src/server.js is the entry point for the server
• translations/ contains translation files for all languages supported by Jetshop

Available Scripts

Flight uses yarn for managing packages and running scripts. In the project directory, you can run:

yarn start

Runs the app in the development mode. Open http://localhost:3000 to view it in the browser.

The page will reload if you make edits. You will also see any lint errors in the console.

yarn test

Launches the test runner in the interactive watch mode. See the section about running tests for more information.

yarn cypress

Launches cypress in headless mode and runs all cypress tests. Note: The development or production server has to be running as well!

yarn cypress:open

Launches cypress with the UI open, making it easier to debug failing tests. Note: The development or production server has to be running as well!

yarn build

Builds the app for production to the build folder. It correctly bundles React in production mode and optimizes the build for the best performance.

The build is minified and the filenames include the hashes. Your app is ready to be deployed!

yarn build:analyze

Same as the regular build command, but this also enables webpack-bundle-analyzer, which helps you analyze the output bundle and identify huge components or dependencies.

yarn serve

Starts the production server, depends on that yarn build has already been run.

yarn serve:dev

Starts the production server with the debugger attached, depends on that yarn build has already been run.

yarn intl

Runs the intl utility, see Translations and localization for more information.

Syntax Highlighting in the Editor

To configure the syntax highlighting in your favorite text editor, head to the relevant Babel documentation page and follow the instructions. Some of the most popular editors are covered.

Debugging in the Editor

This feature is currently only supported by Visual Studio Code editor.

Visual Studio Code supports debugging out of the box with Create React App. This enables you as a developer to write and debug your React code without leaving the editor, and most importantly it enables you to have a continuous development workflow, where context switching is minimal, as you don’t have to switch between tools.

You would need to have the latest version of VS Code and VS Code Chrome Debugger Extension installed.

Then add the block below to your launch.json file and put it inside the .vscode folder in your app’s root directory.

{
  "version": "0.2.0",
  "configurations": [{
    "name": "Chrome",
    "type": "chrome",
    "request": "launch",
    "url": "http://localhost:3000",
    "webRoot": "${workspaceRoot}/src",
    "userDataDir": "${workspaceRoot}/.vscode/chrome",
    "sourceMapPathOverrides": {
      "webpack:///src/*": "${webRoot}/*"
    }
  }]
}

Start your app by running yarn start, and start debugging in VS Code by pressing F5 or by clicking the green debug icon. You can now write code, set breakpoints, make changes to the code, and debug your newly modified code—all from your editor.

Translations and localization

Flight comes with support for translations and localizations via the package @jetshop/intl. To use this in a component, just import the default import from @jetshop/intl and call the function with the original string (preferrably in English):

import t from '@jetshop/intl';

function MyComponent() {
  return (
    <h1>{t('This text is translatable')}</h1>
  );
}

This will create a translatable string, that can be overridden for each language in the corresponding .json file inside the translations/ folder. Read more about the translation utility on the Jetshop Flight Documentation site.

Adding Images, Fonts, and Files

With Webpack, using static assets like images and fonts works similarly to CSS.

You can import a file right in a JavaScript module. This tells Webpack to include that file in the bundle. Unlike CSS imports, importing a file gives you a string value. This value is the final path you can reference in your code, e.g. as the src attribute of an image or the href of a link to a PDF.

To reduce the number of requests to the server, importing images that are less than 10,000 bytes returns a data URI instead of a path. This applies to the following file extensions: bmp, gif, jpg, jpeg, and png. SVG files are excluded due to #1153.

Here is an example:

import React from 'react';
import logo from './logo.png'; // Tell Webpack this JS file uses this image

console.log(logo); // /logo.84287d09.png

function Header() {
  // Import result is the URL of your image
  return <img src={logo} alt="Logo" />;
}

export default Header;

This ensures that when the project is built, Webpack will correctly move the images into the build folder, and provide us with correct paths.

The final filenames in the compiled bundle are generated by Webpack from content hashes. If the file content changes in the future, Webpack will give it a different name in production so you don’t need to worry about long-term caching of assets.

Using the public Folder

Adding Assets Outside of the Module System

You can also add other assets to the public folder.

Note that we normally encourage you to import assets in JavaScript files instead. For example, see the sections on adding a stylesheet and adding images and fonts. This mechanism provides a number of benefits:

• Scripts and stylesheets get minified and bundled together to avoid extra network requests.
• Missing files cause compilation errors instead of 404 errors for your users.
• Result filenames include content hashes so you don’t need to worry about browsers caching their old versions.

However there is an escape hatch that you can use to add an asset outside of the module system.

If you put a file into the public folder, it will not be processed by Webpack. Instead it will be copied into the build folder untouched. To reference assets in the public folder, you need to use a special variable called PUBLIC_URL.

Inside index.html, you can use it like this:

<link rel="shortcut icon" href="%PUBLIC_URL%/favicon.ico">

Only files inside the public folder will be accessible by %PUBLIC_URL% prefix. If you need to use a file from src or node_modules, you’ll have to copy it there to explicitly specify your intention to make this file a part of the build.

When you run npm run build, Create React App will substitute %PUBLIC_URL% with a correct absolute path so your project works even if you use client-side routing or host it at a non-root URL.

In JavaScript code, you can use process.env.PUBLIC_URL for similar purposes:

render() {
  // Note: this is an escape hatch and should be used sparingly!
  // Normally we recommend using `import` for getting asset URLs
  // as described in “Adding Images and Fonts” above this section.
  return <img src={process.env.PUBLIC_URL + '/img/logo.png'} />;
}

Keep in mind the downsides of this approach:

• None of the files in public folder get post-processed or minified.
• Missing files will not be called at compilation time, and will cause 404 errors for your users.
• Result filenames won’t include content hashes so you’ll need to add query arguments or rename them every time they change.

When to Use the public Folder

Normally we recommend importing stylesheets, images, and fonts from JavaScript. The public folder is useful as a workaround for a number of less common cases:

• You need a file with a specific name in the build output, such as manifest.webmanifest.
• You have thousands of images and need to dynamically reference their paths.
• You want to include a small script like pace.js outside of the bundled code.
• Some library may be incompatible with Webpack and you have no other option but to include it as a <script> tag.

Note that if you add a <script> that declares global variables, you also need to read the next section on using them.

Adding Custom Environment Variables

Your project can consume variables declared in your environment as if they were declared locally in your JS files. By default you will have NODE_ENV defined for you, and any other environment variables starting with REACT_APP_ or FLIGHT_.

For performance reasons, the environment variables are embedded during the build time. This means that if you change an environment variable you need to make a new build.

Note: You must create custom environment variables beginning with REACT_APP_ or FLIGHT_. Any other variables except NODE_ENV will be ignored to avoid accidentally exposing a private key on the machine that could have the same name. Changing any environment variables will require you to restart the development server if it is running.

These environment variables will be defined for you on process.env. For example, having an environment variable named REACT_APP_SECRET_CODE will be exposed in your JS as process.env.REACT_APP_SECRET_CODE.

There is also a special built-in environment variable called NODE_ENV. You can read it from process.env.NODE_ENV. When you run npm start, it is always equal to 'development', when you run npm test it is always equal to 'test', and when you run npm run build to make a production bundle, it is always equal to 'production'. You cannot override NODE_ENV manually. This prevents developers from accidentally deploying a slow development build to production.

These environment variables can be useful for displaying information conditionally based on where the project is deployed or consuming sensitive data that lives outside of version control.

Running Tests

Fligt uses Jest as its test runner. Jest is a Node-based runner. This means that the tests always run in a Node environment and not in a real browser. This lets us enable fast iteration speed and prevent flakiness.

While Jest provides browser globals such as window thanks to jsdom, they are only approximations of the real browser behavior. Jest is intended to be used for unit tests of your logic and your components rather than the DOM quirks.

Filename Conventions

Jest will look for test files with any of the following popular naming conventions:

• Files with .js suffix in __tests__ folders.
• Files with .test.js suffix.
• Files with .spec.js suffix.

The .test.js / .spec.js files (or the __tests__ folders) can be located at any depth under the src top level folder.

We recommend to put the test files (or __tests__ folders) next to the code they are testing so that relative imports appear shorter. For example, if App.test.js and App.js are in the same folder, the test just needs to import App from './App' instead of a long relative path. Colocation also helps find tests more quickly in larger projects.

Command Line Interface

When you run yarn test, Jest will launch in the watch mode. Every time you save a file, it will re-run the tests, just like yarn start recompiles the code.

The watcher includes an interactive command-line interface with the ability to run all tests, or focus on a search pattern. It is designed this way so that you can keep it open and enjoy fast re-runs.

Writing Tests

To create tests, add it() (or test()) blocks with the name of the test and its code. You may optionally wrap them in describe() blocks for logical grouping but this is neither required nor recommended.

Jest provides a built-in expect() global function for making assertions. A basic test could look like this:

import sum from './sum';

it('sums numbers', () => {
  expect(sum(1, 2)).toEqual(3);
  expect(sum(2, 2)).toEqual(4);
});

All expect() matchers supported by Jest are extensively documented here. You can also use jest.fn() and expect(fn).toBeCalled() to create “spies” or mock functions.

Cypress Integration Tests

Flight also comes with Cypress Integration Tests out of the box. These tests are run everytime you push a commit to your Gitlab repository. By default we provide a very basic set of essential integration tests for making sure that the critical purchase flows are working.

Have a look in cypress/integration/essentials.spec.js to see how these tests are set up. When you change shopid from demostore to your new shop instance, you might see that the tests are suddenly failing. This is usually because the category and product we use in the default test does not exist in your Jetshop instance. To fix this, update the urls defined in the top of the file with a category and product that is available in your shop.