
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.

```zsh
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:

![Base Path Example](/assets/images/base-path-directory-structure.png)

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

![Base Path Pages](/assets/images/base-path-pages-directories.png)

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:

```tsx
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:

```json
// 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:

```tsx
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.


Base Path in TypeScript


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._

<iframe
  height="300"
  style="width: 100%;"
  scrolling="no"
  title="Centering Content in CSS"
  src="https://codepen.io/donhamiltoniii/embed/bGpxQKd?default-tab=html%2Cresult"
  frameborder="no"
  loading="lazy"
  allowtransparency="true"
  allowfullscreen="true"
>
  See the Pen
  <a href="https://codepen.io/donhamiltoniii/pen/bGpxQKd">
    Centering Content in CSS
  </a>
  by Don Hamilton III (
  <a href="https://codepen.io/donhamiltoniii">@donhamiltoniii</a>) on
  <a href="https://codepen.io">CodePen</a>.
</iframe>

### Centering using `display: table`

Let's take a look at the code:

HTML:

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

SCSS:

```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:

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

SASS:

```scss
.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:

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

SCSS:

```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:

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

SCSS:

```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.


CSS Centering

CSS For Non-Designers


The publisher/subscriber pattern is a really cool pattern

## What is reactivity?


Publisher/Subscriber Pattern and Custom Events


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/bullshit. 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 FUCKING TESTS (re-read that 1000x and then slam your head into a wall. Get it tattooed on your body, paint it on the walls. Write tests for the love of whatever is important to you.), 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 fucking important. If you have tests in place for your application, you know that your code functions. If you break tests, you fucked up. That's ok. You should fuck up. That means you're making progress. Just make sure you don't leave anything fucked 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, refactor your tests, split things into utilities. But only in a way that makes sense. And let your code tell you what makes sense. Things to consider:

1. WTF is this code doing? - Can you answer that quickly? Can you make a TikTok that would allow someone to confidently implement your function?
2. 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.
3. Is it verbose? - Can you clean it up at all? Are you over-engineering?
4. Do my tests still reflect what I want them to? - This is _sort of_ and 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:

```ts
// 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**

```ts
// 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 = "fart";
    const expected = expect("FART");
    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.


Proper (Re)Factoring

GIT Etiquette


With help from [this article](https://trungtran.io/2020/12/07/set-up-an-expressjs-application-with-typescript-eslint-prettier/)


How To Set Up an Express Application


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](https://github.com/donhamiltoniii/how-to-structure-react-apps) 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.

```bash
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:

```typescript
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


How to Structure a React Project

JavaScript and `this`


Using trello for an agile board, breaking up work, and estimating tickets


Managing Projects with Trello and Ticket Estimation


How to return focus to a modal trigger once that modal gets closed.

1. Put the id of that element (or some identifying attribute) in local storage when the element is clicked
1. Use modal as necessary
1. When the close button of the modal is closed, use local storage to identify the triggering element and use `.focus()` to give it focus, close the modal, and then remove that id from local storage


Return Focus to Triggering Element Once a Modal is Closed


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.

```js
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:

```json
{
  "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.


Accessing Next Data in Browser


How to setup Next with MDX blog (or whatever) pages that include syntax highlighting for code blocks.


NextJS, TypeScript, Markdown, and Syntax Highlihting


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

```bash
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`

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


React 18 Third Party Component Rendering Issue


A general overview of REST APIs, how they work, and why we use them


REST APIs: An Overview


A general overview of run time and compile time as told by the differences between JS and TS


Run Time VS Compile Time

Data Reactivity with the Publisher/Subscriber Pattern


This article is more of a reminder than anything. [This video](https://www.youtube.com/shorts/NwqhFb4B5LU) 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.


Welcome

Posts