7 Little Things I Learned In January

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:

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

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.

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

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

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 for more info.

The point being, Cypress lets you run your frontend without hitting your backend if necessary.

Comments

[Paul Duvall]

Great idea for a series!