darcher-figo/figo-rts

A React/Typescript template and guide.

figo-rts's Issues

improve pipeline scans, pre-commit hooks, and github actions

Establish what scans we want to run and where.

standardize project linting

I'll generate some "best practice" base configurations but we'll want to review those and augment them with anything we want to standardize across projects.

Want:

• sonarlint
• prettier
• eslint
• stylelint

Maybe:

• editorconfig
• style-guide.xml

track oddities in application

We want to create some general oddity tracking mechanisms to log and generate reports from in order to proactively catch issues before they become apparent.

These anomalies will usually need to be tracked by variance to common data,

e.g.

• This response body data object had 42 properties whereas usually we only see between 10-15,
• This page loaded in N seconds, it usually loads in under N milliseconds.
• This Quote instance has been attempted but not completed X number of times, whereas usually users only do it this much.
• This user is using a browser we aren't expecting, etc. etc.

improve accessibility and disabled user access

ALL svg tags should receive focusable="true" and role="img" to prevent screen readers from going into the vector frame, but there's a lot of areas that require some accessibility improvements, we need to investigate and isolate these areas, and create backlog tickets to go after them before they cause any legality issues.

aria-describedby, aria-controlledby, aria-live="polite", aria-label, etc. etc.

For example, one approach:

For form validation, as fields become "valid" or "populated" the progression button should be disabled and have an aria-describedby with a comma delimited list of field id's for fields that remain prior to the button being enabled.

or

For modals, aria-hidden="true" should be applied to the wrapper of all page content behind the modal, while the modal, outside of the container with this attribute, should have proper dialog/modal roles and aria-live indicators on close buttons, proceed buttons, etc.

abstract expensive tasks to a multi-threaded approach (Web Workers)

Javascript is single-threaded and although it has the ability to use Promises or async/await, offloading logic into Web Workers introduces a multi-threaded approach to processing data heavy areas so they can happen in parallel.

Web Workers work similar to a pub/sub mediator in that you send messages to and from the worker while the functionality housed inside the worker operates independently and only looks for specific messages in order to execute the logic is houses, it then passes the result back once the process is completed.

create user feedback questionnaire template(s)

improve automation of remedial or mundane tasks

track user interaction and flows

Introduce additional tracking metrics that bring value to the analytics matrix/dataset

create process for "discovery" during design phase

Get a mocking system in place with Figma to record user interaction with UI interfaces prior to development cycle. Internal users can review mocks during design phase in order to make necessary adjustment prior to items landing in dev backlog.

create a list of git alias commands for community

Global defaults

use alias[key] = "!f() { 〈 command 〉 }; f" to include complex commands

# .git/config

[alias]
	log = log --oneline --graph
	lgc = log -l HEAD --stats
	caa = commit -a --amend -C HEAD
	usr = config --global -l
	cmd = config --get-regexp alias
	dst = reflog expire --dry-run --expire-unreachable=30.days refs/stash
	sba = '!f() { git subtree add --prefix $2 $1 main --squash; }; f'
	bcn = '!f() { git branch --merged ${1-main} | grep -v "${1-main}$" | xargs -r git branch -d; }; f'
	fsh = '!f() { git fetch origin && git rebase origin/$(git branch --show-current); }; f'
	fpc = '!f() { git push -u -F origin $(git branch --show-current); }; f'
	fnd = '!f() { git !git rev-list --all | xargs git grep -F $1; }; f'
	dbm = '!f() { git fetch -p && for branch in `git branch -vv --no-color | grep ": gone]" | awk "{print $1}"`; do git branch -D $branch; done; }; f'
	ubm = '!f() { git for-each-ref --format "%(refname:short)" refs/heads | grep -v main | xargs git branch -D; }; f'
	bin = '!f() { git reset bin/** && git clean bin/** -fxd; }; f'
	new = !sh -c 'git log $1@{1}..$1@{0} "$@"'
	sbf = !sh -c 'git diff "$@" | grep "^[+-]" | sort --key=1.2 | uniq -u -s1'

branch.autosetuprebase always rebase new branches

git config --global branch.autosetuprebase always

pull.rebase always rebase pulls

git config --global pull.rebase true

push.default always push current branch

git config --global push.default current

---

Global shortcuts

usr get global user configs list

git config --global -l

cmd get global alias list

git config --get-regexp alias

refresh pull remote changes into local branch

git fetch origin && git rebase origin/$(git branch --show-current);

reindex reindex branch commit history

git reset $(git merge-base origin/master $(git rev-parse --abbrev-ref HEAD))

shove force push current local branch changes to remote origin

git push -u -F origin $(git branch --show-current)

history get local branch commit history

git log --oneline --graph

stats get local branch last commit in history

git log -l HEAD --stats

find get commits in history that have matches term or phrase in message

git !git rev-list --all | xargs git grep -F 'some phrase or term'

debranch remove all branches that have been merged into master.

git fetch -p && for branch in `git branch -vv --no-color | grep ": gone]" | awk "{print $1}"`; do git branch -D $branch; done

unbranch remove all branches that are not master.

git for-each-ref --format '%(refname:short)' refs/heads | grep -v "master\|main" | xargs git branch -D

destash expire stash older than 30 days

git reflog expire --dry-run --expire-unreachable=30.days refs/stash

dropbin unstage & discard entire /bin directory

git reset bin/** && git clean bin/** -fxd

amend takes all uncommitted and un-staged changes, currently in the working directory, and add them to the previous commit.

git commit -a --amend -C HEAD

create team/project point of contact outline

improve bundle size and performance

Dynamic imports to include functionality as-needed. Necessary dependancies to page load should get:

import { Header } from 'Components'

However, dependancies that are not required at initial load should be offloaded to dynamic imports to promote "as needed" packages:

const [state, setState] = React.useState<{
  nodes: {
    Modal: React.ReactNode | null,
  },
}>({ nodes: { Modal: null } });

(async (() => {

  const { Modal }: {
    Modal: React.ReactNode
  } = await import('Components');

  setState((etc) => ({
    ...etc,
    nodes: { Modal }
  }));

}))

track user performance metrics

Generate a report from any or all of our tools that show areas that stand out, page load speeds, endpoint response times, image rendering, etc. etc.

create tagging strategy in repositories

Lets create a list of tags each repository needs, like:

• Review - Ready for Code Review
• Rebase - Needs Rebase
• Concept - Proof of concept
• Feature - Feature work
• Utility - Helper method
• etc...

create flow and integration testing (cypress)

create typings of data models

To avoid impeding the progress of work, we want to start creating typings based on the data model/structures that are existing so when we start to transition from javascript to typescript we have these already established.

create process for A/B testing

Serving new features to subsets of users to get initial metrics and user feedback.

create code style guide

We should have a hierarchic outline of coding styles and best practices that is easily referenced.

create wiki template(s)

create process for user feedback

What is in place to get user feedback in order to get exposure to paint points or features users want? what in the UI do we want to add in order to get feedback from users interacting with our systems?

create localized storage (IndexedDB)

indexedDB, cookies, localStorage, and sessionStorage can all be used to similar effects. We don't utilize user localized data enough which puts the performance strain on the API endpoints instead of the users local machine.

create repository template(s)

I'm working on a template or starting repo where all projects can start with the same setup/configuration.

create mocked fixtures of data models

create mocked data items for use in testing and development.

create README.md template(s)

Name of the project ·

Additional information or tag line
A brief description of your project, what it is used for.

Installing / Getting started

A quick introduction of the minimal setup you need to get a hello world up &
running.

commands here

Here you should say what actually happens when you execute the code above.

Developing

Built With

List main libraries, frameworks used including versions (React, Angular etc...)

Prerequisites

What is needed to set up the dev environment. For instance, global dependencies or any other tools. include download links.

Setting up Dev

Here's a brief intro about what a developer must do in order to start developing
the project further:

git clone https://github.com/darcher-/app-boilerplate.git
cd app-boilderplate/
yarn

And state what happens step-by-step. If there is any virtual environment, local server or database feeder needed, explain here.

Building

If your project needs some additional steps for the developer to build the
project after some code changes, state them here. for example:

./configure
make
make install

Here again you should state what actually happens when the code above gets
executed.

Deploying / Publishing

give instructions on how to build and release a new version
In case there's some step you have to take that publishes this project to a
server, this is the right time to state it.

packagemanager deploy your-project -s server.com -u username -p password

And again you'd need to tell what the previous code actually does.

Versioning

We can maybe use SemVer for versioning. For the versions available, see the link to tags on this repository.

Configuration

Here you should write what are all of the configurations a user can enter when using the project.

Tests

Describe and show how to run the tests with code examples.
Explain what these tests test and why.

Give an example

Style guide

Explain your code style and show how to check it.

Api Reference

If the api is external, link to api documentation. If not describe your api including authentication methods as well as explaining all the endpoints with their required parameters.

Database

Explaining what database (and version) has been used. Provide download links.
Documents your database design and schemas, relations etc...

Licensing

State what the license is and how to find the text version of the license.

create local setup guide

We should have a short setup guide to show new developers how to setup their local environments to accommodate all projects.

improve state management (implementation & xState)

React.useState manages data states across the application and update in random orders and can cause dependency issues or state conflicts, not to mention cause a performance impact if the application is managing too many state instances.

A better approach, is using a single state const for each functional component and passing all data to it in the below approach:

const [state, setState] = React.useState<Record<string, any>>({});

setState((etc) => ({
  ...etc,
  prop: {
    key: 'value'
  }
}));

---

xState is a tool for creating, inspecting, and visualizing your applications state. Creating a sharable flow of various states that make up logic.

xstate.js.org

standardize project configurations

I'll generate some "best practice" base configurations but we'll want to review those and augment them with anything we want to standardize across projects.

Want:

• sonarlint
• prettier
• eslint
• stylelint

Maybe:

• editorconfig
• style-guide.xml

improve tooling (GitHub, Azure, Atlassian, etc)

We should introduce a quarterly audit of tooling to ensure our toolset stays current with industry trends.

standardize "dead code" or "feature flags" for all new PR's

If we feature flag we can toggle on/off as needed.

Dead code on "in-flight" work or necessary pre-work that is required ahead of features moving fowrard.

improve unit testability (Jest)

Pretty self explanatory... The easiest approach to implementing this is to create abstractions and test those individually to remove complexity from components.

standardize project formatting

I'll generate some "best practice" base configurations but we'll want to review those and augment them with anything we want to standardize across projects.

Want:

• sonarlint
• prettier
• eslint
• stylelint

Maybe:

• editorconfig
• style-guide.xml

create package dependency artifactory

We want to use Checkmarx or Fortify and set it up to automate security checks on dependencies, those that pass we want to include in a company wide artifactory that ensures developers can only use "safe" packages in projects.

create team/project interaction outline

We need a scalable list of projects, their points of contact, and how they interact with each other so new developers (or anyone) can reference it while trying to find who to contact for what.

create internal helpers & utility library (functional programming & ramda/lodash)

Where ES5 iteration methods and in general most logic is inside components, we want to abstract it out, wrap it in a namespace that is descriptive and understandable, and has tests written around it to increase stability, reusability, and scalability.

These new, succinct code snippets, will then be able to get updates as technology evolves and will be isolated/limited to small blocks of functionality.

No sense in reinventing the wheel, I prefer Ramda as it is a functional programming approach to a utility library, but lodash and a few others are acceptable as well.

improve xhr requests (TanStack Query)

Fetches, caches, and updates data in React app without touching global state.

https://react-query-v3.tanstack.com/

create new hire guide

We should establish a hierarchic outline of information that new developers/employees have access to reference.

Retry logic for policy purchases that fail

If a purchase should fail, we notify the user to contact customer support.

Since they're already "purchasing" legally we can just store user details and "retry" after services are restored, then email to "complete" or "confirm"

abstract reusable logic

We want to look through the front-end ecosystem at large and see what pieces we can abstract out and create reusable utilities from.