7 Little Things I Learned In January
Tags: webdev, learning
Published: 2021-02-01 15:43:23

---
title: 7 Little Things I Learned In January
published: true
description: 
tags: webdev, learning
series: monthly_learning
//cover_image: https://direct_url_to_image.jpg
---

I have a dozen half-written articles on dev.to and many more scattered across the universe. It's daunting and overwhelming trying to write something _good_. When these articles come out, I _know_ they'll be good but until I get there, I figured I'd kick off a new personal series :)

## 1. Use JQ to get info from `package.json` quickly

JQ is a command line utility that can explore JSON files. When I found out just how easy this utility is to install (every package manager has it) and to use, I created two aliases to help me with every day tasks:

```bash
# npmscr will print out a list of package.json scripts
alias npmscr="jq '.scripts' package.json"

# npmver will print out the package.json version
alias npmver="jq '.version' package.json"
```

## 2. What `git pull` does

I had a conversation with a fellow dev about this. And honestly, even while researching this for this article, the behavior is a tad confusing.

Out right, this is what `git pull` does:

```bash
git pull

# is equivalent to
git fetch && git merge FETCH_HEAD
```

We fetch data from remote and then merge it into our local.

The confusing part to me is if `git fetch` fetches _only_ data for our current branch or if it does a blanket `git fetch origin` equivalent.

## 3. `console.debug`

I had _no_ idea about `console.debug`. I've always used `console.log` to log any data for debugging. The biggest difference? It shows up differently in your console!

There's literally a special section (at least in chrome devtools) for debugging statements. In any application with regular logging or just a ton of random logs, this is a super easy way to split this stuff apart. 

Super happy that one of my colleagues showed this to me during a pairing session.

```js
console.debug({ thatOneTrickyVar });
```

## 4. Pair programming is a skill to be taught/learned

It might sound obvious to some and baffling to others. I started at a new job recently and had a conversation about this with a fellow programmer and later on, with one of my friends who is just starting out. I had been so used to pairing with my colleagues, that it didn't occur to me that this _helped_ me a ton to get better at pairing.

So what's there to learn? A balance between asking questions, observing, giving input, and a slew of other things.

From my experience, some people tend to micro-manage in either place (as a driver or navigator...or whatever the titles are), some tend to be too hands off, some people ask too many questions and some none at all. It's really an interesting aspect of programming.

I think a lot of programmers are opposed to pairing; however, the benefits of pairing _well_ are incalculable (and probably good for another article :) ). Strangely, from anecdotal experience, senior people have more issues with this than junior people.

## 5. Naming cheatsheet

Okay, okay, probably all of you already know about the [naming cheatsheet](https://github.com/kettanaito/naming-cheatsheet) that Kent C. Dodds tweeted about recently, but it's worth pointing out.

It's a nice little readme specifying various naming conventions. I personally don't agree with some of them but majority of the rules specified, I _already_ follow.

Conventions are extremely powerful, especially in a team setting. 

## 6. Basic TypeScript typing for React

I've used TypeScript with React only _passingly_ but I've used TypeScript quite a bit in Angular, for writing libraries, and just for fun. One thing that's always scary is figuring out the basics. They're often unavailable. So here's the gist of what I've learned:

```typescript
import React from 'react';

// type is `React.FC` (for "Functional Component")
const MyComponent: React.FC = () => { 
  return (
    <h1>Hi!</h1>
  );
};

// React.FC is a generic
interface IMyComponentProps {
  color: string;
  children: React.ReactNode; // React.ReactNode is any react node
}

const MyComponent: React.FC<IMyComponentProps> = ({ color = '#000',  children }) => {
  return (
    <>
      <h1 style={{ color }}>Hi!</h1>
      {children}
    </>
  );
}; 
```

## 7. You can run Cypress without a server

I've been used to writing [Cypress tests](https://cypress.io) as e2e tests where I had full ability to run a backend server. I recently found out that it's fairly straightforward to write mocks in Cypress.

Using routes:

```js
const mockResponse = { id: 1, content: 'Text' }
cy.route('/api/actual/endpoint', mockResponse)
```

The syntax allows for all kinds of specifications from capturing via wildcards `cy.route('/api/posts/*')` to specifying the protocol first like so: `cy.route('POST', '/api/posts/*', mockResponse)`. 

You can even pass in a function to handle/generate a response or even assert on the request body.

`cy.route` is deprecated though so you can always jump into using `cy.intercept`. The main reason I'm not using it is because last time I checked, `intercept` had a bug where it didn't match wildcards (the `*` in URLs). But `cy.intercept` is super powerful. Go checkout [cy.intercept docs](https://docs.cypress.io/api/commands/intercept.html) for more info. 

The point being, Cypress lets you run your _frontend_ without hitting your _backend_ if necessary.