casino777-frontend v0.2.108

Casino777.be

Welcome to the main repository for the casino777.be website. This repository contains the source code, documentation, and other resources related to the website.

Purpose of the project

The casino777.be website is an online casino platform that allows users to play a wide range of casino games, including slots, table games, and live casino games. The website is designed to be user-friendly, fast, responsive, and secure.

Status Badges

Coverage:lines: 44.88%Coverage:linesCoverage:lines44.88%44.88%

Coverage:branches: 36.91%Coverage:branchesCoverage:branches36.91%36.91%

Tech Stack

The website uses a combination of technologie, including : | Technology | Description | Documentation | | ----------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | | Typescript, typed superset of JavaScript that adds static type checking and other features to the language. | Link to documentation | | | (v18) React a popular front-end JavaScript library for building user interfaces. | Link to documentation | | | (v13) Next JS a framework for building server-side rendered React applications. | Link to documentation | | | TailwindCSS - a utility-first CSS framework for quickly styling web applications. | Link to documentation | | | Jest - a popular Javascript testing framework | Link to documentation | | | Testing Library - a set of utilities for testing React components and applications. | Link to documentation | | | Cypress framework is a JavaScript-based end-to-end testing framework | Link to documentation | | | Workbox - a set of libraries and Node.js modules that make it easy to cache assets and take full advantage of features used to build Progressive Web Apps. | Link to documentation | | | Storybook - a development environment for UI components. | Link to documentation |

Development/Utility Tools

Apart from the above mentioned technologies, the project also utilizes several development tools to ensure high code quality and consistency throughout the project.

• Husky: A pre-commit hook that ensures code quality by running automated tests and linting before any code is committed. This helps catch potential errors and maintain code consistency.
• Commitizen: A tool used to standardize commit messages, ensuring they follow a consistent format. This makes it easier to generate automatic changelogs and follow semantic versioning.
• Commitlint: A tool used to enforce commit message conventions. This ensures that all commits follow a specific format, making it easier to track changes and maintain code quality.
• Standard-version: This is a utility for versioning using semver and for changelog generation. Standard-version automatically determines the next semantic version (patch, minor, major) based on the commit messages since the previous release. It also generates/update the CHANGELOG.md file based on these commits. The commit messages need to follow the Conventional Commits specification, which makes versioning and changelog generation predictable and easy to maintain. This aligns well with tools like Commitizen and Commitlint to ensure a smooth and standardized development process.
• Storybook: Storybook is a powerful development environment for UI components that helps build, test, and document UI components in isolation from the main codebase. Its use will enable faster development iterations and easier collaboration between developers, designers, and product managers.
• ESLint: A tool that analyzes code to identify and report patterns that are either incorrect or could lead to issues. We use ESLint with the Airbnb configuration as a base, which also includes the Next.js Core Web Vitals plugin, and Prettier for formatting code.
• Plop: A utility that allows for the quick and consistent creation of files and components based on predefined templates, or "stubs". Plop is used to speed up the development process by reducing the time and effort required to create new files and components, while also maintaining consistency in the project's structure and organization.

Editor

We recommend using Visual Studio Code as the primary editor for this project. However, feel free to use whatever editor you're most comfortable with. If you choose to use Visual Studio Code, we've provided a list of recommended extensions that will enhance your development experience. These extensions will be automatically suggested for VSCode users upon opening the project.

Recommended extensions

• dbaeumer.vscode-eslint: Integrates ESLint into VS Code for linting JavaScript and TypeScript code.
• esbenp.prettier-vscode: Code formatter using Prettier, a popular code formatting tool.
• mikestead.dotenv: Syntax highlighting for .env files.
• csstools.postcss: Syntax highlighting for PostCSS.
• bradlc.vscode-tailwindcss: IntelliSense and linting for Tailwind CSS.
• Orta.vscode-jest: Provides code navigation and test running support for Jest.
• dsznajder.es7-react-js-snippets: Adds useful code snippets for React development.
• steoates.autoimport: Automatically finds and imports the modules you need.
• wix.vscode-import-cost: Shows the size of each imported package in your code.
• jawandarajbir.react-vscode-extension-pack: A collection of extensions to enhance your React - development experience.
• bourhaouta.tailwindshades: Quickly generate Tailwind CSS color shades.
• Gruntfuggly.todo-tree: A todo list manager that can be used to display and manage todo comments in your code.
• eamodio.gitlens: Adds Git capabilities to VS Code.
• shd101wyy.markdown-preview-enhanced: Enhances the VS Code built-in Markdown preview with features such as math typesetting, flowchart, and sequence diagrams.
• unifiedjs.vscode-mdx: Adds syntax highlighting for MDX files.

Project Structure

Here's an overview of the projects' structure:

.
├── __mocks__                       # Mocks for testing
├── .github                         # GitHub/Gitlab folder - CI/CD Workflow yml files
├── .husky                          # Husky configuration
├── .vscode                         # VSCode configuration
├── artifacts                       # Miscellaneous artifacts
├── .next                           # Next JS build folder (auto-generated)
├── .swc                            # Next JS complier folder (auto-generated)
├── .storybook                      # Storybook configurations/files
├── coverage                        # Jest test coverage report for the project (auto-generated)
├── node_modules                    # The node_modules folder (3rd party packages) (auto-generated)
├── bin                             # Folder with our custom bash scripts
├── cli                             # Folder with our custom node/build scripts
├── storage                         # Folder with generated files (not committed to git)
├── storybook-static                # Storybook build folder (auto-generated)
├── cypress                         # Cypress e2e tests & configurations
├── stubs                           # HandleBars templating files, used by file generation commands
├── public                          # Public assets folder
├── scripts                         # Standalone scripts
├── src
│   ├── components                  # React Components (see structure for each component below)
        ├── [componentName]         # Folder with the components' name
            ├── Stories             # Folder containing the components' stories
              ├── [componentName].stories.ts # The components' storybook story file
            ├── __tests__           # Folder containing the components' unit tests
              ├── [componentName].tsx # The components' unit test
            ├── index.ts            # The barrel-export of the component
            ├── [componentName].tsx # The export default of the component
│   ├── features/sections           # Feats/Sections folder for specific not-reusable or a combination components - e.g Registration Form
|   ├── lib                         # If we ever use 3rd party libraries, it will be from this folder, so that our code does not depend directly on the libraries implementation but on our wrapper
│   ├── pages                       # Next JS Pages
│   ├── pages.test                  # Next JS Pages tests (this avoids tests to be treated as a Next.js pages)
│   ├── interfaces                  # Interfaces/Types
│   ├── configs                     # Configuration files
│   ├── styles                      # Styles folder
│   ├── stories                     # Storybook Page Stories
│   ├── middleware                  # Next JS Middleware
│   ├── utils                       # Utility functions
│   └── middleware.ts               # Next JS Middleware function
├── .gitignore                      # Specifies paths that are excluded from GIT
├── .eslintignore                   # Specifies paths that are excluded from ESlint checks
├── .eslintrc                       # ESLint  configuration
├── .env.example                    # Example of the environment variables that need to be filled
├── README.md                       # README file
├── CHANGELOG.md                    # Changelog from releases (Autogenerated)
├── commitlint.config.js            # CommitLint configuration
├── cypress.config.js               # Cypress configuration
├── lint-staged.config.js           # Lint Staged Configuration
├── next-sitemap.config.js          # Base config for next-sitemap generation
├── next-seo-config.ts              # Default config for next-seo
├── next-env.d.ts                   # Next Type Definitions
├── reset.d.ts                      # Reset Type Definitions
├── next.config.js                  # Next JS configuration
├── postcss.config.js               # Post CSS configuration
├── jest.config.js                  # Jest configuration
├── jest.setup.js                   # Common entry point for test, this is called after jest is initialized
├── package.json                    # Package JSON
├── package-lock.json               # Package JSON Lock File
├── plopfile.js                     # Plop configuration & action definition
├── tailwind.config.js              # Tailwind CSS configuration
└── tsconfig.json                   # TypeScript configuration

Useful Links

• Jira Sprint Board
• Jira Kanban Board
• Jira Project Roadmap
• C777BE Confluence
• C777BE Architecture
• C777BE 3rd Party Integrations
• Internal NPM Repository
• Storybook
• Postman API Documentation

Environments

The below table refers to the environments used by the application when is run in different places

Prerequisites

Apart from the technical prerequisites, you will need also to be connected to the company's VPN, otherwise you will not be able to run the app.

You'll also need to configure your .npmrc file. For this you will need to have access to the company's internal npm registry. If you don't have access, please contact your team lead.

Getting Started

Simply clone the project repository, navigate to the projects' root and run the following commands :

npm install

If this is the first time you're running the project, run the following command to initialize the git hooks.

npm run prepare

Last step is to create a .env.local file and populate all the variables specified in the .env.example.

To run the application in dev mode - run :

npm run dev

If you'd like to run a production version of the application - run :

npm run build & npm run start

The application should be accessible at http://localhost:3000

Commands

Environment Variables

Note : Environment variables that are prefixed with NEXT_PUBLIC_ are exposed to the client-side.

Workbox Caching Strategies

Using Google's Workbox, our application leverages various caching strategies to optimize performance and user experience. Here's a breakdown of the strategies employed:

1. Cache First (CacheFirst)

A strategy where the request is always served from the cache if available, and only fetched from the network if not. Useful for assets that don't change often.

• Assets: Google Fonts, Audio files (like mp3, wav, ogg), Specific video assets from /assets/videos/loyalty/, and other mp4 videos.

2. Stale While Revalidate (StaleWhileRevalidate)

This strategy serves the asset from the cache, if available, and then fetches a fresh copy from the network in the background to update the cache. It's suitable for resources that update frequently.

• Assets: Google Font Stylesheets, Font files (like eot, ttf, woff, etc.), Images (like jpg, png, svg), NextJS Image components, JavaScript files, CSS/LESS files, Next.js data JSONs.

3. Network First (NetworkFirst)

The asset is fetched from the network first. If the network request fails, then the asset is served from the cache. It's apt for assets that update often and need fresh data.

• Assets: JSON, XML, CSV files, Certain API routes, Other routes excluding specific API routes, and cross-origin requests.

Note:

• Some of these Network First routes have a fallback mechanism that uses cache if the network doesn't respond within a specified time (like 10 seconds for APIs).
• We're excluding caching for routes starting with /api/auth/ to ensure seamless OAuth workflows, especially in Safari.
• Certain routes check for the x-non-cacheable-response header and skip caching if found. This is automatically managed when using our in-house fetcher with the cacheable option set to false.
• For audio and video assets, rangeRequests is enabled to ensure they can be served efficiently from a cache.

For a deeper dive into how these caching strategies work and when to use each one, please refer to the official Workbox documentation.

Workflows / Pipelines

The main workflow script and logic are described within the .gitlab/workflows/*-ci.yml files. The main .gitlab-ci.yml extends the different stages and add environment specific values and scripts.

The .gitlab folder also contains merge request templates and other stubs that we may add in the future.

Scripts

We are using custom bash scripts which are stored in the bin folder. They are vital and meant to be used in CI/CD jobs. An example of such script is the setup-env.sh, which will read the exported CI/CD variable and create the correct .env file that is needed by the project.

Before Script *

The before script is a special job that executes before every job. In our case we're making sure that important .gitignored files like the .env are created and present before the jobs proceeds. We are using cache for node modules to keep them accessible in the context of different jobs and artifacts to pass down important dependencies like generated files in storage from crons in subsequent jobs.

Stages

Current we are defining the following stages when a pipeline is triggered. Please note that in order for the pipeline to proceed the previous job and its dependencies must be met. E.g if we fail on first stage we will not proceed to the next one.

• bootstrap

• lint

• test

• build

• bundle-analysis

• deploy

• release

Pipeline Dependencies

Here is the order and dependencies of the jobs in the pipeline

• Install Dependencies Production
  • Verify Environment Vars Production
    • Run Data Crons Production
      • Check Types Production
      • Check/Apply Format Production
      • ESLint Checks Production
        • Unit Tests Production
          • End-2-End Tests Production
            • Build Application Production
              • Deploy in AWS Production
              • Deploy in WALDC Production

Triggers

Current triggers are on push for each of the environments. Pushing to each main, pre-production or development branch will trigger a full pipeline and deploy. Exception is the default main branch as mentioned above, which requires a manual click to start the last deployment phase.

Additionally, we have a trigger for new git tags, which trigger the release workflow and create a new release on gitlab.

Finally, we have a trigger on pull/merge request to the main branch, which will run all the checks using development .env variables but will omit the deployment phase. In the future we'd like to use gitlabs' review apps feature, to deploy on dynamic environment that will use our dev back end. E.g- Feature A branch opens a PR to main, after pipeline succeeds, the changes will be live on a feature-a-branch.casino777.be

Changelogs

We're using standard-version and conventional commit messages, to help us automatically generate changelogs on each git tag. The changelog only includes added features and bug fixes, but we can expand the types of commits that we include by modifying the .versionrc file. The changelog will also point out any breaking changes mentioned when commiting via our npm run commit command. The generated changelog will also include the JIRA # with a link to the issue, the commit message with link to the changes and the commit description.

Releases

Gitlab releases are based on our latest git tags. They are an easy way to keep track of state of code that is running on production at any given point.

Integrations

We have the following integrations enabled.

• Google Chat
  • Everytime there is a failed deploy, new merge request or updated merge request to main, we will receive a notification from our chat bot on the CI/CD Alerts space on google chat. (The whole team has access to this channel, including QA. If you do not please ask to be added).
• JIRA
  • We can see linked pull requests, commits and branches directly in JIRA and any mention of a JIRA ticket in a commit message, pull request or changelog is automacially linked with the correct JIRA link. Pull requests will also automacially insert Mentions JIRA# with the link.
• Email integration (Beta)
  • On every new git tag & release, we can specify a list of recipients that will receive the changelog information of the latest release.

Rules and Caveats

• To ensure consistent commit messages, please use npm run commit to commit files. This will prompt you to follow a structured commit message format using Commitizen.
• Please use npm run create:component to create a new React component using Plop.
• When formatting code using npm run format, note that the formatting may not always be perfect. Please double-check the formatted code and manually adjust if necessary.
• If you encounter an error while running any of the npm scripts, please try deleting the node_modules directory and running npm install again.
• When running the tests using npm run test, note that the test coverage may not always be 100%. Please double-check the test coverage report and add additional tests if necessary.
• When using the lint script, please note that some linting errors may not be fixable automatically. Please double-check and manually fix any linting errors that cannot be fixed automatically.
• Functions, classes, commands, etc. that are prefixed with an underscore (_) are considered private and should not be used outside of the file in which they are defined.