DEV Community: Mark Erikson

Coding Career Advice: Using Git for Version Control Effectively

Mark Erikson — Wed, 27 Jan 2021 15:00:00 +0000

Introduction

Git has become the standard tool for software development version control. Other VCS tools exist, and some work better than Git for certain scenarios, but most of today's development world relies on using Git. So, becoming comfortable with Git and knowing how to use it effectively is a key skill for any software developer.

I'd like to pass along some of the most useful Git concepts and tips that I've learned over the last few years. In addition, I've covered background info on how Git works and common operations , and there's some specific usage patterns I've found to be especially valuable when working with a team and trying to understand a codebase.

As usual, none of the info or advice in this post is completely new or original, and there's many other sites that cover the same topics (and probably explain them better). I'm just trying to provide an overview of the relevant material and provide enough details that you can do further research and learning from there.

This post is largely based on my slideset Git Under the Hood: Internals, Techniques, and Rewriting History, and I talked about rewriting repo history in my post Rewriting Your Git History and JS Source for Fun and Profit

Introduction
- Table of Contents
Git Fundamentals
- Git Terms and Concepts Overview
  - Git Basics
  - Sharing Data Between Repositories
  - Branches
- Understanding Git Internals
Git Tools
Git Techniques
- Improving CLI Logging
- Preparing Commits in Pieces
- Stashing Changes
- Working with Branches
  - Creating and Switching Branches
  - Fetching, Pushing, and Pulling Branches
  - Merging Branches
  - Feature Branch Strategies
  - Pull Requests
  - Updating Branches in the Background
- Rewriting Git History
  - Amending Commits
  - Resetting Branches
  - Rebasing Branches
  - Reverting Commits
  - Cherry-Picking
  - Interactive Rebasing
  - Reflog
  - Advanced History Rewriting
Git Patterns and Best Practices
- Write Good Commit Messages
- Make Small, Focused Commits
- Clean Up Commit History Before Pushing
- Only Rewrite Unpushed History
- Keep Feature Branches Short-Lived
Code Archeology with Git
- Displaying Historical File Changes
- Bisecting Bugs
Final Thoughts
Further Information

Git Fundamentals

Git is notoriously difficult to work with, especially using the command line. The CLI commands and options are confusing, mismatched, and hard to remember. There's phrases and warnings like "detached HEAD". Git, frankly, is not easy to learn and kinda scary.

The good news is that once you understand how Git works, it becomes an extremely powerful tool that offers a lot of flexibility.

Git Terms and Concepts Overview

While I'm not going to turn this into a complete "Git tutorial from scratch", it's worth reviewing some of the key concepts.

Git Basics

Git is a tool for tracking changes to file content over time. A Git repository is a folder that has a .git folder inside. The .git folder contains all the metadata and stored history of the project's changes.

The working copy is all other folders and files in the repository folder that Git is storing and tracking. Any newly created files start out untracked. Git knows that the files are there, but you haven't told Git to save them.

To tell Git to start tracking a file, you add the file (git add some-file). Git then saves a copy of the file in an internal section called the staging area. Staged files are not being saved permanently, yet. Instead, they represent the set of files and contents that will be saved when you actually tell Git to save them.

Once you've added one or more files to the staging area, you can save them by committing them. "Commit" is both a verb and a noun here: we "commit" files to save them, and every time we save them, we make a "commit".

Git commits contain a certain set of files and their contents, at a specific point in time. They also contain metadata, including the author's name and email address, and a commit message that you write to describe the changes that were saved.

After a file has been added at least once, making further changes to that file will cause Git to mark it as modified. That means that Git knows the contents are different, but you haven't told Git to save the new changes yet. Once you add that file to the staging area again, Git sees that its latest copy of the file is the same as what's on disk, so it describes the file as unchanged.

Sharing Data Between Repositories

Each Git repository folder is standalone. However, Git repositories can be shared across folders, computers, and networks, allowing developers to collaborate on the same codebase. A Git repo can be configured with the URL of another repo, allowing the two repos to send commits back and forth. Each URL entry is called a remote. Downloading commit data from a remote repo is a fetch or a pull (with slight differences in behavior), and uploading commit data from local to remote is a push. Downloading a complete repo from scratch is making a clone of that repo.

Repositories normally have a default remote repo they point to, called the origin. Whenever you clone a repo, the new local repo points to the remote source as the origin, but that entry can be changed later. Repos can be configured to talk to many other repos at once, and can push and pull data from any remote.

Branches

Git commits are tracked using branches. A branch is like a pointer to the latest commit in a specific series of commits. Any time you make a new commit, Git bumps that branch pointer to point to the newest commit. You can make many branches within a repo, and most devs create a new branch for each task they work on. You can also make tags, which also point to a specific commit, but don't get moved or changed automatically. Tags are normally used to identify checkpoints and releases, so you can easily jump back and see how the code was at that point in time.

Changes from multiple branches can be brought together using a merge process. If some of the changes apply to the same lines of code, there is a merge conflict, and it's up to you as the developer to look at the mismatched changes and resolve the conflict by picking out what the right contents are.

Historically, most repos use a branch called master as the primary development branch. More recently, the community has started switching to use a primary branch named main instead. But, you can configure Git to use any branch name as the "default development branch" if you want.

Git uses the term checking out to refer to updating the working copy files on disk, based on previously committed values. Typically you check out a branch, which overwrites the files on disk to match the files as they exist in the latest commit of the branch. However, you can check out other versions of files as well

Uncommitted changes can be copied and saved for later by creating a stash. A stash is kind of like an unnamed commit - it again points to specific files at a certain point in time, but it doesn't exist in a branch. Stashed changes can later be applied on top of your working copy.

Overall, the Git data workflow looks like this:

Understanding Git Internals

I really feel that understanding Git's internal data structures is critical to understanding how Git works and how to use it correctly.

Git tracks all content using SHA1 hashes of byte data. Running any specific sequence of bytes through the hashing function calculates a specific hex string as a result:

from hashlib import sha1

sha1("abcd").hexdigest()
'81fe8bfe87576c3ecb22426f8e57847382917acf'

sha1("abce").hexdigest()
'0a431a7631cabf6b11b984a943127b5e0aa9d687'

readme = open("README.md", "rt").read()
sha1(readme).hexdigest()
'45257c0245c56a4d5990827b044f897c674c8512'

Git hashes files and data structures, then stores them inside the .git folder based on the hash:

/my-project
  /.git
    /objects
      /00
      /01
      ...
      /81
        81fe8bfe87576c3ecb22426f8e57847382917acf
      /82
      ...
      /fe
      /ff

Git has three primary internal data structures:

blobs are file contents, and identified by a hash of the file's bytes
file trees associate folder and file names with file blobs, and are identified by a hash of the file tree data structure
commits contain metadata (author, timestamp, message), point to a specific file tree, and are identified by a hash of the commit data structure

Type	Contains	Identified By
Blob	File contents	Hash of the file's bytes
File tree	Associates names and folder definitions with file blobs	Hash of the file tree data structure
Commit	Metadata for author, commit timestamps, and message	Hash of the commit data structure

A file tree may point to multiple other file trees for subfolders:

Commit objects themselves form a linked list, which points backwards to earlier commits based on their hashes: A <- B <- C <- D.

A Git "ref" is a name label that points to a specific commit. Branches are names associated with a given ref, where each time a new commit is made, the ref is updated to point to that latest commit. So, you can start from the branch ref pointer, then walk backwards through the chain of commits to see the history.

HEAD is a ref that points to "whatever the current active commit" is. Normally this is the same as the current branch pointer, but if you check out a specific earlier commit, you get the ever-popular warning about a "detached HEAD". This just means that HEAD is pointing to a specific commit instead of a branch, and if you make any new commits, they won't be part of any branch.

Because commits are a linked list based on hashes, and the hashes are based on byte contents of files and other structures, changing any one bit in an earlier commit would have a ripple effect - every hash of each commit after that would be different.

Git commit objects are immutable - once created, they cannot actually be changed. This means that you can't change history, exactly - you can only create an alternate history.

Git Tools

I've seen a lot of arguments about whether it's better to use a Git GUI tool, or use Git from the command line. To those people, I say: why not both? :)

I find that having a Git GUI tool is absolutely invaluable. It makes visualizing the state of the repository and its branches much easier, and many operations are way simpler via a GUI. For example, I can view the diffs for many pieces of a file at once, and selectively add specific changes to the staging area by clicking "Add Hunk" or CTRL-clicking a few lines to select them and clicking "Add Lines". This is much simpler and more intuitive than trying to use Git's "patch editing" text UI to manipulate pieces of changes. Interactive rebasing is also much easier to do via a GUI. I can't remember what the different options like "pick" mean, but it's straightforward to use a GUI listview with arrow buttons that lets you reorder commits and squash them together.

On the other hand, it's often faster to create or switch branches from the CLI. You can add all changed files to the staging area with a single command of git add -u. And of course, if you are using a remote system via SSH, you probably do only have the Git CLI available.

So, I use both a Git GUI, and the CLI, based on what tasks I'm doing.

I primarily use Atlassian SourceTree (Win, Mac). It's very powerful, with a lot of options, and has a good built-in UI for interactive rebasing. It also happens to be free. The biggest downside is that it doesn't have a way to view the contents of the repo file tree as of a given commit.

Other Git tools I've used in some form include:

Git Extensions for Windows (Win): integrates with Windows Explorer to let you perform Git operations from the filesystem. I mostly use this to do a quick view of a given file's history if I happen to be browsing the folder contents of the repo.
Git Fork (Win, Mac): excellent UI design, and does have an interactive rebase UI. Recently switched from being free to $50, but likely worth paying for.
Sublime Merge (Win, Mac, Linux): from the makers of Sublime Text. Fewer options and tool integrations, but very snappy. Tells you what CLI operations it's doing when you try to push or pull, so it expects familiarity with the CLI. $100, but will run for a while with nag messages.

There's also Tower (Win, Mac) and Git Kraken (Win, Mac, Linux), which have slick UIs but require yearly subscriptions, and a laundry list of other smaller Git GUIs. There's even "text-based UI" tools like lazygit, gitui, and bit.

All major IDEs have Git integration. JetBrains IDEs like IntelliJ and WebStorm have excellent Git capabilities. VS Code has adequate Git integration, but really needs additional extensions like Git History and GitLens to be useful.

I also really prefer using external diff tools for comparing complete files, or fixing merge conflicts. I personally use Beyond Compare as my external diff tool, and DiffMerge as my conflict resolution diffing tool.

Git Techniques

Improving CLI Logging

The default git log output is ugly and hard to read. Whenever I start using Git on a new machine, the very first thing I do is browse to https://coderwall.com/p/euwpig/a-better-git-log and copy-paste the instructions for creating a git lg alias to set up a much pretter CLI logging view that shows the branch and commit message history:

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

That gives us this view whenever we run git lg:

Note that git log accepts a variety of filtering options, including text strings, dates, branches, etc.

Preparing Commits in Pieces

I've seen comments that complain that the Git staging area is confusing. To me, the staging area is one of the most valuable features of Git - it lets me carefully craft commits that contain only the code that belongs together.

When I work on a task, I frequently end up modifying multiple files before I'm ready to make a commit. However, the changes might logically belong in several smaller commits instead of one big commit. If I do git add some-file, it adds all the current changes in the file to the staging area. Instead, I often want to stage just a couple sections from file A, and a couple sections from file B, and maybe all of file C, because those are the changes that should go together in one commit.

You can do this from the commandline using the git add -p flag, which brings up a text UI that lets you view each "hunk" of changes in a file, and decide whether to stage that hunk or not. However, I strongly recommend using a Git GUI tool like SourceTree for adding pieces of files , because it's easier to click "Add Hunk" or CTRL-click a couple lines and click "Add Lines" than it is try to decipher what the command abbreviations in the text UI actually mean:

Once you've got these pieces added, you can make a commit with just chose changes, and repeat the process for the next commit. This is a key part of the "making small commits" practice that I cover below.

On the flip side, sometimes you do just want to add everything that's been changed at once. In that case, the fast way is to run git add -u from the command line, which adds all modified files to the staging area.

Stashing Changes

Stashes are most useful when you've got some modified files that aren't committed, and need to set those aside to work on a different branch for a while. Git's list of stashes acts like a stack data structure, but you can also supply names for stash entries when you create them. Creating stash entries normally resets the modified files back to the latest commit, but you can choose to leave the modifications in place.

From the CLI, the main options are:

git stash: save a copy of local changes for later reuse, and clears the working directory/index
- git stash push: creates a new stash entry
- git stash pop applies changes from the top stash entry and removes it
- git stash apply stash@{2}: applies changes from the third stash entry
- git stash -p: choose specific pieces to stash
- git checkout stash@{2} -- someFile: retrieve a specific file contents from the stash

But, this is another situation where it's particularly useful to use a GUI instead. It's easier to just click a "Stash" button in a toolbar and type in a name for the entry to create one, or to expand a "Stashes" section of a treeview, right-click an entry, and "Apply Stash" to apply a stash.

Working with Branches

Creating and Switching Branches

Git has a bunch of different commands for working with branches. The most common way to create a branch is actually with git checkout -b NAME_OF_NEW_BRANCH. That creates a new branch, starting from the latest commit on the current branch, and switches to it.

You can also use git checkout NAME_OF_EXISTING_BRANCH (without the -b flag) to switch to an existing branch.

There's many other branching commands - see the Git docs and other pages like this Git branching cheatsheet for lists of commands and options.

Fetching, Pushing, and Pulling Branches

Most Git network operation commands accept the name of the remote repo to talk to, but assume that you want to talk to the origin remote repo by default if you don't specify a remote name.

git fetch tells Git to contact another repo, and download copies of all commits that the local repo doesn't have stored. This includes information on branches in the remote repo as well.

Once your repo has downloaded the list of remote branches, you can create a local branch based on the remote branch's name, with git checkout NAME_OF_REMOTE_BRANCH. Git will create a new branch that points to the same commit. It also sets up the local branch to track the remote branch, which means that any pushes from the local branch will update the remote branch.

Later, you can update the remote branch with the new commits you made locally, with git push. You can also push local branches taht the remote repo doesn't know about yet.

If the remote branch has commits you don't have in your local branch, git pull will both fetch the set of new commits into your local repo, and update your local branch to contain those commits.

If you rewrite history on your local branch so that it's different than the remote branch, a git push attempt will fail with an error. You can force push , which will hard-update the remote branch to use these commits instead. Force pushing is semi-dangerous, depending on workflow. If someone else pulled the old history, and you force-push, now they have a conflict to deal with. Force pushing is a valuable tool if you need it, and can be a legitimate solution to fixing problems or repeatedly updating a PR, but should be used cautiously. Think of it as a chainsaw - if you need it, you need it, you just have to be very careful when using it :)

Merging Branches

Merging allows you to take changes and history that exist on branch B, and combine them into the changes on your current branch A. The assumption is that both branches have a common set of ancestor commits, and two different sets of changes (either to different files, or even the same files). Merging creates a new "merge commit" on the current branch that has all of the changes together in one spot. This is used to let developers collaborate by writing code separately, but combine their changes together.

Merging is done with git merge OTHER_BRANCH_NAME, which tells Git to merge from the other branch into the current branch.

If the changes on the two branches interfere with each other, there's a merge conflict. Git will mark the file with text strings indicating the two mismatched sections. It's up to you to fix the problem, save the corrected file, add it, and finish the merge commit. I like using SourceGear DiffMerge as a GUI tool for fixing conflicts, but VS Code also does a nice job of highlighting conflict markers in files and offering hover buttons to pick one side or the other.

Feature Branch Strategies

Most teams use some kind of a "feature branch" strategy for development. They have a primary development branch such as main, master, or develop. Any time a developer starts work on a new task, they create a new branch based on the primary branch, and often using the name and ID of a task/issue as the branch name: git checkout -b feature/myapp-123-build-todos-list.

The developer works on their feature for a while. Once the work is complete, they push the branch up to the team's central repository, other team members review the changes, the developer makes any needed fixes from the review, and then the feature branch is merged back into the primary development branch.

Developers may need to pull down changes that have been added to the primary branch, then "merge down" from the primary branch into their feature branch. Merging the feature branch back into the primary branch is referred to as "merging up".

Pull Requests

If you've worked with Git at all, you've probably heard the term "pull request" (also know as a "PR" for short, or occasionally "merge request") before. Strictly speaking, a "pull request" isn't even a Git concept - it's a merging workflow that is built on top of Git by repository hosting sites and tools like Github, Gitlab, and Bitbucket.

Pull Requests are an approach to doing code reviews and handling merging at the central Git repo/server level. This is typically associated with using feature branches. A developer pushes up their completed feature branch, and creates a PR that will merge some-feature into main. Other devs can look at the page for the PR, see the file diffs, and leave comments on specific lines suggesting changes. The feature dev makes more commits based on those suggestions, pushes them up, and the PR is updated to reflect the changes. After other team members approve, the PR can be merged and the feature branch can be deleted.

Updating Branches in the Background

Normally, the main way to update a local copy of a branch is to git checkout some-branch and then git pull. But, if I'm working on a feature branch, I often have unsaved changes and don't want to switch over to the main branch just to do a pull.

There's a really useful trick for doing a "background pull" of a branch without checking it out:

git fetch <remote> <remoteBranch>:<localBranch>

So, say I'm on features/some-feature, and I want to update my main branch without switching to it. Typically the local branch and remote branch have the same name. So, I can run:

git fetch origin main:main

and Git will download any new commits on the remote origin/main branch, then update my local main branch to have those commits too.

Rewriting Git History

There's a variety of ways to alter the history in a Git repository. Each technique is useful in different situations, and these are often valuable for fixing earlier problems. As mentioned earlier, Git commits are immutable, so you can never actually modify them - you can only replace commits with new ones. So, when we "rewrite history", we're actually creating an "alternate history" instead.

It's critical that you should only ever rewrite history that is still local to your own repository and has never been pushed up to another repository! As long as commits haven't been pushed, no one else cares about them, and you can rewrite them to your heart's content. But, once they've been pushed, someone else's Git repo clone may be relying on the old history, and changing that history will likely cause conflicts for them.

Amending Commits

The easiest technique for rewriting history is to "amend" the latest commit.

Amending a commit really means replacing it with a slightly different one. This can be done via git commit --amend, or a corresponding option in a GUI tool:

Technically, the old commit still exists in Git's storage, but the current branch ref now points to the newly created commit instead.

Resetting Branches

Since branch refs are pointers to a given commit, we can reset a branch by updating the ref to point to an earlier commit. This is typically used to roll back some of the commits you made.

When you reset a branch, you have three options for what happens to the files on disk and in the staging area:

git reset: move a branch pointer to point to a different commit
- --soft: keep the current files on disk and in the staging area
- --mixed: keep the current files on disk, but clear the staging area
- --hard: clear the staging area and make the working directory look exactly like this specific commit

So, git reset --soft is fairly "safe" to do, because it doesn't change any files on disk. git reset --hard is "dangerous", because it will wipe out any files that were changed during these commits or that haven't been committed yet, and replace them all with the files from this exact commit.

git reset requires a commit identifier as an argument. This could be a specific commit hash ( git reset ABCD1234 ), or some other revision identifier. You can even update your current branch to point to the same commit as a different branch ( git reset --hard some-other-branch ).

Rebasing Branches

"Rebasing" is a technique that is an alternative to merging for updating one branch with another's changes. Instead of combining the two sets of changes directly, rebasing rewrites history to act as if the current branch was created now, off the latest commits on the source branch, instead of starting from the earlier commits. Similar to merging, this is done with git rebase OTHER_BRANCH_NAME.

Imagine that the main branch has commits A <- B to start with, and we make a feature branch starting from commit B. Now, someone else merges some more work into main, giving it commits A <- B <- C <- D. If we rebase our feature branch against main, it's kind of like cutting off the line of our feature branch, transplanting it to the end, and pretending we really started this branch after commit D instead of B:

Reverting Commits

Resetting a branch effectively throws away the newer commits. What if we want to undo the changes in an earlier commit, but keep the history since then?

Reverting a commit with git revert creates a new commit that has the opposite changes of the commit you specified. It doesn't remove the original commit, so the history isn't actually modified - it just inverts the changes.

Cherry-Picking

Cherry-picking allows you to copy the changes in specific commits, and apply those as new commits onto a different branch. For example, maybe there's an urgent patch that has to be created directly onto a hotfix branch and deployed to production, but you need to also make sure that main has that commit as well. You can cherry-pick the individual commit from the hotfix branch over onto main.

git cherry-pick accepts either a single commit reference, or a commit range. Note that the range excludes the first commit you list. if I run git cherry-pick A..E, then it will copy commits B,C,D,E over onto this branch. This creates new commits with new hashes (because the timestamps and parent commits are different), but preserves the diffs and commit metadata.

Interactive Rebasing

"Rebasing" involves rewriting the entire history of a branch. There is a variation on this called "interactive rebasing", which allows you to selectively modify earlier commits on a branch. This is done with git rebase -i STARTING_COMMIT.

Interactive rebasing lets you perform several different types of modifications. You can:

Edit the message for a commit
Reorder commits
Squash multiple commits together
Remove commits

After you specify the desired changes to the commit history, Git will execute the modifications you listed, and update all commits after the starting point accordingly. As with other history rewriting operations, this always produces a new set of commits after any changed commit, with new hashes even if the rest of the contents haven't changed due to the parent commits changing.

Running an interactive rebase from the CLI brings up a list of all commits after the starting commit in your text editor, along with a column of odd command names like "pick" and "squash". You rework the commits by actually modifying the text in the file, and then saving and exiting. For example, if you want to swap a couple commits, you'd cut one of the text lines and paste it in a different location.

I find this very unintuitive to work with, so I strongly recommend using a Git GUI for any interactive rebase operations. SourceTree and Fork have pretty good UIs for performing interactive rebasing.

Reflog

It's actually very hard to completely wipe out your Git commits and permanently lose work. Even if you do a git reset --hard and the commits appear to have vanished, Git still has a copy of those commits saved internally.

If you do end up in a situation where you can't see those commits referenced from any tag or branch, you can use the Git reflog to look back and find them again. The reflog shows all commits, no matter what branch they're on or whether there's still a meaningful pointer to that commit. That way you can check them out again, create a new tag or branch pointing to those commits, or at least see the diffs.

Advanced History Rewriting

Finally, Git supports some very advanced tools for rewriting history at the whole repository level. In particular, git filter-branch lets you perform tasks like:

rewriting file names and paths in the history (example: changing files in ./src so that they now appear to be in the repo root)
creating a new repo that contains just certain folders from the original, but with all their history
rewriting actual file contents in many historical commits

git filter-branch is notoriously slow, so there's other external tools that can perform similar tasks. While I haven't used it, https://github.com/newren/git-filter-repo claims to be able to run the same kinds of operations much more quickly, and is apparently now even recommended by the actual Git docs.

Sometimes repos end up with very large files cluttering the history, and you want to rewrite the history to pretend those files never existed. A tool called the BFG Repo Cleaner does a good job of that.

If these existing tools don't do what you need, you can always write your own. I once wrote a set of Python-based tools to rewrite the JS source for for an entire repository with multiple years of history, including optimizing it to run in just a few hours.

These tools are very powerful and should not be something you use for day-to-day tasks. Think of them as fire extinguishers. You hope you never need to use them, but it's good to have it sitting around in case something happens.

Git Patterns and Best Practices

So now that we've covered a bunch of commands and technical details, how do you actually use Git well? Here's the things that I've found to be most helpful:

Write Good Commit Messages

It's critical to write good commit messages. It's not just a chore to satisfy the Git tools. You're leaving notes to any future developers on this project as to what changes were made, or even more importantly, why those changes were made. Anyone can look at a set of diffs from a commit and see the changed lines, but without a good commit message, you may have no idea what the reason was to make those changes in the first place.

There's lots of good articles out there discussing rules for writing commit messages, with plenty of good advice. I personally don't care so much about things like "max 72 characters per line" or "use present tense for the top line and past tense for other lines", although there's valid reasons to do those things. To me, the critical rules are:

Always start the commit message with a relevant issue tracker ID number if there is one. That way you can always go back to the issue tracker later to see more details on what the specific task was supposed to be.
First line should be a short high-level summary of the intent of the changes. This line of the message is what will be shown in any Git history log display, so it needs to both fit in one line, and clearly describe the commit overall. Aim more for the purpose of the changes than a specific list of "what changed" in this line.
If you have any further details, add a blank line, then write additional paragraphs or bullet points. Write as much as you want here! This section will usually be collapsed by default in a Git UI, but can be expanded to show more details. I've seen some excellent commit messages that were multiple paragraphs long, and they provided important context for why changes were being made.

A typical example of this format would look like:

MYAPP-123: Rewrite todos slice logic for clarity

- Added Redux Toolkit
- Replaced handwritten reducer with `createSlice`. This simplified the logic considerably, 
  because we can now use Immer and it auto-generates the action creators for us.
- Updated `TodosList` to use the selectors generated by the slice.

Make Small, Focused Commits

This goes hand-in-hand with the advice to write good commit messages.

Commits should be relatively small and self-contained, conceptually. One commit might touch several files, but the changes in those files should be closely related to each other. There's multiple reasons for this:

It makes it easier to describe the changes in the commit
It's easier to look at that one commit and see what changes it includes
If the commit needs to be reverted later, there's fewer other changes that would be affected
When someone looks at the line-by-line history, there will be more specific comments associated with each line ("Fixed bug X" instead of "Made a bunch of changes", etc)
It's easier to bisect the commit history and narrow down what changes might have caused a particular bug

For example, say I'm adding a new JS library to a project. I would make one commit that just updates package.json and yarn.lock, then put the initial code changes using that library into a separate commit. You can see an example of this commit approach in the commits for the "Redux Fundamentals" tutorial example app I wrote.

To me, the commit history should "tell a story" of how a given task was accomplished. Someone should be able to read through the series of commits, whether it be during the PR review process or years down the road, and be able to understand my thought process for what changes I made and why I made them.

Clean Up Commit History Before Pushing

I frequently have to make "WIP" commits as I'm working on a task. Maybe I've just made a bunch of edits, the code is now mostly working, and I want to record a checkpoint before I keep going. Or, maybe I forgot to commit a particular bit of code, added it in another commit later, but it doesn't really belong as part of the "story" that I'm telling.

I often use interactive rebase to clean up my commits before I push a branch for a PR. Just because I have some junk commits in my history locally doesn't mean that the rest of the world needs to know or care that was part of my actual progress for this task. The "story" that I'm telling with my commits is sort of the idealized version - ie, "let's pretend that I did this task perfectly without any mistakes along the way".

Only Rewrite Unpushed History

As mentioned earlier: as long as a branch is still local and hasn't been pushed, it's fair game - rewrite it all you want! Once it's been pushed, though, you should avoid rewriting it.

The one main exception to that is if the branch is still up for PR, and you redo the history. At that point, most likely no one depends on it yet, so you can get away with force-pushing the branch to update the PR. (The React team does this frequently.)

Keep Feature Branches Short-Lived

There's no hard rule about how many lines of code or commits can be in a branch. In general, though, try to keep feature branches relatively short-lived. That way the size of the changes to merge in a PR is smaller, and it's less likely that you'll need to pull down changes from someone else.

Some people argue about whether it's better to merge feature branches back into the primary branch, or rebase them when they're done to keep the main branch history "clean and linear". I kinda like having merge commits, personally - I prefer seeing when things got merged in. The important thing is to pick a convention as a team and stick with it.

Code Archeology with Git

So why do all these good commit practices matter?

Say you're working in a codebase with multiple years of history. One day, you're assigned a task to work on some portion of the codebase. Maybe it's fixing a bug that just popped up, or adding a new feature. You open up a file, and there's hundreds of lines of code inside. You read through it, and it's kind of ugly - there's a bunch of extra conditions in the logic, and you're really not sure how it ended up this way.

Reading through that file tells you what the code does, now. Unless the file has a lot of good comments, there may not be much information for why the code is like that, or how it got that way. We naturally have a tendency to assume that "whatever code is there currently must be correct", but that's not always true :)

That's where having a good Git history is critical. Digging through a file's history can show you:

Who wrote each line of code
When that code was changed, and what other code changed at the same time
What task the changes were part of
What the intent was behind the change
What the author was thinking at the time
When a bug was introduced

These can all be extremely valuable pieces of information when tracking down a bug or working on a feature.

Displaying Historical File Changes

There's a variety of ways to view the history of changes to a file.

git log lets you look at the commits that affected a specific file. IDEs and Git GUIs let you explore the history of a file as well, showing each commit its diffs, often including the ability to diff two arbitrary versions of a file. Some Git GUIs also let you explore the entire repo file tree as of a specific commit.

Git has a feature called git blame, which prints the commit ID, author, and timestamp for each line. The CLI output is hard to read, but every good IDE has the ability to show file blame information next to the actual code in a file. IDEs typically enhance the blame information to show you more details on the author, the commit message, and the commits before and after this one:

Github offers a "blame" view as well, and makes it easy to jump back to view an earlier version of the repo. Github also lets you browse specific file versions and trees. For example, https://github.com/reduxjs/react-redux/tree/v7.1.2 shows the React-Redux codebase as of tag v7.1.2, and https://github.com/reduxjs/react-redux/blob/5f495b23bcf3f03e0bee85fa5f7b9c2afc193457/src/components/connectAdvanced.js shows that exact file version. (Press y while browsing a file on Github to change the URL to the exact file hash.)

Bisecting Bugs

Git has a really neat command called git bisect, which you can use to help find the exact commit where a bug was introduced. When you run git bisect, you can give it a commit range where you think the problem started. Git will then check out one commit, let you run whatever steps you need to with the app to determine if the bug is present or not, and then say git bisect good or git bisect bad. It then jumps to another commit and lets you repeat the process. It follows a splitting pattern that lets you narrow down the potential problem commit in just a few steps.

Final Thoughts

As software developers, we use lots of tools. Everyone has their own preferences for things like text editors and such, but everyone on a team is going to use the same version control system. In today's world, that's inevitably Git.

Given how critical Git is to modern development, anything you can do to use it more effectively will pay dividends down the road, and anyone reading your commits will appreciate the effort you put into clearly describing what changes are happening and why. It might be a teammate reading your PR, an intern exploring the codebase next year, or even yourself revisiting code that you wrote many years ago.

Ultimately, good Git practices are a key part of long-term codebase maintainability.

Further Information

Git Tutorials
- Atlassian Git tutorials
- Git for Humans slides
Git Internals
Commit Messages
- How to Write a Git Commit Message
- Git Commit Message Good Practices
Operations
- Git Beyond the Basics
- Advanced Git Commands You Will Actually Use
Cheat Sheets
- A Visual Git Guide
- Tower Git Cheat Sheet
- akras14 Git Cheat Sheet
- DevHints Git cheat sheets: revision syntax, log syntax, branching commands
Other Resources
- Git Flight Rules: a guide for when things go wrong
- React/Redux Links: Git Resources

Coding Career Advice: Searching and Evaluating Online Information Efficiently

Mark Erikson — Tue, 24 Nov 2020 03:00:00 +0000

Introduction

A while back I saw this excellent quote on Twitter:

When I learn something today, I usually do it by piecing together clues gleaned from out of date tutorials and random forum posts until a coherent picture forms, and that is a skill you should practice relentlessly because it's the most valuable skill you will ever acquire.

I attribute much of my success as a developer to my ability to search for information online quickly and efficiently, absorb key pieces of info from the relevant search results, and then synthesize that information into a potential solution.

To be honest, this is a really hard topic for me to write about, because it's something I've been doing my whole online life. It's kind of like trying to describe "How to learn and speak English" as a native speaker. It's not something I can exactly describe based on learning it, because it's a skill I naturally developed back during the dawn of the Web. It's also not something I think about, because by now it's entirely instinctive. Similarly, I can't go tell anyone "start using the internet back in 1995", or "spend most of your childhood learning to speed-read" - clearly that doesn't scale or actually help anyone else :)

That said, I firmly believe that developing a strong ability to search for and evaluate information online is a key skill that every developer should aim for. I actually already described a form of this in my earlier post on evaluating software libraries and tools.

Here's my suggestions for a general set of steps to follow.

Suggested Search and Evaluation Process

Know what it is you're trying to find. Obviously you don't know the exact details yet, otherwise you wouldn't be looking :) But, think of it as drawing an outline, and then trying to find a picture that matches that outline. The better idea you have up front of what you're looking for, the easier it is to look at a result and say "this does or does not match what I'm looking for"

Know where to look for relevant information. Google is the typical starting point, but I'll use the search feature on other sites for specific things: NPM for JS libraries, Twitter for tweets, Github for code repos or usage snippets, and so on.

Use specific phrases and keywords as part of your search. You might not even know what the relevant keywords are to begin with, but after opening up a few initial results, you might find some info that's in the same general category as what you're looking for. Start up a new search using specific relevant phrases you just found, and keep narrowing the results down based on those. (I'll throw an extra-special shout out to Shawn Swyx Wang's post on "How to Google Your Error Messages", which both has some excellent advice for a common problem and tweet-quotes me in the process.)

Learn to skim search results quickly and do an initial filtering pass based on likely relevance. This includes looking at page titles or software library names, "last updated at" dates, URLs, and anything else in the actual search results list that can give you a sense of whether a given result is likely to be relevant and trustworthy. Learn to immediately disqualify search results as "too old", "likely spam or clickbait", or "just not relevant" as you move your eyes down the results list. Pop open potential candidates in a new tab for later review, and keep skimming results.

Once you've got an initial set of potentially useful results opened up, skim the pages and get a sense of what the actual content is and whether it's worth looking at further. Consider the source (blog, docs site, tutorial), date, author, length, apparent level of detail, and overall content. If it doesn't look relevant, close the tab and move on to the next one. The emphasis here is on trying to figure out which of these results should be kept for the the real deeper reading and understanding portion of the process.

Now that you have a good list of likely meaningful results, go back through them in more detail. You might want to take notes on your findings, bookmark some of the results and save them for later, or start up new searches based on some of the keywords you find.

Finally, you should have accumulated a good set of info from across all these results. Maybe none of those pieces of info directly solves your problem by itself, but it's possible to take some of the info as a basis for putting together your own solution. Think of it as lego blocks - maybe you didn't find a complete pre-assembled kit, but you've got enough blocks that you can build something yourself.

Note that these steps aren't limited to Google searches. They apply as you look at just about any other search site or tool, even if you're looking for something like a software library on NPM.

Additionally, one of the main reasons why I still use Firefox as my primary browser is the Tree Style Tabs addon. It lets you switch from a row of tabs on top of the browser, to a sidebar that has a tree of tabs that can be nested and collapsed at any level. This makes it much easier to have a large number of tabs open at once, including grouping results from different searches based on the starting page. (My understanding is that Chrome addons can't do the same kind of UI changes that Firefox addons can, and last I checked there wasn't a good equivalent of Tree Style Tabs for Chrome. Could easily have changed since the last time I looked, though.)

Examples

I'll briefly describe some specific cases where I went through this process myself.

Git History Rewriting

In my post Rewriting Git History and JS Source for Fun and Profit, I described how I completely migrated our team's Git repository history, by stripping out unused files and rewriting the JS source to modernize it at all points in the history of the codebase.

When I started this task, I had some prior experience with rewriting Git history. I frequently used commands like rebase in my daily work, and I had used git filter-branch a few times. I also generally understood how Git's data structures worked, and that tools like JS codemods existed. So, I understood the general shape of what I wanted to do ("create an alternate Git history but with changed content", "rewrite JS source automatically on a large scale") and key terms that I needed to look for ("git filter-branch", "rewrite Git history", "JS codemod"). I also assumed that what I wanted to do must be possible, somehow - I just didn't know the exact technical details of how.

I probably spent at least a week doing initial research on this. I didn't find an exact solution, but I did find several critical resources that gave me much deeper understanding, key terms to look for, and ideas that shaped my potential solution:

Understanding Git Filter-branch and the Git Storage Model: helped clarify my understanding of how filter-branch works and how Git stores its data
Large scale Git history rewrites: gave me the idea for doing some of this work in Python
A tale of three filter-branches: described a rewrite process, and linked to a Ruby script that did low-level Git repo manipulation to speed up the rewrite work
sergelevin/pylter-branch: a Python lib that builds on pygit2 to provide an abstraction for iterating over Git history and rewriting it

None of those pieces by itself was the entire solution, but together they gave me enough understanding to figure out how to build the actual solution I needed.

By the time I was done building this, I had learned enough to write a 6000-word blog post on the topic, off the top of my head, in about 5 hours :)

Searching for Info on How to Search

I started this evening by searching online and evaluating info on how to search online and evaluate info efficiently. (How meta!)

My first search was for how to search for information on the internet. In a sense I didn't follow my own advice here, because that's more of a question or a phrase than specific keywords, but I didn't quite know where to start looking for details on this topic. Most of these results were either blogspam about search engine optimization, or too narrowly focused on how to actually type things into a search engine rather than how to look at the results. I also avoided any results with dates older than the last couple years, on the grounds that they probably weren't as relevant.

That initial search turned into effectively evaluating search results, which produced some better hits. I also saw the phrase "digital literacy", realized that was a relevant aspect of this topic, and searched for digital literacy searching for information. These queries gave me some better results, including a number of academic-related pages like university libraries.

Ultimately, I didn't end up using those resources to write this post, but I have linked the best results in the "Further Information" section below.

React-Redux, React Native, and Jest

Last year I fixed a bug in React-Redux where it broke under React Native. As part of that, I needed to update our test suite to make it correctly test behavior with React Native, vs just ReactDOM.

I remember having seen a tweet that day about "all the stuff I googled in a week as a software developer", so for fun I wrote down every Google search I did while trying to solve this particular React Native test setup problem. This included searches like react uselayouteffect ssr to find a particular issue thread I knew existed in the React repo, jest mockComponent.js Support for the experimental syntax 'classProperties' isn't currently enabled to find a solution to a particular error message I was seeing, and microsoft ipod naming as a sidebar based on a discussion with a friend, to find the classic Microsoft self-parody video on how they're so bad at naming things.

Further Information

Announcing the new "Redux Fundamentals" core docs tutorial!

Mark Erikson — Mon, 02 Nov 2020 15:02:40 +0000

I'm very excited to announce that:

📖📖The new "Redux Fundamentals" core docs tutorial is LIVE!📖📖

This is a complete rewrite of the old "Basics/Advanced" tutorial, and teaches "how Redux works and how to use it" from the ground up:

https://redux.js.org/tutorials/fundamentals/part-1-overview

The goals for the rewrite were:

Improve explanations
Drop outdated references ("Flux", "container components")
Show simpler patterns (inline action types, single-file logic)
Explain how Redux works "bottom-up"
Teach modern practices
Show how Redux Toolkit simplifies Redux logic

The tutorial still builds a todo example app, but it's now a real app that gets bigger as the tutorial goes along and is used to demonstrate all concepts including async logic.

We've got numerous CodeSandboxes throughout the tutorial showing the changes at different steps.

This effort pairs with our "Redux Essentials" tutorial, which teaches "how to use Redux, the right way" for real-world usage.

Like with the "Essentials" tutorial, each page now starts with "What You'll Learn" and ends with "What You've Learned" summaries. There's callout boxes with links to more info, and expandable "Detailed Explanation" sections that give more background.

All of the old tutorial pages have been removed entirely, and we've added redirects pointing to matching content in the new "Fundamentals" pages instead.

That completes the effort to rewrite our tutorials, but there's still a lot more docs work left to do! We've got many more pages that need to be updated / reorganized, and we want to add new material as well.

If you'd like to contribute, see this issue:

https://github.com/reduxjs/redux/issues/3592

Coding Career Advice: Evaluating Software Libraries and Tools

Mark Erikson — Tue, 22 Sep 2020 04:30:00 +0000

Introduction

As a senior developer, I spend a lot of my time looking at tools and libraries to decide if they're something we can or should use as part of our projects. I've developed a strong ability to quickly filter through lists of possible tools to narrow them down, and then do further research on the remaining candidates.

This is definitely not the kind of skill that they teach you in school, which is sad given the way modern software development is strongly dependent on reusing libraries.

To help with that, here's some of the things I take into consideration when evaluating tools.

How to Correctly Evaluate Third-Party Software Libraries and Tools

Starting Point: Search Locations

For software libraries, you should typically start with the appropriate package manager site for the language you're using, such as NPM for JavaScript, PyPi for Python, or Maven Central for Java). If you're looking for non-library tools such as IDEs, Google is your best bet.

Searching for keywords on those sites should turn up a list of things that are potentially relevant.

Potential Evaluation Criteria

When choosing any tool, you have to evaluate it on multiple criteria. Here's an (incomplete) list of things you may want to consider when looking at any software library or tool that you're considering using:

Zeroth Pass: Relevance

The first step is to select a list of tools that actually look relevant to your topic. For example, searching NPM for react number input right now turns up 219 hits. There's probably only a much smaller number that actually match what you're looking for. Skim through the hits and pop open the most likely looking options based on the initial descriptions.

First Pass: Basic Suitability

Now that you've got the initial candidate list, it's time to determine which of these may be a good possibility:

Does this even solve the problems I have right now?
Does it solve those problems well?
What's the license of this tool? Is it compatible with my company's policies?

The goal of using any tool is to solve a problem you have. If a tool doesn't solve your problem, you shouldn't even consider using it in the first place. (Note that this implies that you should understand what problems you're trying to solve before you start investigating tools to help with them :) )

Along with that, there's the question of whether a tool is something you can use based on legal or policy concerns. For example, many companies disallow use of GPL-licensed software libraries to avoid any possible issues mixing their proprietary code with GPL-licensed code and being forced to distribute their own code publicly. Other companies might restrict libraries and applications based on the nationality of the authors, purchased licensing terms, or license costs.

One-line summary of the most common open-source (OSS) licenses:

MIT, BSD: use the code for whatever you want, just credit the original author
LGPL: Use it as long as you don't modify the original library
GPL: If you use it, your own software must be licensed under the GPL as well, and your source must be made available on request

If you know ahead of time that you can't use a particular tool, there's no point in digging into it further.

Second Pass: Detailed Evaluations

Once you've narrowed down the list down to the top 3-4 choices, you can do a more detailed evaluation of each of them.

Here's some of the criteria that I take into consideration. I don't necessarily have these in a formal checklist, but they're usually in the back of my head in some form. (This list is biased towards OSS software libraries, particularly for JavaScript, but most apply more broadly as well).

How easy is it to use?
What's the size of the community?
- How many projects appear to use this tool?
- How many downloads does this have weekly/monthly?
- How much info is there on using it outside the core docs?
What's the size of the ecosystem?
- How many related packages exist?
- If we have an additional use case not solved by the core tool, do addons exist that handle that use case?
- How easy is it to extend or modify this tool?
How easy is it to understand what the tool does internally and conceptually?
How much documentation does this have? Is there an actual meaningful docs site, or is it just a Github readme?
How well tested is this tool?
How much prior experience does my team have with this tool or something similar?
Is it well maintained?
- How many bugs does it have?
- Has this ever had any critical vulnerabilities / CVEs? If so, how many, how often, and how long did they take to get fixed?
- How often do new releases occur? When was the last release?
- How many open issues / PRs are there?
- How fast will things get fixed if there's a bug?
- How many maintainers are there? Are they active?
- What's the long-term roadmap for this project?
How many other dependencies does this tool have?
- How many of them are runtime dependencies vs development-only dependencies?
- Do we need to be concerned about any of them?
How much does this affect the architecture of our app?
- Can we rip it out if we choose to switch to something else?
- How hard is it to upgrade this tool when a new version comes out?
Where does this fall in the "hype cycle"?
- Brand new tool that is experimental? It works, but still only used by early adopters? Mainstream? Dying?
- Are people actively starting new projects with this tool, or are they moving away?
What technical requirements and system constraints does this have?
- What's the minimum runtime version?
- Are there size concerns, such as min+gzip size for a JS library used in the browser?

This isn't an all-inclusive list - there's likely other factors you might want to consider as well.

These all affect a decision on whether using a given tool is a good idea or not for your team. It's also likely that some of these may be more relevant than others depending on your situation.

Note that you could easily spend an infinite amount of time recursing through the transitive dependencies of a given tool, especially if this is a JavaScript package of some kind. For example, a brand new Create-React-App project only has a handful of dependencies: react, react-dom, @testing-library/react, and react-scripts. However, react-scripts itself depends on Jest, ESLint, Webpack, Babel, PostCSS, and a couple dozen other packages, and Webpack in turn ends up pulling in around 700 packages, for a final total of just over 1500 individual packages installed into your node_modules folder. Clearly, inspecting every one of those manually is not feasible, so you have to draw a line somewhere. Given the rise of "supply chain" attacks, where malicious packages are deliberately created to steal information or cause harm, it's critical to make these decisions wisely.

It can sometimes be worth doing a "trade study" to evaluate alternatives, especially if multiple people are involved in this decision. Define several categories, decide on the possible range of numeric scores for each category, and rate each tooling option in each category. You may want to add together the scores for each tool, or average them out. Also, you might want to weight some categories as being more important than others. I suggest defining the weights and scoring approach ahead of time, so that the final decision is more fair.

When searching for critical security vulnerabilities like CVEs, you can use sites like https://cve.mitre.org/cve/search_cve_list.html and https://nvd.nist.gov/vuln/search as references.

For open-source projects on Github, it's worth looking at the number of stars, open issues, and PRs. Those aren't final decision criteria, but they can give you a sense of the popularity and health of a project. Also keep an eye on the recent commits to get an idea how active it is.

NPM shows a weekly download stats graph on the package description page, but I prefer using npm-stat.com, which lets you compare the download stats for multiple packages over a specific period of time, with values shown for daily/weekly/monthly/yearly downloads totals.

For JS client bundle size questions specifically, I strongly recommend using Bundlephobia to determine the true cost of adding a given package to your app. Michel Weststrate's import-size util can also be helpful here.

Further Information

TLDR Legal: shortened plain English explanations of common software licenses
Bundlephobia
mweststrate/import-size
Trade Study guidelines
npm-stat.com
17 criteria for evaluating third-party libraries
The 12 Things You Need to Consider when Evaluating Any New JavaScript Library
Evaluating 3rd party libraries

Coding Career Advice: Keeping a Daily Work Journal

Mark Erikson — Tue, 22 Sep 2020 04:00:00 +0000

Introduction

As I've progressed through my career as a developer, I've learned a bunch of useful things based on my experiences. I've frequently shared some of these thoughts with other developers on my team and various folks I've chatted with online, so it's worth trying to write these down so I can share them more widely.

None of these thoughts are particularly new, and in fact I'll try to link to other resources that say similar things. But, writing them down means I've got somewhere to point people to in the future, and maybe they'll be new to someone who hasn't seen these thoughts before.

Note : For a much more extensive set of career advice on many topics, I strongly recommend Shawn Swyx Wang's book The Coding Career Handbook: Guides, Principles, Strategies, and Tactics from Code Newbie to Senior Dev. There's a ton of valuable info in there, and it's totally worth the purchase.

Tip #1: Keeping a Daily Work Journal

At the start of 2013, I started keeping a daily work journal. At the end of every workday, I take 10-15 minutes to write down a few paragraphs covering what I did that day , such as:

Tasks I worked on and what specific things I did for those
Conversations with other developers on my team and what topics we covered, or key takeways from discussions outside the team
Problems I ran into, and (hopefully) how I solved them
Where I left off at the end of the day
What tasks I need to prioritize the next day
Useful code snippets

I don't hit all of those points every day, but they're all common things I cover.

Why Keep a Work Journal?

Writing journal entries like this has a lot of potential benefits:

When I pick up work after a long weekend, it reminds me what I'm even supposed to be working on now
I sometimes run into a bug that I know I solved months or even years ago. There's been several times I dug back into my notes and found the solution I'd written down the last time.
It's often interesting to look back at how I approached problems years ago, and see how I've grown since then
But most of all, it's extremely valuable come performance review season. I can go back through every single workday of the past year, see exactly what tasks I worked on, and put together an extensive list of accomplishments for my self-evaluation writeup.

Journaling Tools

I strongly prefer to write notes in Markdown format, with actual syntax highlighting in the Markdown text and the rendered output.

I currently use the "legacy" Boostnote desktop app (v0.16), although I may end up switching to the "modern" Boostnote app in the near future once it looks mature enough. Boostnote does a pretty good job handling Markdown and syntax highlighting. It also has decent search capabilities.

I've also been writing a lot of Markdown documentation in VS Code lately, and there's some notebook plugins for VS Code that look like they might be viable options as well.

You should feel free to use whatever works best for you, electronic or analog, although I would suggest something electronic because it's probably easier to search for text keywords.

Journal Organization

I have a separate folder for each month, typically named like 2020-09 (September), and create a separate Markdown note for each day, named like 2020-09-21 (Monday). Legacy Boostnote sadly doesn't have nested folders, so all folders for all years are flattened out, but that makes it pretty easy to jump straight to a period of time that I'm interested in. (Looks like new Boostnote does support nested folders, so that may be a reason for me to switch.)

I also have a separate parent category for other notes organized by topics.

Example Journal Entry

Here's a very slightly anonymized version of a real journal entry I wrote recently:

2020-09-03 (Thursday)

Talked to $DEV_1 and split the remaining "UI polish" tasks up.

Fixed an issue with input cells not focusing in FF. Turns out FF doesn't trigger click events on disabled inputs. Had to apply input[disabled] { pointer-events: none; }, per Stack Overflow.

I tried to get sticky table columns to work, and bounced off that. Too tough for now, so we'll put that for later.

Had a good talk with $UX_DESIGNER. He's been busy the last few weeks with other projects, so we caught up on the state of our work. He's going to see if he can get a couple other UX folks to look at what we've got. He'll also think about the best way to display things like the couple dozen columns for $BUSINESS_FEATURE.

I tossed out the idea of showing $FEATURE instruction help as a separate new popup window. He agreed that was viable.

Found react-new-window, pulled that in. Was able to copy and paste field definitions from Excel and convert to HTML via Tableizer. Threw together help pages for the three $FEATURE tabs so far.

Reviewed $DEV_2's PR that had removal of dead $FEATURE code, backend models converted to TS, a unit test for deleting $ITEM, and a bunch of other cleanup. Looks pretty good overall.

I'll try to knock off the remaining UI polish tasks next.

Further Information

Debugging Tips and Tales

Mark Erikson — Sat, 19 Jan 2019 17:57:09 +0000

Originally posted on my blog at https://blog.isquaredsoftware.com

Last week's #devdiscuss discussion was on the topic of debugging. This is something I have a lot of opinions and advice on, so I replied with a quick list of my suggestions for better debugging. It's worth recording those in blog post form as well.

Note: Ben McCormick pointed me to a very similar post he wrote a few years back. It's excellent, and you should read it too: The Debugging Toolbox

Mark's Debugging Advice

1) Reproduce the Issue

Reproducing the problem is key. If you can't reproduce the issue, it's harder to figure out what's going on and iterate on fixes. More importantly, if you can't repro, you probably can't prove that a "fix" actually works.

2) Errors Provide Useful Information

Error messages and stack traces are important. @swyx quoted me in a Dev post last year on this topic: How to Google Your Errors . They usually give you a good starting point for where the problem is and why it's happening. Read the messages. Google them if needed.

3) Learn to Use Debuggers

Know your tools. Most debuggers work the same no matter what IDE / DevTools you're using. Understand breakpoints, watches, stepping. Use more advanced features like conditional breakpoints, or "watchpoints" to just log a message instead of stopping.

4) Print Logging is Important

Sometimes an IDE debugger won't cut it, especially if it's a remote system or multi-threaded environment. Good ol' console/print debugging is still important. It helps to have lots of existing logging with different levels that you can enable via config files.

5) Debug With a Plan

Go in with a hypothesis. Understand how the code should behave first. Look at the actual behavior. You can probably make educated guesses for where things are diverging. Focus on those areas. Don't randomly tweak. Change one thing at a time and compare results. Narrow down possible causes based on that.

6) Don't Be Afraid

Experience helps, but don't be afraid to dive in if you're new, because that's how you get experience :) Even if an issue looks like it's really complex, take some time to break it down into smaller pieces. Dave Ceddia and Gosha Arinich both wrote good advice on the topic of breaking down problems from the perspective of building a new project and learning new topics, but the same concept applies to debugging.

7) Know When To Keep Going, and When To Stop

Persistence is good, and it takes time to build up mental context on an issue, but sometimes you gotta take a break. Plenty of times I've left work, gone home, relaxed, and figured out what the issue was overnight or in the morning.

On that note, I'll recap a couple of my best debugging stories.

Tales of Debugging

The Case of the Wrong Case

A few years ago. I had a Python service that was doing a bunch of number crunching, so I used Cython to speed up the math-intensive portions of the code. Cython is a tool that can compile plain Python code to C so that it runs faster. If you add extra type declarations, it can generate more efficient C code, because it knows what each variable type is.

Cython has a few ways you can declare types. You can rename your .py files to .pyx and add types directly in the code; you can use decorators to declare the types; or you can add separate .pxd files that declare the types. I set it up using the side-by-side file approach, which lets you leave your original Python files alone. For this to work, the .pxd file with the types has to match the exact name of the original .py file. So, if I had FileA.py, I'd also have FileA.pxd.

I added type definitions for the Python functions and variables and referenced several C math functions from <math.h>. This service primarily runs on Linux, but I do most of my development on Windows. I did the initial changes on my local Windows machine, tested the code, and it seemed to be working great.

Unfortunately, when I went to run this on Linux, it compiled fine, but started throwing some weird exceptions buried deep down in the code. I hadn't actually written the math portion of this service myself, so I wasn't familiar with the actual logic. I traced the problem pretty far down into the code, and finally concluded that a particular function was trying to call the cos() trigonometry function, but the call was failing because cos didn't seem to exist. This didn't make any sense, because I was explicitly importing the C version of cos from <math.h> if using Cython, and importing the normal Python function from the math module otherwise.

Took me about 6 hours of tracing, investigating, and steadily growing confusion before I finally figured out what was going on: there was a single letter casing mismatch between a .py file and its corresponding .pxd file. One had a capital 'O', the other had a lower-case 'o'. This worked fine on Windows, because Windows file systems are case-insensitive (so filea.txt is considered the same as FileA.txt). But, Linux file systems are case-sensitive, so files can have the same name with different letter cases. Because of this, the Cython compiler never actually found the .pxdfile to match the original .py file, didn't get the right imports, and thus stuff eventually exploded. The fix was to change the capital 'O' to a lower-case 'o', and it worked.

Definitely a pretty high hours-of-work to number-of-characters-changed ratio :)

A Twisted Tale

Recently, we got reports that one of our Python services appeared to be locking up entirely. This particular service acts as a reverse proxy, forwarding HTTP requests to the rest of our system, and also handling authentication requests.

The main symptom was that none of our app would load in the browser. Oddly, there were no obvious errors in the logs, but that was because the logs for the service stopped entirely at about the time the symptoms occurred.

This Python service is built on the Twisted network framework. Twisted uses an "event loop", similar to how Javascript and Node.js work. It has a queue of events, and for each event, runs the associated code to completion. This is great if you have lots of IO that happens in the background. But, it also means that if a particular script takes a long time to run, it can block the entire event loop and keep any other code from running.

I was stumped by the issue for a while, but I had a couple guesses. My hypothesis was that one of the external calls this service was making was never getting a response, and thus blocking the event loop from continuing.

We cranked up the log levels for this service, restarted things, and waited for it to happen again. When it did, I took a look at the logs. Sure enough, the last thing the service was trying to do was make an external request to an LDAP server to query some user data.

I did some testing and confirmed that all of the external requests were happening on the main thread, same as the event loop (which I did by modifying the logging config to print out the name of the thread where the log statement occurred). I moved all those external requests to happen in background threads instead, and also fixed the timeout settings on the calls so that they don't block indefinitely.

The changes resolved the issue. We later found out that the issues did actually correspond to times when the LDAP server had been experiencing 100% CPU usage, thus confirming the external cause.

The moral of the story is that knowing how the underlying technologies behave allowed me to make an educated guess for the likely cause of the problem.

Final Thoughts

Debugging is a combination of gathering information, problem solving, and knowing how to use the tools you have available. Articles and courses can teach you a lot of things, but debugging is something that I feel really requires practice and experience.

So, the next time you see your application spewing errors into the logs, or something just "doesn't work", DON'T PANIC! You can figure this out :)

Redux - Not Dead Yet!

Mark Erikson — Thu, 29 Mar 2018 15:00:00 +0000

I'm a Redux maintainer. There's been a lot of confusion, claims, and misinformation about Redux going around lately, and I want to help clear things up.

Originally published on my blog at blog.isquaredsoftware.com as part of my “Blogged Answers” series .

TL;DR

Is Redux dead, dying, deprecated, or about to be replaced?

No.

Are there situations where you don't need Redux?

Sure, but that's always been true.

A Longer Explanation

There's been a whole slew of comments and articles lately that boil down to people asking "Is Redux dead?", or asserting that "Tool X replaces Redux". I'll recap several sources of confusion, and explain what's actually going on.

"Redux is Overused"

Where's this coming from?

Redux has been around for almost three years. In "JS library years", that's like... forever :) It got very popular very quickly, and as a result, a lot of people were told they had to use Redux, without actually understanding the tradeoffs involved and when it actually makes sense to use Redux. So, there's been some inevitable backlash, and people have looked for alternatives, including adopting other state management libraries or creating their own.

As part of that, there was a wave of tweets about a month ago about how Redux was being overused. One in particular was from Cory House, a well-known author/teacher in the React community. That tweet and various others got heavily retweeted, and the ensuing discussion ricocheted around Twitter for a while.

Clearing the Confusion

The Redux maintainers (first Dan Abramov and Andrew Clark, now Tim Dorr and myself) have always said that you might not need Redux. There are excellent reasons to use Redux, but it may not be the best fit for your situation. Like any tool, it's important to understand the tradeoffs and benefits before deciding to use something.

I've seen plenty of comments amongst the Twitterati that people have opted to move away from Redux to something else. But, at the same time, my own estimates are that somewhere between 50-60% of all React apps use Redux, plus all of its usage with other JS frameworks like Angular, Ember, and Vue, and that is a userbase that isn't just going to disappear overnight. (There's also a big gap between what gets chatted about at lightning speed on social media, and what people are actually doing in "the real world".)

It's also worth noting that Redux is not owned by Facebook - it's a separate open-source project. Both of its creators (Dan Abramov and Andrew Clark) now work at Facebook, but Tim Dorr and I have no affiliation with Facebook at all. We talk with the React team to help coordinate future plans, but Redux doesn't belong to them.

"The new Context API can replace Redux"

Where's this coming from?

React 16.3 is introducing a new stable version of the context API, which is intended to replace the old unstable API. Context is specifically intended for the use case of passing data to deeply nested React components. That's one of the reasons why some people have chosen to use Redux, and so there's been claims that the new context API will replace Redux.

Clearing the Confusion

Yes, the new context API is going to be great for passing down data to deeply nested components - that's exactly what it was designed for. If you're only using Redux to avoid passing down props, context could replace Redux - but then you probably didn't need Redux in the first place. Context also doesn't give you anything like the Redux DevTools, the ability to trace your state updates, middleware to add centralized application logic, and other powerful capabilities that Redux enables.

"GraphQL can replace Redux"

Where's this coming from?

Somewhat similarly, there's been a lot of noise around GraphQL and the Apollo Client. There have been articles specifically claiming that "GraphQL will let you replace Redux". Also, Apollo has a new apollo-link-state addon that can handle client-side state, and there's been discussion that that can also help replace Redux.

Clearing the Confusion

I'd agree that data fetching via GraphQL, and especially with Apollo, will likely reduce or eliminate your data-fetching related Redux code. And again, if that's all you were using Redux for, you probably wouldn't need Redux after moving all the data-fetching handling into Apollo. I'll even go so far as to say that apollo-link-state could probably handle most of your other client-side state logic, and I think Apollo ships with a DevTools setup of its own. The Apollo team has been doing some pretty neat work, and while I don't like seeing people switch away from Redux, ultimately we all want to build great apps that help our users. But, as with context, I'd say there's definitely use cases where Redux is going to work better than GraphQL + Apollo, and possibly without requiring as much buy-in throughout your architecture. This is especially true if you need to do more than just fetch data or update a couple local state values, like persisting user data through page reloads or implementing complex workflow logic.

"Redux is being replaced by something from React"

Where's this coming from?

Finally, Dan Abramov recently gave a great talk at JS Conf Iceland where he demoed two upcoming aspects of React's "async rendering": time-slicing will allow React to split up update calculations for smoother updates, and "React Suspense" will allow deeply nested components to delay their rendering until fetched data is available. Unfortunately, shortly after the talk, a site known for writing misleading and poorly-written articles about React put up a post claiming that "Dan Abramov announced a new 'future-fetcher' library that replaces Redux", and linked a tweet by Kent C Dodds with that statement as evidence.

Clearing the Confusion

One of the problems with social media is that it's easy for misinformation to spread quickly. And especially in this case, because that widely-spread article about Dan announcing a "future-fetcher" library was completely and utterly wrong! Dan's announcement was purely about async React capabilities, and had nothing to do with Redux. In addition, Kent's tweet about Redux being replaced was literally a joke tweet in a joke Twitter "live-commentary" thread about the talk. The article was either a complete misunderstanding of the React ecosystem, or a deliberate attempt to spread confusion and FUD.

The Future of Redux

As a Redux maintainer, I can assure you that Redux isn't going anywhere. The Redux core library is stable, and we've actually got a 4.0 beta release available. Despite the major version bump, it's really just about cleaning up some edge cases and improving the TypeScript typings. Besides that, the Redux ecosystem is thriving.

The real interesting near-future work is around the React-Redux library. We're going to be updating it to work better with React's async capabilities. We have an open issue for discussion of how Redux will work with async React, and I created a proof of concept PR that updates connect to use the new context API. There will be more work needed over the next few months, but we're committed to ensuring that React and Redux continue to be a great choice for building applications.

Ready to Learn Redux?

So with all that in mind, it's a great time to learn how to use Redux. As always, I'll close with some links to further resources:

The official Redux docs. I just updated the README to include a quick list of learning resources, and there's a more extensive list of Redux learning resources that cover many aspects of using Redux.
I've got a blog post with my suggested list of resources for learning Redux
My React/Redux links list has an extensive section full of Redux tutorials
My "Practical Redux" blog tutorial series demonstrates a variety of real-world Redux and React techniques through building a sample application, and I've also created an interactive "Practical Redux" course on Educative.io.

I'd also encourage people to really understand when and why they should use Redux. Some suggested articles:

The Redux FAQ entry on "When should I use Redux?"
Dan Abramov's post You Might Not Need Redux, which discusses the tradeoffs Redux asks you to make and some of the benefits you get in return
My two part post The Tao of Redux, Part 1 - Implementation and Intent and The Tao of Redux, Part 2 - Practice and Philosophy, which look into the history and intent behind how Redux was designed, how it's meant to be used, and why common usage patterns exist.

Learn Redux In Person from Me!

Besides all the articles and posts and links, I'm going to be teaching a series of "Redux Fundamentals" workshops through Workshop.me! I'm excited for this chance to spend a couple days helping people learn exactly how Redux works and how to use it.

My first "Redux Fundamentals" workshop is April 19-20, in New York City, with other workshop locations and dates TBD later this year. Tickets for the NYC workshop are still available! If you're not in NYC, or are already comfortable with Redux, spread the word to someone you know who might be interested! :)

Idiomatic Redux: Using Reselect Selectors for Encapsulation and Performance

Mark Erikson — Sat, 23 Dec 2017 01:00:00 +0000

An overview of why and how to use Reselect with React and Redux

Note: This post was originally published on my blog at blog.isquaredsoftware.com, and is part of my "Idiomatic Redux" blog series on good Redux usage practices.

Intro

In a good Redux architecture, you are encouraged to keep your store state minimal, and derive data from the state as needed. As part of that process, we recommend that you use "selector functions" in your application, and use the Reselect library to help create those selectors. Here's a deeper look at why this is a good idea, and how to correctly use Reselect.

Basics of Selectors

A "selector function" is simply any function that accepts the Redux store state (or part of the state) as an argument, and returns data that is based on that state. Selectors don't have to be written using a special library, and it doesn't matter whether you write them as arrow functions or the function keyword. For example, these are all selectors:

const selectEntities = state => state.entities;

function selectItemIds(state) {
    return state.items.map(item => item.id);
}

const selectSomeSpecificField = state => state.some.deeply.nested.field;

function selectItemsWhoseNamesStartWith(items, namePrefix) {
     const filteredItems = items.filter(item => item.name.startsWith(namePrefix));
     return filteredItems;
}

You can call your selector functions whatever you want, but it's common to prefix them with select or get, or end the name with Selector, like selectFoo, getFoo, or fooSelector (see this Twitter poll on naming selectors for discussion).

The first reason to use selector functions is for encapsulation and reusability. Let's say that one of your mapState functions looks like this:

const mapState = (state) => {
    const data = state.some.deeply.nested.field;

    return {data};
}

That's a totally legal statement. But, imagine that you've got several components that need to access that field. What happens if you need to make a change to where that piece of state lives? You would now have to go change every mapState function that references that value. So, in the same way that we recommend using action creators to encapsulate details of creating actions, we recommend using selectors to encapsulate the knowledge of where a given piece of state lives. Ideally, only your reducer functions and selectors should know the exact state structure, so if you change where some state lives, you would only need to update those two pieces of logic.

One common description of selectors is that they're like "queries into your state". You don't care about exactly how the query came up with the data you needed, just that you asked for the data and got back a result.

Reselect Usage and Memoization

The next reason to use selectors is to improve performance. Performance optimization generally involves doing work faster, or finding ways to do less work. For a React-Redux app, selectors can help us do less work in a couple different ways.

Let's imagine that we have a component that requires a very expensive filtering/sorting/transformation step for the data it needs. To start with, its mapState function looks like this:

const mapState = (state) => {
    const {someData} = state;

    const filteredData = expensiveFiltering(someData);
    const sortedData = expensiveSorting(filteredData);
    const transformedData = expensiveTransformation(sortedData);

    return {data : transformedData};
}

Right now, that expensive logic will re-run for every dispatched action that results in a state update, even if the store state that was changed was in a part of the state tree that this component doesn't care about.

What we really want is to only re-run these expensive steps if state.someData has actually changed. This is where the idea of "memoization" comes in.

Memoization is a form of caching. It involves tracking inputs to a function, and storing the inputs and the results for later reference. If a function is called with the same inputs as before, the function can skip doing the actual work, and return the same result it generated the last time it received those input values.

The Reselect library provides a way to create memoized selector functions. Reselect's createSelector function accepts one or more "input selector" functions, and an "output selector" function, and returns a new selector function for you to use.

createSelector can accept multiple input selectors, which can be provided as separate arguments or as an array. The results from all the input selectors are provided as separate arguments to the output selector:

const selectA = state => state.a;
const selectB = state => state.b;
const selectC = state => state.c;

const selectABC = createSelector(
    [selectA, selectB, selectC],
    (a, b, c) => {
        // do something with a, b, and c, and return a result
        return a + b + c;
    }
);

// Call the selector function and get a result
const abc = selectABC(state);

// could also be written as separate arguments, and works exactly the same
const selectABC2 = createSelector(
    selectA, selectB, selectC,
    (a, b, c) => {
        // do something with a, b, and c, and return a result
        return a + b + c;
    }
);

When you call the selector, Reselect will run your input selectors with all of the arguments you gave, and looks at the returned values. If any of the results are === different than before, it will re-run the output selector, and pass in those results as the arguments. If all of the results are the same as the last time, it will skip re-running the output selector, and just return the cached final result from before.

In typical Reselect usage, you write your top-level "input selectors" as plain functions, and use createSelector to create memoized selectors that look up nested values:

const state = {
    a : {
        first : 5
    },
    b : 10
};

const selectA = state => state.a;
const selectB = state => state.b;

const selectA1 = createSelector(
    [selectA],
    a => a.first
);

const selectResult = createSelector(
    [selectA1, selectB],
    (a1, b) => {
        console.log("Output selector running");
        return a1 + b;
    }
);

const result = selectResult(state);
// Log: "Output selector running"
console.log(result);
// 15

const secondResult = selectResult(state);
// No log output
console.log(secondResult);
// 15

Note that the second time we called selectResult, the "output selector" didn't execute. Because the results of selectA1 and selectB were the same as the first call, selectResult was able to return the memoized result from the first call.

It's important to note that by default, Reselect only memoizes the most recent set of parameters. That means that if you call a selector repeatedly with different inputs, it will still return a result, but it will have to keep re-running the output selector to produce the result:

const a = someSelector(state, 1); // first call, not memoized
const b = someSelector(state, 1); // same inputs, memoized
const c = someSelector(state, 2); // different inputs, not memoized
const d = someSelector(state, 1); // different inputs from last time, not memoized

Also, you can pass multiple arguments into a selector. Reselect will call all of the input selectors with those exact inputs:

const selectItems = state => state.items;  
const selectItemId = (state, itemId) => itemId;  

const selectItemById = createSelector(  
    [selectItems, selectItemId],  
    (items, itemId) => items[itemId]  
);  

const item = selectItemById(state, 42);

/*
Internally, Reselect does something like this:

const firstArg = selectItems(state, 42);  
const secondArg = selectItemId(state, 42);  

const result = outputSelector(firstArg, secondArg);  
return result;  
*/

Because of this, it's important that all of the "input selectors" you provide should accept the same types of parameters. Otherwise, the selectors will break.

const selectItems = state => state.items;  

// expects a number as the second argument
const selectItemId = (state, itemId) => itemId;  

// expects an object as the second argument
const selectOtherField (state, someObject) => someObject.someField;  

const selectItemById = createSelector(  
    [selectItems, selectItemId, selectOtherField],  
    (items, itemId, someField) => items[itemId]  
);

In this example, selectItemId expects that its second argument will be some simple value, while selectOtherField expects that the second argument is an object. If you call selectItemById(state, 42), selectOtherField will break because it's trying to access 42.someField.

You can (and probably should) use selector functions anywhere in your application that you access the state tree. That includes mapState functions, thunks, sagas, observables, middleware, and even reducers.

Selector functions are frequently co-located with reducers, since they both know about the state shape. However, it's up to you where you put your selector functions and how you organize them.

Optimizing Performance With Reselect

Let's go back to the "expensive mapState" example from earlier. We really want to only execute that expensive logic when state.someData has changed. Putting the logic inside a memoized selector will do that.

const selectSomeData = state => state.someData;

const selectFilteredSortedTransformedData = createSelector(
    selectSomeData,
    (someData) => {
         const filteredData = expensiveFiltering(someData);
         const sortedData = expensiveSorting(filteredData);
         const transformedData = expensiveTransformation(sortedData);

         return transformedData;
    }
)

const mapState = (state) => {
    const transformedData = selectFilteredSortedTransformedData (state);

    return {data : transformedData};
}

This is a big performance improvement, for two reasons.

First, now the expensive transformation only occurs if state.someData is different. That means if we dispatch an action that updates state.somethingElse, we won't do any real work in this mapState function.

Second, the React-Redux connect function determines if your real component should re-render based on the contents of the objects you return from mapState, using "shallow equality" comparisons. If any of the fields returned are === different than the last time, then connect will re-render your component. That means that you should avoid creating new references in a mapState function unless needed. Array functions like concat(), map(), and filter() always return new array references, and so does the object spread operator. By using memoized selectors, we can return the same references if the data hasn't changed, and thus skip re-rendering the real component.

Advanced Optimizations with React-Redux

There's a specific performance issue that can occur when you use memoized selectors with a component that can be rendered multiple times.

Let's say that we have this component definition:

const mapState = (state, ownProps) => {
    const item = selectItemForThisComponent(state, ownProps.itemId);

    return {item};
}

const SomeComponent = (props) => <div>Name: {props.item.name}</div>;

export default connect(mapState)(SomeComponent);

// later
<SomeComponent itemId={1} />
<SomeComponent itemId={2} />

In this example, SomeComponent is passing ownProps.itemId as a parameter to the selector. When we render multiple instances of <SomeComponent>, each of those instances are sharing the same instance of the selectItemForThisComponent function. That means that when an action is dispatched, each separate instance of <SomeComponent> will separately call the function, like:

// first instance
selectItemForThisComponent(state, 1);
// second instance
selectItemForThisComponent(state, 2);

As described earlier, Reselect only memoizes on the most recent inputs (ie, it has a cache size of 1). That means that selectItemForThisComponent will never memoize correctly, because it's never being called with the same inputs back-to-back.

This code will still run and work, but it's not fully optimized. For the absolute best performance, we need a separate copy of selectItemForThisComponent for each instance of <SomeComponent>.

The React-Redux connect function supports a special "factory function" syntax for mapState and mapDispatch functions, which can be used to create unique instances of selector functions for each component instance.

If the first call to a mapState or mapDispatch function returns a function instead of an object, connect will use that returned function as the real mapState or mapDispatch function. This gives you the ability to create component-instance-specific selectors inside the closure:

const makeUniqueSelectorInstance = () => createSelector(
    [selectItems, selectItemId],
    (items, itemId) => items[itemId]
);    

const makeMapState = (state) => {
    const selectItemForThisComponent = makeUniqueSelectorInstance();

    return function realMapState(state, ownProps) {
        const item = selectItemForThisComponent(state, ownProps.itemId);

        return {item};
    }
};

export default connect(makeMapState)(SomeComponent);

Both component 1 and component 2 will get their own unique copies of selectItemForThisComponent, and each copy will get called with consistently repeatable inputs, allowing proper memoization.

Final Thoughts

Like other common Redux usage patterns, you are not required to use selector functions in a Redux app. If you want to write deeply nested state lookups directly in your mapState functions or thunks, you can. Similarly, you don't have to use the Reselect library to create selectors - you can just write plain functions if you want.

Having said that, you are encouraged to use selector functions, and to use the Reselect library for memoized selectors. There's also many other options for creating selectors, including using functional programming utility libraries like lodash/fp and Ramda, and other alternatives to Reselect. There's also utility libraries that build on Reselect to handle specific use cases.

Further Information

Selector basics and usage
Organizing selectors
- Dan Abramov's "Idiomatic Redux" video series: Colocating Selectors with Reducers
- Randy Coulman's posts on selectors and encapsulation:
- React/Redux Links: Redux Architecture - Encapsulation and Reusability
React/Redux Performance

The Obligatory introduction

Mark Erikson — Tue, 03 Jan 2017 21:54:51 +0000

I'm a (mostly web) dev in southwest Ohio. I'm a Redux maintainer, and write lots of stuff about React, Redux, and more.

I keep a big list of links on React, Redux, at related topics, at https://github.com/markerikson/react-redux-links , as well as a list of Redux addons at https://github.com/markerikson/redux-ecosystem-links .

I blog at http://blog.isquaredsoftware.com/ , and am on Twitter at @acemarke .

DEV Community: Mark Erikson

Coding Career Advice: Using Git for Version Control Effectively

Introduction

Table of Contents

Git Fundamentals

Git Terms and Concepts Overview

Git Basics

Sharing Data Between Repositories

Branches

Understanding Git Internals

Git Tools

Git Techniques

Improving CLI Logging

Preparing Commits in Pieces

Stashing Changes

Working with Branches

Creating and Switching Branches

Fetching, Pushing, and Pulling Branches

Merging Branches

Feature Branch Strategies

Pull Requests

Updating Branches in the Background

Rewriting Git History

Amending Commits

Resetting Branches

Rebasing Branches

Reverting Commits

Cherry-Picking

Interactive Rebasing

Reflog

Advanced History Rewriting

Git Patterns and Best Practices

Write Good Commit Messages

Make Small, Focused Commits

Clean Up Commit History Before Pushing

Only Rewrite Unpushed History

Keep Feature Branches Short-Lived

Code Archeology with Git

Displaying Historical File Changes

Bisecting Bugs

Final Thoughts

Further Information

Coding Career Advice: Searching and Evaluating Online Information Efficiently

Introduction

Suggested Search and Evaluation Process

Examples

Git History Rewriting

Searching for Info on How to Search

React-Redux, React Native, and Jest

Further Information

Announcing the new "Redux Fundamentals" core docs tutorial!

Coding Career Advice: Evaluating Software Libraries and Tools

Introduction

How to Correctly Evaluate Third-Party Software Libraries and Tools

Starting Point: Search Locations

Potential Evaluation Criteria

Zeroth Pass: Relevance

First Pass: Basic Suitability

Second Pass: Detailed Evaluations

Further Information

Coding Career Advice: Keeping a Daily Work Journal

Introduction

Tip #1: Keeping a Daily Work Journal

Why Keep a Work Journal?

Journaling Tools

Journal Organization

Example Journal Entry

2020-09-03 (Thursday)

Further Information

Debugging Tips and Tales

Mark's Debugging Advice

1) Reproduce the Issue

2) Errors Provide Useful Information

3) Learn to Use Debuggers

4) Print Logging is Important

5) Debug With a Plan

6) Don't Be Afraid

7) Know When To Keep Going, and When To Stop

Tales of Debugging

The Case of the Wrong Case