DEV Community: Don Hamilton III

VS Code Balance Out

Don Hamilton III — Mon, 08 Jul 2024 00:00:00 +0000

This article is more of a reminder than anything. This video explains everything about this command and how to implement it. Essentially this is a way to select an entire HTML element with a key binding instead of having to hunt through the document on your own for an opening and closing tag. Super useful.

Using Git and Github Effectively

Don Hamilton III — Wed, 07 Jun 2023 17:36:29 +0000

Using Git and Github Effectively

Git and Github are very powerful tools for managing collections of files. Most people are familiar with using Git for programming version control and Github for maintaining remote versions of these programs. Git can be used for more than version control for programming, but it can also be a tool to maintain any project or directory of files that it would be helpful to have snapshots of over time.

Following are some tips and practices that have helped me use git to not only more efficiently manage projects, but to also work with teams of developers on a code base. All of these tips should be able to be applied as best practices to any project that you are using git and Github to maintain. This will not be a comprehensive guide to using git. This article will provide useful tips that I have found useful to me in my projects.

General Tips

`HEAD` just refers to the most recent commit on whatever branch you're on.

HEAD was a concept that took me a really long time to understand. HEAD simply refers to your most recent commit on whatever branch you are currently on. Grasping that makes things like "detached HEAD states" much less confusing

Always use `git add -p` instead of `git add .` to avoid committing unintended files.

The git add -p command goes through the changes that you haven't staged and asks you about changes one by one and asks you if you want to include them on the current commit. This might seem tedious, but it can save you a lot of time by avoiding commits that contain changes that should be saved for later, smaller commits.

Generally use `git commit -v` instead of `git commit -m <message>` to type a long form commit.

Admittedly, one of the first reasons I started doing this was to get more familiar with Vim and editing files (especially small changes) from the command line. While using Vim is certainly a noble pursuit in and of itself, it is definitely a much better practice to have some sort of commit template in place when you are working with teams and sticking to it as much as possible. Examples of commit templates can be found here.

Always do a `git rebase -i` before submitting a feature branch for PR.

More on this in a later section, but this allows you to clean up your commits before showing people your work. Which means you can get rid of things like work-in-progress commits, merge commits that may be related to one another, rename commits after having more context for what they actually do, etc. It helps clean up your changes and gives your team, and future members of your team, a better idea of what work was done.

Stashing

Stashing is a phenomenal resource in git that I feel gets underused. Here is an example scenario. You are working on a branch in which you have progress you aren't ready to commit. A co-worker reaches out and asks you to review some work on another branch before they make a PR. You don't want to muddy up your commit history with a work-in-progress commit, but you don't want to move this work to your co-workers branch either. What do you do? Use git stash instead! This saves a version of your current work in the stash list. Then when you finish and return to your original branch, simply reapply your previous changes using git stash pop. Now you're back where you left off with no unneeded commits!

Time Travel and Undoing

It's really useful to be familiar with restoring, resetting, and reverting. Now if you stick to good git practices, you can usually avoid these. USUALLY. But there are times when you or your teammates might add some code into a commit that shouldn't be there and you will need to do a little time traveling to work things out. The best thing about git is that it is truly almost impossible to blow work away forever. There is almost always a way to go back to previous states or recover code that might accidentally get deleted. So if you think you've irrecoverably broken something or lost all the work you did on that new feature, CALM DOWN. You can fix it.

note: HEAD~# refers to a way to specify a number of commits behind the current HEAD. For example, if you simply want to go back one commit from where you are now in the commit tree, simply type HEAD~1 and go back one commit relative to where you are.

`git restore --source [<commit hash or HEAD~#>] <file-name>`

Unstage a file that is currently staged for commit or return a file to a state at a previous commit. Restore is usually used before you make a commit and you stage something you didn't mean to. (read: use git add -p and not git add .)

`git reset <commit-hash or HEAD~#>`

Reset is what you want to use when you need to undo an existing commit. Using the command above takes HEAD back to specific commit but DOES NOT remove changes. It brings files back to a new HEAD for you to do as you please. So your files will almost look like you have a merge conflict and allows you to fix up your files as you need.

`git reset --hard <commit-hash or HEAD~#>`

Removes all commits following the specific commit and DOES remove changes. All work from removed commits is lost. So essentially, this takes you back in time to whatever commit you specify and removes all of the commits you made after that point. BE CAREFUL especially if you are going to be removing commits that have been pushed and may already be merged. This will not be fun to deal with in teams.

`git revert <commit-hash or HEAD~#>`

Removes changes to a given commit very much like git reset BUT creates a new commit with those changes instead of removing commits and changing git history. Almost all of the time, you want to use git revert over git reset, but there are exceptions. You can pretty safely use git reset if you are working locally and the changes to the commit history will not affect anyone else that may be working on the branch you will be changing.

Fetch/Pull

Fetch

Fetching retrieves any changes from the remote and puts them in the local repository. It does not apply these changes to any files and, as such, doesn't alter any work that you may have in a given file. For example, if you're working in a file called Button.tsx and you've made changes to 30 lines and then perform a git fetch and another 20 lines have been changed in that file on the remote, you will now have those new lines, but you will not have them moved into your local file until you either choose to git merge or git rebase. This is preferable to git pull as it gives you options.

Speaking of...

git pull on the other hand combines the commands git fetch and git merge. This is more dangerous because you may end up with merge conflicts that you do not anticipate and give you no way to deal with them other than fixing the merge and making a new commit. (note: the new commit is the problem albeit not a horrible one if you stick to the rule of doing a clean-up rebase before pushing)

Tips

It is generally a good idea to use git fetch alongside git rebase which will come later. A colleague on a previous project got me in the habit of doing a git fetch followed by a git rebase every morning from our development branch to our feature branches. (the development branch is the one we would make PRs to from our feature branches). This is a tremendous help because it severely cuts down on merge conflicts later on when you PR said feature branch as you've already worked through any file changes in much smaller chunks. (At least most of the time...)
Use git checkout origin/<branch-name> after using git fetch to take a look at changes before rebasing. This can give you a good idea of any conflicts you may be fixing ahead of time and mitigating them in your code first. An ounce of prevention is worth a pound of cure.

Why Feature Branches

I've mentioned feature branches. So a quick aside on what I mean. The concept of feature branches comes from trunk-based development. (note: I'm not going to be going into detail about that as it is extensive. But you can read more about it here if you'd like.)

Feature branches are short lived branches that only exist for the duration of a feature's development. Once the given feature is done, the branch is merged back into the main branch and then deleted. This process usually includes a code review before merging back into the main branch.

This is the very short version of how feature branches work. Feature branches are useful because they prevent developers from working on the same branch while making the new features. This is a good work flow because it prevents developers doing a bunch of work on one branch all at the same time. It is a very important topic when working with teams and I encourage you to seek out more information about it and talk to your fellow developers about best practices.

Rebasing

Golden Rule: Don't rebase if other people are working with your branch! Since rebasing creates new commits that are identical to the commits you had previously, it does remove the commits that were in place. BUT, to reiterate, if you are using feature branches properly, this should never become an issue. Don't share your branches. Covet them. You are Smeegle, it is your precious ring. Don't merge it until it is done. Once a branch is merged, work should not be done on the feature. If work does need to be done, log a bug or new feature.

Rebasing is essentially a way to put your feature branch at the end of the current branch instead of dealing with merges intermittently in that branch. The best way to think of this is in comparison to merging. Imagine you are working on a code base with a team of developers and you want to keep in sync with the main branch once a day (a very typical workflow). You can do this by pulling down the main branch each morning and then merging it with your feature and then cleaning up any subsequent changes. The issue with this practice is that the merges then muddy up your branch with commits that do nothing other than get the most current version of the development branch.

On the other hand, if you do the same practice with rebase, you are simply updating your branch with the changes and shifting where your changes exist in relation to the current HEAD of the main branch. Which keeps things a lot cleaner and doesn't muddy up your commit history.

Interactive Rebasing

Interactive rebasing is the process by which you can alter commits before they are remade by git rebase. To do this we use the command git rebase -i [<branch-name>] [<HEAD-#]>. Notice that both the branch name and number of commits is optional. But one or both is highly recommended. Now what can you do with it?

Rewording

You can use rebase to reword commit messages before git replaces that commit. This is especially useful with hindsight because you might have a better idea of what that commit was actually doing with respect to the finished work.

Fixing Up and Squashing

fixup gives you the ability to squash commits into one another but also gives you the ability to give a new commit name if you'd like. While squash will just fold commits into the previous commit without giving you the rename option. Opt for fixup so you don't have to remember more keywords and they do the same thing.

Both of these maintain the code changes from removed commits. They just clean up history.

Drop

This is dangerous. It gets rid of the commit and any changes in it. It's like it never happened.

Conclusion

Hopefully these tips can help you use git a little more efficiently. Git is an amazing tool and one that we as developers should be using as ambitiously as possible. Thanks for reading!

Integrating MUI Button with React Router Link in React Applications

Don Hamilton III — Wed, 07 Jun 2023 17:35:00 +0000

Introduction

In modern web development, particularly in React applications, it's often necessary to combine UI components with navigation functionality. Material-UI (MUI), a popular React UI framework, offers a comprehensive set of components that are both functional and aesthetically pleasing. React Router, on the other hand, is a standard library for routing in React. Integrating MUI's Button component with React Router's Link component allows developers to create buttons that not only look good but also facilitate seamless navigation. This article will guide you through the process of combining these two powerful tools.

Prerequisites

Before diving into the integration, ensure that you have the following prerequisites in your React project:

React and React DOM
Material-UI (MUI)
React Router

You can install Material-UI and React Router via npm:

npm install @mui/material @emotion/react @emotion/styled npm install react-router-dom

Basic Integration

To start, we'll integrate a basic MUI Button with React Router's Link. Here's a simple example:

import React from 'react';
import { Link } from 'react-router-dom';
import Button from '@mui/material/Button';

export const MyButtonLink = () => (
    <Button component={Link} to="/your-path">
        Navigate
    </Button>
);

In this code snippet, the Button component from MUI is combined with the Link component from React Router using the component prop of the Button. The to prop specifies the navigation path, which is a key feature of the Link component.

Styling the Button

Material-UI provides extensive styling options. You can customize the appearance of the button to match your application's design. Here’s an example of a styled button:

import React from 'react';
import { Link } from 'react-router-dom';
import Button from '@mui/material/Button';
import { makeStyles } from '@mui/styles';

const useStyles = makeStyles(theme => ({
    linkButton: {
        backgroundColor: theme.palette.primary.main,
        color: 'white',
        '&:hover': {
            backgroundColor: theme.palette.primary.dark,
        },
    },
}));

export const MyStyledButtonLink = () => {
    const classes = useStyles();

    return (
        <Button
            component={Link}
            to="/your-path"
            className={classes.linkButton}
        >
            Navigate
        </Button>
    );
};

In this example, we use makeStyles to create custom styles and apply them to the button. This allows for a more personalized and consistent look throughout your application.

Handling Navigation Programmatically

Sometimes, you might need to handle navigation programmatically, such as after a certain action is completed. Here’s how you can do it:

import React from 'react';
import { useHistory } from 'react-router-dom';
import Button from '@mui/material/Button';

export const MyProgrammaticButton = () => {
    const history = useHistory();
    const handleNavigation = () => {
        // Perform some action
        history.push('/your-path');
    };

    return (
        <Button onClick={handleNavigation}>Navigate</Button>
    );
};

In this example, the useHistory hook from React Router is used to navigate programmatically. The history.push method is called within an event handler, allowing for more complex navigation logic.

Combining with Other MUI Components

Material-UI's ecosystem is vast, and you can integrate the Button with other components like Icons, Toolbars, or Drawers. Here's an example with an Icon:

import React from 'react';
import { Link } from 'react-router-dom';
import Button from '@mui/material/Button';
import ArrowForwardIcon from '@mui/icons-material/ArrowForward';

export const MyIconButtonLink = () => (
    <Button
        component={Link}
        to="/your-path"
        startIcon={<ArrowForwardIcon />}
    >
        Navigate
    </Button>
);

This example demonstrates how to add an icon to your button, enhancing its visual appeal and user experience.

Advanced Navigation Patterns

In more complex applications, you might have nested routes or need to pass state to the navigation. React Router's Link component allows for these advanced patterns. For instance, you can pass state as follows:

import React from 'react';
import { Link } from 'react-router-dom';
import Button from '@mui/material/Button';

export const MyButtonWithState = () => (
    <Button
        component={Link}
        to={{
            pathname: "/your-path",
            state: { fromButton: true }
        }}
    >
        Navigate with State
    </Button>
);

In this example, the to prop is an object that includes both the pathname and the state. This is particularly useful when you need to pass data to the route you are navigating to.

Accessibility Considerations

When integrating UI components, it's important to consider accessibility. Material-UI components are designed with accessibility in mind, but you should ensure that your navigation is also accessible. This includes proper labeling, keyboard navigation, and focus management. For instance, adding an aria-label to your button can improve accessibility:

<Button
    component={Link}
    to="/your-path"
    aria-label="Navigate to your path"
>
    Navigate
</Button>

Conclusion

Integrating MUI's Button with React Router's Link provides a powerful way to create navigable UI elements in your React applications. This combination allows you to leverage the aesthetics and functionality of MUI with the navigational capabilities of React Router, resulting in an efficient and user-friendly experience. By following the examples and patterns outlined in this article, you can effectively integrate these two technologies in your next React project. Remember to always consider customization and accessibility to create a more inclusive and engaging user interface.

How to Structure a React Project

Don Hamilton III — Wed, 08 Mar 2023 00:00:00 +0000

One of the biggest problems we face as developers is project or directory structure. It's important to have a set structure for your projects so that as they grow, your code is well organized and easy to navigate. I recently found a way to organize React projects that I personally believe is so good that I want to share it.

Disclaimer: This sort of organization can be used in pretty much any project with minor changes based on the project.

Here is the repo if you want to explore everything.

Components

Starting at the component level, what I like to do is continue to use principles of OOP in all of my JS/TS applications. But This doesn't mean we have to use Classes, Methods, and Properties. If you would like to do that and create instances in a more traditional way, that's fine. But I think that it ignores all of the great things that we get from modern JS/TS. We can still follow SOLID principles without Classes.

component
  |-- component.tsx
  |-- hooks.ts
  |-- index.ts
  |-- styles.css
  |-- test.tsx
  |-- utils.ts

What do each of these files do?

`component.tsx`

Houses everything that is going to be rendered on screen by React. This file should contain as little logic as possible. If you can eliminate it entirely, all the better. Obviously that's not always popular but it should be the goal to keep the component as close to just markup as possible.

`hooks.ts`

For any hooks in the component that are only used in this component. Any hooks that are shared with other components should be pulled up higher into a hooks directory at the root directory or src depending on how your project is structured.

`index.ts`

Is solely our public interface for our component. Anything meant to be exported from this component gets exported from here. For example:

export * from "./component";

Those sorts of exports are all that we include here

`styles.css`

Should be fairly self explanitory. This is where we keep styles related to our component. This can also be a JS/TS file if you're using styled components or SASS or anything else so long as it's related to styling.

`test.tsx`

Is where we house the unit tests for our component.

`utils.ts`

Should contain utility functions related specifically to this component. Similar to the hooks file, anything that would be shared between components

Accessing Next Data in Browser

Don Hamilton III — Wed, 08 Mar 2023 00:00:00 +0000

Today's is just a quick post of a discovery from a colleague. On the project that I'm currently assigned to, we are using NextJS to build some pretty amazing tech. One thing that we are constantly running up against is checking the data that we are receiving from one of the handful of APIs from which we are sourcing.

Usually this involves all sorts of looking around inside of the network tab or console logging or all kinds of other work-around, hacky shit to see wtf we're getting. Which is both just bad form and, in most cases, ineffective.

Until this wonderful, beautiful, simple, little one line of code came into all of our lives.

JSON.parse(document.getElementById("__NEXT_DATA__"));

It turns out that Next provides you the data that is being provided as props to the page in a serialized JSON object. Just another reason to love tf out of this framework. Here's an example payload that I get from my recipe site:

{
  "props": {
    "pageProps": {
      "recipes": [
        {
          "title": "Bacon Wrapped Jalapeño Poppers",
          "prepTime": "15 minutes",
          "cookTime": "15 minutes",
          "servings": 8,
          "imgUrl": "/img/jalapeno-poppers.jpg",
          "description": "Jalapeños stuffed with cheese and wrapped with bacon.",
          "notes": "Mad easy. Mad delicious. Perfect side dish.",
          "tags": [
            "keto",
            "jalapeño",
            "cheese",
            "cream cheese",
            "bacon",
            "appetizer",
            "side dish"
          ],
          "content": "\n### Ingredients\n\n- 8 Jalapeños, hollowed\n- 8oz Cream Cheese\n- 8oz shredded cheese of your choice\n- 8 slices bacon\n\n### Instructions\n\n1. Cut a \"T\" into one side of your Jalapeños and scoop out the seeds.\n1. In a bowl, mix cream cheese and shredded cheese until throughly mixed.\n1. Preheat air frier for 10 minutes at 400°\n1. Stuff each pepper with cheese mixture and wrap with one slice of bacon. Wrap the ends of the bacon underneath so they stay together.\n1. Cook for 15 minutes at 350°\n1. Eat them all in one sitting.\n",
          "slug": "bacon-wrapped-jalapeño-poppers"
        }
      ]
    },
    "__N_SSG": true
  },
  "page": "/",
  "query": {},
  "buildId": "development",
  "isFallback": false,
  "gsp": true,
  "scriptLoader": []
}

I truncated the recipe list for readability but you get the idea. Look at how easy and pretty that is! Keep this in mind whenever you're dealing with Next data. This is a game changer folx.

Proper (Re)Factoring

Don Hamilton III — Wed, 08 Mar 2023 00:00:00 +0000

Don't factor your code too early! There are plenty of organizational patterns that are essentially universal in an application.

Having a src directory
components - React/Next
utils - every project
routes/views - web anything

These will probably exist in all of your applications/projects/whatever. Dont be afraid of using them. But let your applicaiton be abstract in the beginning. Don't rush to set a structure for how things should be organized, what should constitues a module, what should be a class (or shouldn't), making hooks, making utilities, etc. Just write the code, make the application work, WRITE THE TESTS (re-read that 1000x, get it tattooed on your body, paint it on the walls. Please. Write. Tests.), write documentation, know what it all does.

🚨🚨🚨 BEFORE YOU COMMIT YOUR CODE!, REFACTOR!!! 🚨🚨🚨

Or, when you do it the first time, factor. This is why testing is sooooo important. If you have tests in place for your application, you know that your code functions. If you break tests, you messed up. That's ok. You should mess up. That means you're making progress. Just make sure you don't leave anything messed up.

This is the stage in the development process where you make sure things are organized properly. This is the part where you focus on CODE READABILITY.

Split logic out into the tiniest possible pieces. Make new functions/methods, organize modules differently, split things into utilities. But only in a way that makes sense. And let your code tell you what makes sense. Things to consider:

WTF is this code doing? - Can you answer that quickly? Can you make a TikTok that would allow someone to confidently implement your function?
Is this repetative? - Is this logic (Or similar logic) happening anywhere else? If so, combine it. Pull it into a function. Move that function up the directory tree wherever it makes sense.
Is it verbose? - Can you clean it up at all? Are you over-engineering?
Do my tests still reflect what I want them to? - This is sort of an after refactoring thing. I say sort of because it very much IS refactoring. But, refactoring your tests tend to happen after you refactor the corresponding code. For example:

// Code
function camelCaseToCapitalSnakeCase(str: string): string {
  return str.replace(/[A-Z]/g, (letter) => `_${letter}`).toUpperCase();
}

// Test
describe("camelCaseToCapitalSnakeCase", () => {
  test("should convert string to capital snake case", () => {
    const testString = "hereIsMyCamelCaseString";
    const expected = expect("HERE_IS_MY_CAMEL_CASE_STRING");
    const result = camelCaseToCapitalSnakeCase(testString);

    expected.toBe(result);
  });
});

REFACTOR

// Code
function camelToSnakeCase(str: string): string {
  return str.replace(/[A-Z]/g, (letter) => `_${letter}`);
}

function capitalize(str: string): string {
  return str.toUpperCAse();
}

// Test
describe("camelToSnakeCase", () => {
  test("should convert camel to snake case", () => {
    const testString = "hereIsMyCamelCaseString";
    const expected = expect("here_is_my_camel_case_string");
    const result = camelToSnakeCase(testString);

    expected.toBe(result);
  });
});

describe("capitalize", () => {
  test("should capitalize given string", () => {
    const testString = "example";
    const expected = expect("EXAMPLE");
    const result = capitalize(testString);

    expected.toBe(result);
  });
});

While this refactoring essentially happens at the same time (or should), usually the work to the code is done, the initial test fails, the tests are updated to reflect the change to the code.

Refactoring is such an important step in the development of a code base. Mostly because tech debt has a strange way of going unpaid. There are so many minor things that we convince ourselves as devs that we will come back to, or someone will, to "clean up" or "clarify". But that rarely happens. The reality of writing code, especially new code, is that you have more context right now than anyone else, including yourself in a month, is ever going to have again. You know exactly what problem you're trying to solve and why you're doing it the way that you are. So it is your responsibility to try to capture that as much as possible for people in the future, including you. So don't let deadlines get in the way of doing the right thing. Take the extra hour or 4 or 8 to make sure this step happens. Because if you're in an environment that tracks tech debt, great. But the harsh reality is that those tickets will probably get stale before they get played. So do the work now.

React 18 Third Party Component Rendering Issue

Don Hamilton III — Wed, 08 Mar 2023 00:00:00 +0000

If you ever run into a build error with any package that looks like this:

12:06:28 PM: $ yarn build
12:06:28 PM: yarn run v1.22.10
12:06:28 PM: $ next build
12:06:28 PM: info  - Checking validity of types...
12:06:32 PM: Failed to compile.
12:06:32 PM:
12:06:32 PM: ./pages/_app.tsx:6:11
12:06:32 PM: Type error: 'Component' cannot be used as a JSX component.
12:06:32 PM:   Its element type 'ReactElement<any, any> | Component<{}, any, any> | null' is not a valid JSX element.
12:06:32 PM:     Type 'Component<{}, any, any>' is not assignable to type 'Element | ElementClass | null'.
12:06:32 PM:       Type 'Component<{}, any, any>' is not assignable to type 'ElementClass'.
12:06:32 PM:         The types returned by 'render()' are incompatible between these types.
12:06:32 PM:           Type 'React.ReactNode' is not assignable to type 'import("/opt/build/repo/node_modules/@types/react-syntax-highlighter/node_modules/@types/react/index").ReactNode'.
12:06:32 PM:             Type '{}' is not assignable to type 'ReactNode'.
12:06:32 PM:   4 |
12:06:32 PM:   5 | export default function MyApp({ Component, pageProps }: AppProps) {
12:06:32 PM: > 6 |   return <Component {...pageProps} />;
12:06:32 PM:     |           ^
12:06:32 PM:   7 | }
12:06:32 PM:   8 |
12:06:32 PM: error Command failed with exit code 1. (https://ntl.fyi/exit-code-1)
12:06:32 PM: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

The current fix is to add the following to your package.json

}
  // ...
  "resolutions": {
    "@types/react": "17.0.40"
  }
}

Base Path in TypeScript

Don Hamilton III — Sat, 04 Mar 2023 00:00:00 +0000

Whenever working in TypeScript, we deal with importing and exporting modules in our project. This quick post is just a reminder/tutorial for how to set up a base path so that we may reference these modules in a more organized fashion.

Let's begin by creating a new project. We could just create a basic TypeScript app but let's create something a little more practical. We'll be creating a simple NextJS app that uses TypeScript. This is a pretty popular stack these days since it provides a full stack environment with the (current) most popular view library.

To start, let's navigate to a directory to make our project and run the following command.

npx create-next-app base-path-example --ts

This will build out a new Next app called base-path-example with a directory structure that looks like this:

Inside of this project, we're going to include a deeply nested path by adding a few directories inside of pages.

This is going to illustrate what happens when we have to bring in a component from way higher up in the directory tree. Here's what our deeply nested page looks like:

import { Counter } from "../../../../components/counter";

export default function CounterPage() {
  return (
    <div>
      <Counter />
    </div>
  );
}

Notice that we're bringing in this Counter component from the components directory which is four levels up. While this certainly works, it's a little difficult to read and in an app with dozens, or even hundreds of pages, these ../ pieces get annoying to deal with.

To solve this issue, we can make a quick and easy update to our tsconfig.json file which will simplify our imports throughout our entire app. Inside of tsconfig.json, add the following:

// tsconfig.json

"compilerOptions": {
  // ...
  "baseUrl": ".",
  "paths": {
      "@/*": ["./src/*"]
  }
}

This gives us a shorthand to reference the src directory. So now on any of our imports, we can just start with @. Now we can revisit that deeply nested page and make the following change:

import { Counter } from "@/components/counter";

export default function CounterPage() {
  return (
    <div>
      <Counter />
    </div>
  );
}

Now we can reference all directories and files relative to the src directory! This avoids all of the backtracking with ../! As small of a change as this may be, it will save TONS of time with imports and help your code look a lot cleaner in the process.

SIDE NOTE FOR FULL-STACK/API PROJECTS

If you are building something with ts-node or nodemon, you also need to follow this section of the ts-node docs.

CSS Centering

Don Hamilton III — Sat, 04 Mar 2023 00:00:00 +0000

Today we're going to be looking at the different ways in which you can center content in CSS. We're gonna go through a bit of a history lesson as well to illustrate just how amazing modern tools are in comparison to the shit we used to have to write as developers to achieve the same goal. We are going to be looking at examples of centering both horizontally and vertically but all of these examples can be used to accomplish each task individually.

* Only the SCSS related to positioning is included. You will see more in the CodePen.

Centering using `display: table`

Let's take a look at the code:

HTML:

<table class="table-centering">
  <tr class="table-centering__row">
    <td class="table-centering__content">:( why?</td>
  </tr>
</table>

SCSS:

.table-centering {
  &__row {
    text-align: center;
    vertical-align: center;
  }
}

As we can see, this achieves what we want. But this is clunky and it violates a few golden rules. First of all, this isn't tabular data so our markup (HTML) isn't semantic. It's also violating separation of concerns as we're using our content layer to handle styling. In older web infrastructure, this method of styling isn't uncommon to see. Though it is INCREDIBLY frowned upon. So, moving on to better options.

Centering using `transform`

Now we'll explore a better (still not best) option. This one came about once we got the transform property available in browsers (2009ish). This is definitely a better way to achieve our centered goal than the previous as it allows us to semantically markup our content as well as abide by separation of concerns by keeping the positioning solely to the style (SCSS) layer. Let's take a look at the code and then go over the pros and cons:

HTML:

<section class="transform-centering">
  <p class="transform-centering__content">:| slightly less why?</p>
</section>

SASS:

.transform-centering {
  position: relative;

  &__content {
    left: 50%;
    position: absolute;
    top: 50%;
    transform: translateX(-50%) translateY(-50%);
  }
}

The first notable difference here is the markup. We only have a containing element and a contained element. Honestly, this is all we should have since we're centering one thing inside of something else. Second, it's semantic. We have a section, which is properly descriptive of what it is/does and the content is enclosed in a p tag which also accurtately describes what we're dealing with. These might seem like trivial details, but I assure you, for many reasons, they are not. This will be beneficial to other developers looking at your code and it will be much more descriptive for screen readers and robots (read Google bots) crawling your page to index it inside of their search algorithms.

Next, let's examine the styling. There are a few more lines of code here to achieve our goal, but what is better about this solution is that everything about the positioning is encapsulated in the style layer.

What I personally dislike (you should too) about this method is that it forces us to alter the position attribute of both of these elements. While this isn't strictly taboo, it can cause unforeseen consequences with other style rules. It is general best practice to avoid manipulating position, BUT, this does work. The quick explanation is that we are pushing the paragraph 50% the width and height of the container. The problem is we are pushing relative to the top left corner of the contained element. So then we are manipulating the contained element to move half of its own width and height up and to the left respectively. In so doing, we center the paragraph in the section.

Centering using `flex`

Finally, we arrive at THE definitive answer for centering in modern web development. The answer is for sure using Flexbox. We need look no further than the code to understand why:

HTML:

<section class="flexbox-centering">
  <p class="flexbox-centering__content">:) very much zero why?</p>
</section>

SCSS:

.flexbox-centering {
  align-items: center;
  display: flex;
  justify-content: center;
}

So this technique combines all of the good parts of the previous examples while omitting all of the bad parts. First, our markup is succinct and semantic. Next, our styling is encapsulated and only needs 3 lines of code to work.

This is partially why flexbox exists. It's all about positioning and ordering elements without having to worry about the content layer. This is exactly how we want our code to work. That is textbook definition of proper separation of concerns.

BONUS Centering using `grid`

It is possible to center content inside of grid containers as well. Though, I would argue that you should use flex by default, sometimes that adds superfluous code which should ALWAYS be avoided if possible. So let's take a look at how we can achieve our goal in grid.

HTML:

<section class="grid-centering">
  <p class="grid-centering__content">:) very much zero why? #2</p>
</section>

SCSS:

.grid-centering {
  align-content: center;
  display: grid;
  justify-items: center;
}

Not much more to review here aside from the fact that we're using a different display value. The only notable difference here is the usage of align-content and justify-items as opposed to their Flexbox counterparts.

Conclusion

We've gone through a bit of a history lesson as far as how we deal with layout and positioning in our web sites/applications. The first two are here for historical reference only. Going forward, we should all be using Flexbox and Grid whenever we're dealing with layout and positioning.

DEV Community: Don Hamilton III

VS Code Balance Out

Using Git and Github Effectively

Using Git and Github Effectively

General Tips

HEAD just refers to the most recent commit on whatever branch you're on.

Always use git add -p instead of git add . to avoid committing unintended files.

Generally use git commit -v instead of git commit -m <message> to type a long form commit.

Always do a git rebase -i before submitting a feature branch for PR.

Stashing

Time Travel and Undoing

git restore --source [<commit hash or HEAD~#>] <file-name>

git reset <commit-hash or HEAD~#>

git reset --hard <commit-hash or HEAD~#>

git revert <commit-hash or HEAD~#>

Fetch/Pull

Fetch

Speaking of...

Tips

Why Feature Branches

Rebasing

Interactive Rebasing

Rewording

Fixing Up and Squashing

Drop

Conclusion

Integrating MUI Button with React Router Link in React Applications

Introduction

Prerequisites

Basic Integration

Styling the Button

Handling Navigation Programmatically

Combining with Other MUI Components

Advanced Navigation Patterns

Accessibility Considerations

Conclusion

How to Structure a React Project

Components

component.tsx

hooks.ts

index.ts

styles.css

test.tsx

utils.ts

Accessing Next Data in Browser

Proper (Re)Factoring

React 18 Third Party Component Rendering Issue

Base Path in TypeScript

SIDE NOTE FOR FULL-STACK/API PROJECTS

CSS Centering

Centering using display: table

Centering using transform

Centering using flex

BONUS Centering using grid

Conclusion

`HEAD` just refers to the most recent commit on whatever branch you're on.

Always use `git add -p` instead of `git add .` to avoid committing unintended files.

Generally use `git commit -v` instead of `git commit -m <message>` to type a long form commit.

Always do a `git rebase -i` before submitting a feature branch for PR.

`git restore --source [<commit hash or HEAD~#>] <file-name>`

`git reset <commit-hash or HEAD~#>`

`git reset --hard <commit-hash or HEAD~#>`

`git revert <commit-hash or HEAD~#>`

`component.tsx`

`hooks.ts`

`index.ts`

`styles.css`

`test.tsx`

`utils.ts`

Centering using `display: table`

Centering using `transform`

Centering using `flex`

BONUS Centering using `grid`