Skip to content

My personal starter project for SPA development. It uses react, redux, saga, and typescript -among other things.

Notifications You must be signed in to change notification settings

tysmithnet/react-starter

Repository files navigation

react-starter v2

This is my personal starter for SPA development. It's a bare bones starter meant to be hacked. Perhaps in the future I will provide branches/forks/whatever for more full-featured applications based on this starter.

Goals

Ideally, this will end up being a generator or some kind -either through something like yeoman or something akin to angular-cli or create-react-app. In the mean time, it is going to be clone/checkout based.

Here are some of the requirements I have for an MVP. I add more as I think of them.

  • First class support for testing
    • unit tests
    • e2e tests
    • coverage
    • snapshot testing?
    • storybook for components & layouts
  • Easy development
    • seemless debugging
    • fast recompilation
    • autogenerated documentation
    • beautification
    • dependency graph generation
    • linting
    • bundle analysis
    • .d.ts generation
    • Redux devtools browser extension
  • Features
    • router
    • history
    • authentication
    • authorization
    • logging
    • animations
      • CSS
      • Greensock (imperative)
      • react-pose (declarative)
    • webworkers?
    • metrics
    • lazy-loading modules
    • charts

Technologies

  • TypeScript
  • react
  • react-redux
  • redux-saga
  • webpack
  • eslint
  • prettier
  • material-ui
  • cosmos?
  • gsap?
  • react-pose?

Style Explanation

  1. I prefer to split my application code along domain boundaries. This is opposed to another popular style where you have directories for "types" of application pieces e.g. /components, /services, /containers. I prefer this because I believe it fosters good programming practice.
  2. Unit Tests should live next to the files they test. When tests are in a complete separate directory structure, it's very easy to forget to move the test when refactoring the location of some domain code. Integration tests or e2e tests should live in a central location.
  3. Files should follow a predictable naming convention. I prefer dot separated files of the form: domain.sub-clarifier.clarifier.ext e.g. auth.domain.ts, home.animation.banner.ts
Examples
File Purpose
user.saga.ts Saga logic for the user domain
route.domain.ts Domain types for the route domain
auth.action.ts Redux actions for the auth domain
auth.login.action.ts Hypothetical action file for auth domain where we felt it warranted its own file

Starter Project Requirements

The basic idea is to create a starter project that represents a CICD tracking system that will have several modules:

  • Users (admin)
    • CRUD users
  • User profile
    • Update information
    • View contributions
    • Notifications
  • Reports (admin)
    • Build pass/fail stats
    • Projects/contributions
  • Builds
    • Trigger/cancel builds
    • View build history

We want this to be pseudo operational, so we will provide a docker-compose.yml file that will spin up a populated database for testing with.

Developer Notes

I wrote this on Linux, and so some of the project caters towards such a system. For example, linting uses the utility find which is not from the windows world as well as *nix file paths. Additionally, I assume you have docker and docker-compose available for bringing up the database. If you are on Windows, then I recommend you use a linux VM. You can try using WSL, but YMMV.

About

My personal starter project for SPA development. It uses react, redux, saga, and typescript -among other things.

Resources

Stars

Watchers

Forks

Packages