CRA TS Starter Kit

Stack: React, Redux, Firebase TypeScript, Storybook, EsLint, Prettier, Jest, Enzyme

How to use:

Installation

# via npm
$ npm install

# via yarn
$ yarn

Launch App Locally

# via npm
$ npm start

# via yarn
$ yarn start

Deployed App Version

Visit wtf.com.

About this Documentation

Three level documentation:

• In-code Level Documentation. Series of comments all along the codebase. The goal of In-code Documentation is to register:

  • What a function do
  • What the function's parameters or arguments are
  • What a function returns

  NOTE: It's useless to document absolutely everything around the code. But we all know when you are making those kind of easy-to-forget/hard-to-understand decisions. So, these are the ones that MUST to be documented.

• Components Level Documentation. Component documentation handled with Storybook Documentation. Component-Driven Development is the way to build UIs from the bottom up starting with components and ending at screens. The good thing is with Storybook we can auto-generate a maintainable solid documentation. Here's what we are covering:

  • Design System decisions
  • Component's usage
  • Each component's description, primary story sample (with copyable source), props table, and collection of stories.

    Visit wtf.com for life Design System Docs.

• Project's Level Documentation. Includes this same README file, which contains:

  • A brief description of the project
  • Installation instructions
  • Record all major decisions made
  • Conventions applied if that's the case: naming, file organization, coding practices, etc.

File Structure

Compoents Tree

Global State

Code Base: Major Decisions

Styles

Raw CSS. The current configuration already allows us to use CSS pre-processors. BUT, we are not going to make use of any magic tool for CSS. "WHAT? WHY?", - you may ask.:

• Firstly, because I believe in plain CSS. It's strong enough.
• Second, still didn't find a legitimate excuse to adopt such complexity. CSS Variables? The language already have them. Expressions? I doubt that we will ever need them.

Eric Meyer's reset.css. Eric Meyer's // TODO - EXPLAIN WHY AND WHERE IS IT

Design System Decisions under index.css. Design System Decisions // TODO - EXPLAIN WHY AND WHERE IS IT

Modular CSS. Modular CSS makes just sense, specially with all the benefits of React Components.

BEM Naming Convention. For this project I decided to apply BEM naming convention *2 // TODO - EXPLAIN WHY

BEM + Modular CSS + React Components = SUCCESS.

Functionality

Naming and Absolute imports.

Layout

Import:

Tests

Unit Tests: Jest & Enzyme

Coverage: Coveralls

NOTE: Do you want to run your brand new Coveralls script? Follow the steps

• Add a .coveralls.yml file at the root level of the repository.

• Paste the following code snippet:

repo_token: YOUR_COVERALLS_REPO_TOKEN

• Replace YOUR_COVERALLS_REPO_TOKEN with your corresponding one.

• Check the script works by runing: $ yarn run coverage

Functional Tests: Cypress & Cucumber

Feature: A short description of the desired functionality
  Scenario: A business situation
    Given a precondition
    And another precondition
    When an event happens
    And another event happens too
    Then a testable outcome is achieved
    And something else is also completed

Visual Tests: Storybook & Loki

Continuous Integration & Continuous Delivery

Back-End Solution

Firebase

Config

TSConfig

Absolute imports from /src. According to what we've seen on the File Structure section, src is kind of our play field, where logic happens. Such reason makes me think /src is a nice root folder:

  "compilerOptions": {
    "baseUrl": "src",
  }

IDE: Visual Studio Code

I personally like VS Code IDE for its multiple solutions. If you are interested on what rules were applied on this particular project, please check VS Config.