Forem: Deckstar

React Pro Tip #2 — How to Type `this.props` to Include `defaultProps`

Deckstar — Wed, 19 Oct 2022 18:11:46 +0000

This trick is for those occasions when you use a class component, and don't want TypeScript to complain about optional props being possibly undefined, despite definitely being included in defaultProps.

In a word, how to fix this:

Unfortunately, TypeScript doesn't know that defaultProps get added to this.props. And so we get Object is possibly 'undefined'. in places where we shouldn't. Quelle horreur!

Contents:

TLDR
Explained
Drawbacks
Conclusion
Further reading

TLDR

There are two ways to solve this. Both should be simple & easy to understand.

Case 1: Simple

If your Props interface is not used anywhere else, you may want to just remove the optional ?: from the type:

interface RatingProps {
  /**
   * The rating out of 10.
   *
   * @default 10
   */
  rating: number; // <--- remove the `?`
}

As long as the prop is included in the component's defaultProps, React's typing should be smart enough to not force you to specify the prop when using the component:

return <Rating /> // `rating` is required, but we don't need to specify it because it's included in `defaultProps`

This is the recommended way to solve this problem, if you're writing the code from scratch. This solves the "possibly undefined" error within the component without creating errors elsewhere, provided that no other types depend on the Props interface.

But if interface Props {} is already interdependent with other types, and you don't want to refactor them, then you might benefit from the fancier solution below:

Case 2: Slightly more complicated

It may be you can't make the props required, or feel it would be unnecessarily complicated to do so (for example, if many other types depend on the type of your props). In that case, you can still fix this error.

All you need is this one-line trick:

import React, { Component } from "react";

interface RatingProps {
  /**
   * The rating out of 10.
   *
   * @default 10
   */
  rating?: number;
}

class Rating extends Component<RatingProps> {
// ---------
  declare readonly props: RatingProps &
    Required<Pick<RatingProps, keyof typeof Rating.defaultProps>>; // <--- Add me!
// ---------

  constructor(props) {
    super(props);
  }

  static defaultProps = {
    rating: 10,
  };

  render() {
    const { rating } = this.props;

    if (rating < 5) return <p>Fail</p>;
    return <p>{rating}</p>;
  }
}

export default Rating;

(Well, two if you include formatting... 😉)

This method should be fool-proof: this.props should now be perfectly typed within the component, and no other side-effects should be produced in any types anywhere else.

Declare your own props, and voilà! Problem solved!

Explained

React's type definitions file (index.d.ts) defines the props as:

readonly props: Readonly<P>;

The reason method #1 works, is because of this definition in the same file:

type ReactManagedAttributes<C, P> = C extends { propTypes: infer T; defaultProps: infer D; }
    ? Defaultize<MergePropTypes<P, PropTypes.InferProps<T>>, D>
    : C extends { propTypes: infer T; }
        ? MergePropTypes<P, PropTypes.InferProps<T>>
        : C extends { defaultProps: infer D; }
            ? Defaultize<P, D>
            : P;

in which React infers the leftover required props based on the supplied defaultProps.

Method #2 works because of the following: by declaring our own props at the top of the component, we simply overwrite React's definition of props inside the component definition itself to not only use the P (i.e., the type of the component's passed in Props) but also its defaultProps. (In TypeScript, this is known as a "type-only field declaration".)

Pretty neat, huh?

Another pro-tip: I've actually written a reusable helper type — WithDefaultProps — to make this trick easier:

/**
 * Like `Required`, but you can choose which keys to make required. (`Required` makes all keys required).
 *
 * ---
 *
 * Example:
 * `typescript
 * type Obj = { a?: 1; b?: 2; c?: 3 };
 * type PartiallyRequiredObj = Imposed<Obj, 'a' | 'b'>; // equivalent to `{ a: 1; b: 2; c?: 3 }`;
 * `
 */
export type Imposed<T, K extends keyof T> = T & Required<Pick<T, K>>;

/**
 * A helper for React class components with `static defaultProps`.
 *
 * To use, simply add `declare readonly props:` at the top of the class:
 * `ts
 * class MyComponent extends Component<Props>{
 *  declare readonly props: WithDefaultProps<Props, typeof MyComponent.defaultProps>;
 *
 *  // ...
 * }
 * `
 */
export type WithDefaultProps<PassedInProps, DefaultProps extends object> =
  Readonly<Imposed<PassedInProps, keyof DefaultProps>>;

Drawbacks

As far as I can tell, there are no drawbacks to either of these methods. (Keep in mind that method #1 is just using React's defaultProps in a way that's working as intended).

For the custom props declaration method, try to keep in mind that you are forcefully overwriting the props. You must beware of typos which might ruin your type, especially when copy-pasting. Forgetting about this fact might lead to surprises if you don't keep in mind where the types come from.

Also, note that you have to know that defaultProps will definitely be passed in, because TypeScript won't know this. And a React novice might not know that either, so it might be a good reason to add a JSDoc comment over your custom props declaration. (Not to mention that the seniors will probably wonder what the heck you're doing 😄)

Otherwise, use it to your heart's content! 🙂

Conclusion

In this article, we saw two quick & easy ways to make sure that your this.props always remains type-safe.

If you're one of the few people still using class components, then this tip may have been helpful for you 😄

React Pro Tip #1 — Name your `useEffect`!

Deckstar — Thu, 06 Oct 2022 19:46:58 +0000

There's a very simple trick that will 10x your useEffect hooks' readability, and probably improve their performance, too: use named functions as callbacks for your useEffects. You might even find that you don't need an effect at all!

Contents:

TLDR
Backstory
Drawbacks
Conclusion
Further reading

TLDR

Do this:

useEffect(
  function doSomethingAfterMounting(){ // <--- name me!
    // Your effect code 
  },
  []
);

Not this:

useEffect( 
  () => {
    /**
    * Your effect code
    * 
    * Note that this may or may not make
    * sense to you in 6 months time.
    */
  },
  []
);

What for?

This should provide 3 key benefits:

More clarity in the purpose of the effect, so other programmers would could easily tell what it's supposed to do just by reading the name;
If the effect throws an error, the function's name will show up in the stack trace, which should help debugging;
It should psychologically nudge the programmer into trying to make the effect do only one thing, and to split different tasks into several useEffects if necessary;

But before you even write a useEffect, consider if you even need one! There are plenty of situations where using props directly, or another hook like useMemo may make much more sense.

Backstory

useEffect can be a dangerous hook if you don't know what you're doing. Doubly so because it's usually opaque, with little indication of intent. I can't count how many times I've stared at a giant useEffect with no idea what it was written to do, or what its authors were thinking.

Once upon a time, I had to refactor a huge amount of logic for a form page. The original author had used useEffect in exactly the way that React doesn't recommend:

for updating state based on new props,
for caching,
for initializing field values,
for fetching data from an API,

... and other bad practices.

Even worse, he had often written all of that functionality into just one useEffect. Clearly, someone had never heard of useMemo 😄 There were several useEffects that stretched to 50 lines or more. Worse yet, there were often several of them in one file, each of which had its own setState calls that made the effects dependent on each other. One file had 12 such useEffects (which, side note, is almost certainly far, far too much code for any single component!)

And alas, that was not the end of it. It turned out that these bad practices were littered throughout the website, on code written by several programmers over many months.

The refactoring took a week, and while it's nice to have some stable work to do, I'm pretty sure both I and the client would've preferred if I had been doing something more productive.

It was around that time that I realized that not only is useEffect very easy to abuse, but that probably the worst part of it was how opaque it was. I was reading Bob Martin's Clean Code around this time, and noticed that this gentleman had some pretty nice tips!

Among other pearls of wisdom, he advised that:

all variables (and functions!) should have a clear, informative name:
functions should be small and short, aim to do one thing, have no side effects, have minimal or no repetition, and should have separated error handling
the best comment is no comment at all — your code should be self-explanatory in its intention through its concise logic and good naming

It was obvious to anyone with eyes that these principles were being woefully neglected in our client's codebase. So as I did my rewrites, I aimed to break up the enormous components with multiple useEffects into smaller, easily understandable parts. One file could turn into two, or five, or even ten. This meant having to figure out what all of those giant effects actually did — and to do that, I often pulled out big chunks of logic into their own, shorter functions. fetch() effects got their own functions, as did moveUI(), openModal(), reorderList() and many others. It turned out that many of these things didn't even need to be effects, and were thus eliminated.

But other things needed to stay as effects — things like autoClose() or setHasMounted(), and I wanted to find a way for these effect hooks to also have names. I aspired to code in a way so that even a person who didn't know how to program (or at least didn't know JavaScript) could see a name and instantly know the point of those few lines.

Comments wouldn't do, so I started out with the simple idea of using a memoized callback that would get automatically called whenever its dependencies changed:

// Idea #1: using a named `useCallback` to add clarity to `useEffect` (don't do this)

const doSomethingInAnEffect = useCallback(() => {
  // ... The effect code
}, [])

useEffect(() => doSomethingInAnEffect(), [doSomethingInAnEffect])

This definitely made things better. The effects finally had a meaning, even if they required this superfluous use of a memoized function.

It was at that point that one day it just struck me like a lightbulb: if all I need is a name, why not just use an old-fashioned named function instead of an arrow function? It seemed so simple, and why not? We never needed to use this inside the effect. And then we could avoid the new useCallback-hell that was festering. Could it really be so simple? I turned to Google, and as it turns out, I wasn't the first person with the idea (see the sources below). And if it's on Twitter, it must be a great idea, right? 😄

// Idea #2: just using an old-fashioned named function (DO do this)

useEffect(function doSomething() {
  // insert effect in here
}, []) // <-- notice: no extra dependencies! :)

As I tried to name my effects, I realized that their names weren't always so obvious — and usually this was because one effect was trying to do too many things. Once I realized this, it became natural to split things apart until each effect did just "one thing" or just got removed completely, and our code quickly got more clearer and simpler as a result. Who knew that naming things well would turn out to be a gift that keeps on giving?

And so, since then, I've always used named functions whenever I needed useEffect, and I advise everyone else to do so, too.

I don't blame my colleagues (whom I also call my friends) for writing messy useEffects. I've written plenty of unmaintainable code, too (haven't we all? 😄). Plus, back in those days, we didn't have awesome guidance articles like "You Might Not Need an Effect" (which I very much recommend you to read, by the way).

I'd also argue that we had inherited the psychological burden of only having one place for effects — namely, componentDidUpdate — from back in the days when we only had class components, and this may have nudged us into a "write a giant effect that handles everything"-state of mind that didn't always shake off naturally.

So what have we learned? I'd say that this experience taught me a few lessons:

Make sure to keep your functions as short as possible. Ideally, they should do one thing.
- This tip includes React components, too. If you need to render a giant form, it's probably better to split it up into different files for each section, and maybe even each field.
useEffect shouldn't be treated as a "go to solution", and can be dangerous if you don't know what you're doing. To avoid hurting your app's performance, consider if you can get by with just using the prop itself, or with using useMemo and useCallback.
And finally, while naming things may be one of the only two hard things in computer science, it is absolutely vital for the readability of your code.
- ...Which is why you absolutely must name all of your useEffects with named functions! 😉

Drawbacks

...Are there even any? 😄

So far, I haven't had any issues with this method, but have certainly felt the benefits.

One issue I can imagine occurring is pointer mismatches if you use the this keyword in your effect. Recall that arrow functions do not have their own this, but rather use their parent's this. That said, I have never, ever seen this being used in an effect, or in fact at all in a functional component... so I guess it's a non-issue? 😄

Conclusion

From what I can see, we should all switch to using named functions in useEffect, and should do so immediately. This should make our code cleaner and more reliable, and doesn't seem to have any drawbacks. Not only would a simple name let everyone know your intentions, but it should push you to write short, "do only one thing" effects, too.

What do you think? Let me know in the comments! 🙂 And thanks for reading!

How to "Git Copy": copying files while keeping git history

Deckstar — Tue, 16 Aug 2022 17:14:00 +0000

Have you ever wanted to break a long file into several smaller files, but worried about losing all the git blame history? Well, with the bash script in this post, you'll be able to split your file into as many files as you want, while still keeping the git history for every single line!

Table of Contents

Motivation
The script
Demo
Pros and cons of this method
Conclusion
Further reading

Motivation

Why would you ever want to copy a file like this? Basically, it's useful whenever you want to turn one file into multiple, but you still want to git history to stay visible, so people could track the evolution of this file. Not only that, but it ensures that you can also blame, or rather git blame, the right culprits for... interesting coding decisions 😉

I can think of two types of situations that I've encountered often:

Sometimes, a file grows too big to be easily legible and understandable. In those cases, it makes sense (and is even recommended) to split it up into smaller chunks.
- For me, this is a pretty regular thing with React components. It often happens that a small, seemingly simple component grows more and more complex, until there's too much unrelated logic in one place.
  - Example: a "page" component may start out with a few "sections", and the sections may have their own, complicated logic that's only got something to do with that section. This would be a prime candidate for splitting into multiple files.
Other times, you might want to turn one file into multiple. Perhaps because they have essentially the same functionality.
- Example, you may start out developing with one "config" file: config.js. But as your project gets closer to production-ready, you may realise that you want some different settings for "production" mode, and opt to have two files: config.development.js and config.production.js. Regularly copying the config file would make it look like all the production-mode changes happened all at once, whereas "Git copying" the old config would — you guessed it — let other developers track the evolution of the file.

Two use cases:

Splitting a large file into smaller files.

Creating a copy of a file that will always remain similar to the original.

The Script

Without further ado, here's the bash script that you can copy-paste and then use at your own convenience:



#!/bin/bash

# HOW TO USE:
#
# PSEUDO-CODE TEMPLATE:
# `
# bash ./gitCopy.bash {fileToCopy} {...newFiles}
# `
#
# EXAMPLE:
# Lets say you have a file called Section.tsx. Your section has grown very big
# and you want to split it into into three subsection files, while preserving
# the git history. Your plan is to copy the section file into three new files, in
# a new subfolder called "subsections".
#
# In that case, you would do something like this:
#
# `
# bash ./gitCopy.bash ./components/Section.tsx ./components/subsections/Section1.tsx ./components/subsections/Section2.tsx ./components/subsections/Section3.tsx
# `

GRAY='\033[1;30m'
GREEN='\033[0;32m'
LIGHT_BLUE='\033[1;34m'
RED='\033[0;31m'
NO_COLOR='\033[0m'


fail_and_quit () {
    echo -e "\n${RED}Failed to git copy.${NO_COLOR}"
    exit 0
}

if [ ! \( -f "$1" -a $# -ge 2 \) ]; then
    echo -e "\n${RED}Invalid inputs${NO_COLOR}"

    cat 1>&2 <<-EOF
    Usage: \$0 ORIGINAL copy1 [... copyN]

    Copy ORIGINAL, preserving history for git blame
    New history will have N+3 commits

    EOF
    exit 1
fi

ORIGINAL="$1";

# shift to $2 and start counting arguments from 2
shift;

# Messages
echo -e "\nWill copy ${GRAY}${ORIGINAL}${NO_COLOR} into ${LIGHT_BLUE}+$# files${NO_COLOR}:"

args=("$@")
for i in "${!args[@]}"; do
   echo -e "    $i. ${GRAY}${args[$i]}${NO_COLOR}"
done

echo -e "New history will have ${GREEN}+$(($# + 3)) commits ${NO_COLOR}\n"
# /Messages

NEWLINE=$'\n'
KEEP=$(mkdir -p $(dirname $1) && mktemp ./"$1".XXXXXXXX);
MESSAGE="Copied (with git history):$NEWLINE$NEWLINE$ORIGINAL$NEWLINE$NEWLINE — into: —$NEWLINE$NEWLINE$@"
SPLIT=""

# Remember current commit
ROOT=$(git rev-parse HEAD)

# Check for errors
if [ -z "$ORIGINAL" ]; then
    echo -e "\n${RED}ERROR:${NO_COLOR} Did not get ORIGINAL variable."
    fail_and_quit
elif [ -z "$KEEP" ]; then
    echo -e "\n${RED}ERROR:${NO_COLOR} Did not get KEEP variable."
    fail_and_quit
elif [ -z "$MESSAGE" ]; then
    echo -e "\n${RED}ERROR:${NO_COLOR} Did not get MESSAGE variable."
    fail_and_quit
fi


# Create branch where $2 has $ORIGINAL's history
for f in "$@"; do
    git reset --soft $ROOT
    git checkout $ROOT "$ORIGINAL"
    git mv -f "$ORIGINAL" "$f"
    git commit -n -m "* (create $f)$NEWLINE$NEWLINE$MESSAGE"
    SPLIT="$(git rev-parse HEAD) $SPLIT"
done

# Go back to initial branch and move $ORIGINAL out of the way
git reset --hard HEAD^
git mv "$ORIGINAL" -f "$KEEP"
git commit -n -m "* (keep $ORIGINAL)$NEWLINE$NEWLINE$MESSAGE"

# Merge $2's branch back into the original
git merge $SPLIT -m "* (merge)$NEWLINE$NEWLINE$MESSAGE"
git commit -a -n -m "* (merge)$NEWLINE$NEWLINE$MESSAGE"

# Move $ORIGINAL back where it was
git mv "$KEEP" "$ORIGINAL"
git commit -n -m "$MESSAGE"


# Report
echo -e "\nNew history: ${GRAY}$(git rev-parse --short $ROOT)..$(git rev-parse --short HEAD)${NO_COLOR}"
echo -e "\n${GREEN}Success!${NO_COLOR}\n"
exit 0

I usually title this thing gitCopy.bash. But in principle you could call it whatever you want.

Note as well that a lot of code in here is just UI fluff (in particular, most of the logic with the color- & text-related variables is completely unnecessary to achieve the core functionality). You don't really need all the colorful messages to show up in your terminal when running this script. But I just think that they're nice to have 😉

Demo

As you can see in the GIF below, this script should be pretty easy to use:

Demo of the "gitCopy" script.
Notice how both files show the same git blame information, using VS Code's GitLens extension.

Pros and cons of this method

Advantages:

Your git history gets kept in every file;
- You and others will be able to easily see the git blame records and track how the file changed and why
It's very easy to use — just copy a file path, then decide on one or more new ones, press enter and voilà!
If you change your mind, you can always revert the commits.

Disadvantages:

This method uses the "octopus-merge" strategy between the temporary branches, which means that your git history will no longer be a perfectly straight line.
- You probably don't care about this, but there do exist arguments for keeping git log --graph linear, as well as counterarguments against it. Personally, I've done both, but I don't really have much of an opinion on this.
This method creates a lot of commits, which can be a bit frustrating.
- How many commits? Well, it's N + 3 for every file that you want to copy, where N is the number of copies that you want to make.
  - So, for example, let's say that you want to copy two different files, with 1 copy of the first file and 3 copies of the second file. For instance, maybe you want to copy config.js into config.production.js, and you want to copy Component.tsx into Subcomponent1.tsx, Subcomponent2.tsx and Subcomponent3.tsx. That would mean 1 + 3 = 4 commits for the config file, and 3 + 3 = 6 commits for the Component. Plus at least 1 more commit if you want to actually edit your new files, bringing the total up to at least 11. That's a lot of commits!
- The general formula here is:
  $∑Cf=(N1+3)+(N2+3)...+(Nf+3)\sum C_f = (N_1 + 3) + (N_2 + 3) ... + (N_f + 3)$
  
  where:
  - $∑Cf\sum C_f$ is the sum total of the number of commits that you will create by copying all the $f$ files, and
  - $N_i$ is the number of copies that you want to create of each file $i$ .
- We can see that the minimum number of commits here is 4 (when copying one file one time).
- This large number of commits may start to feel overwhelming when reading commit histories, or when reading through pull requests.

Conclusion

So that's "git copying" in a nutshell.

We've seen that this method is an easy and flexible way to keep git history while copying files. However, we've also seen that it produces a lot of commits, and requires an "octopus merge" strategy, which may not be ideal in some teams.

As always with coding tools, you will have to decide for yourself when and whether to use this new trick that I have just presented to you 🙂

Good luck and happy coding!

Gatsby JS — How to solve FOUC when using tss-react and Material UI v5

Deckstar — Sat, 29 Jan 2022 17:01:36 +0000

Material UI v5 brought some amazing updates, but switching from JSS to Emotion had an arguably nasty side-effect: it was no longer as straightforward to group your component styles in classes. Fortunately, a fantastic library emerged that allowed developers to not only reduce the extreme pain from migrating all their classes from v4's makeStyles to emotion, but to also to continue to writing classes in practically the same syntax, with wonderful TS type-safety. This library was tss-react, and it was one of my favorite open source discoveries of 2021.

Unfortunately, however, tss-react and material-ui don't exactly work "out of the box" when it comes to Gatsby JS. Gatsby is a fantastic framework for generating static websites with React code. Static websites are great because they load fast, can be largely cached in a visitor's browser and have great Search Engine Optimization (SEO).

The trouble I was having was that my production website was displaying what is known as a "flash of unseen content", or FOUC. Material UI users have known about this problem for a long time — in fact, there even exists a popular plugin for solving this exact issue.

But because tss-react and material-ui do not share the same emotion cache, then simply adding gatsby-plugin-material-ui doesn't work. A more custom solution is needed.

This post is about how I solved the FOUC-problem in my Gatsby JS website after migrating to Material UI v5 with tss-react.

TLDR:

copy paste the two files below
make sure your <CacheProvider /> component imports your emotion cache from the new place
remove gatsby-plugin-material-ui from your gatsby-node.js file if you had it

Showcase:

Here's a sample implementation. Feel free to copy from it! 😉

This little example project should be helpful if you get stuck 🙂

Explained

Step 1: make an emotion `cache` that can be used both on the client and the server

This is the cache that will be used by emotion to make your Material UI styles.

Unfortunately, you probably want this file to be a vanilla JS file, without TypeScript. This is because the gatsby-srr.js file that we will have to create later must be a vanilla JS file, and cannot parse uncompiled TypeScript. But don't worry — you can still get some TS typing intellisense just by adding a few JSDoc comments! ;)

// ./src/theme/cache.js

import createCache from '@emotion/cache';

/** @type {import('@emotion/cache').Options} */
export const cacheProps = {
    key: 'mui',
    prepend: true,
};

/** @type {import("@emotion/cache").EmotionCache | undefined} */
export let muiCache;

export const makeMuiCache = () => {
    if (!muiCache) {
    muiCache = createCache(cacheProps);
    }

    return muiCache;
};

Don't forget to use this cache for your <CacheProvider /> that wraps your Material UI <ThemeProvider />:

// example

import { makeMuiCache } from './cache';

const muiCache = makeMuiCache();

const ThemeWrapper = (props: { children: ReactNode }) => {
  const { children } = props;

  return (
    <CacheProvider
        value={muiCache} // <-- use the new cache here
    >
      <ThemeProvider theme={yourTheme}>
        {children}
      </ThemeProvider>
    </CacheProvider>
  );
};

Step 2: create a `gatsby-srr.js` file, and add the generated styles to the server-side `<head>`-components

You'll probably want it to look something like this:

// ./gatsby-srr.js

import { CacheProvider } from '@emotion/react';
import createEmotionServer from '@emotion/server/create-instance';
import React from 'react';
import { renderToString } from 'react-dom/server';
import { getTssDefaultEmotionCache } from 'tss-react';

import { makeMuiCache } from './src/theme/cache';

/** @param {import('gatsby').ReplaceRendererArgs} args */
export const replaceRenderer = (args) => {
  const { bodyComponent, replaceBodyHTMLString, setHeadComponents } = args;

  const muiCache = makeMuiCache();
  const { extractCriticalToChunks } = createEmotionServer(muiCache);

  const emotionStyles = extractCriticalToChunks(
    renderToString(
      <CacheProvider value={muiCache}>{bodyComponent}</CacheProvider>
    )
  );

  const muiStyleTags = emotionStyles.styles.map((style) => {
    const { css, key, ids } = style || {};
    return (
      <style
        key={key}
        data-emotion={`${key} ${ids.join(` `)}`}
        dangerouslySetInnerHTML={{ __html: css }}
      />
    );
  });

  const tssCache = getTssDefaultEmotionCache();
  const { extractCritical } = createEmotionServer(tssCache);
  const { css, ids } = extractCritical(renderToString(bodyComponent));

  const tssStyleTag = (
    <style
      key="tss-styles"
      data-emotion={`css ${ids.join(' ')}`}
      dangerouslySetInnerHTML={{ __html: css }}
    />
  );

  const combinedStyleTags = [...muiStyleTags, tssStyleTag];
  setHeadComponents(combinedStyleTags);

  // render the result from `extractCritical`
  replaceBodyHTMLString(emotionStyles.html);
};

The idea here is that we are exporting a replaceRenderer function that Gatsby will use internally to render your page when generating it (see Gatsby the docs here).

The first part of this function is copy-pasted straight out of gatsby-plugin-material-ui . However, where the plugin has to use clever file-system tricks to get access to your emotion cache, we can just import our own cache directly! With our cache available from our makeMuiCache function, we can easily generate our muiStyleTags using emotions server-side helpers.

tss-react is also very helpful — you can easily access its emotion cache using the getTssDefaultEmotionCache helper. As Nicholas Tsim documents in his blog post, it is then very easy to create the style tags for any emotion cache — much like how we did earlier for Material UI, we create another emotion server, extract the critical CSS and map it convert it into a JSX style tag.

We then combine all our style tags into one array, and use the Gatsby setHeadComponents helper so that all of them would be included on our page. And finally, we call replacebodyhtml with the generated HTML-string.

Step 3: Remove `gatsby-plugin-material-ui` from `gatsby-config.js` to avoid conflicts.

Self-explanatory. If you were using the plugin before, then open your Gatsby config and delete it:

// ./gatsby-config.js

module.exports = {
 /* Your site config here */
 plugins: [
   `gatsby-plugin-material-ui`, // <-- delete me!
    // ...rest plugins
 ],
 // ...rest config
};

Don't forget to run yarn remove gatsby-plugin-material-ui (or the same command with whatever package manager you're using), since the package is no longer needed.

That's it! Your Gatsby site should now load without any flash of unseen content, and you can continue to use the spectacular Material UI library in all its v5 glory, together with tss-react, of course ;)

Good luck!

TypeScript & VS Code tricks for beginners: 10 things I wish I knew when starting out

Deckstar — Sat, 29 Jan 2022 14:24:04 +0000

TypeScript is supposed to make your development life easier, but I vividly recall my earliest memories of TypeScript involving a lot of cursing, confusion about errors, and wondering why anyone would ever waste time writing out all types and how interfaces were any better than PropTypes. I used to write type definitions for hours and complain that I definitely didn't feel my productivity getting any better.

My point of view was understandable: I was a total noob (or, in polite parlance, a beginner). And everything is hard and demoralizing when you're a noob. Today, I love TypeScript and usually find projects written in plain old JavaScript to be injurious to my mental health. Looking back, I probably hated TypeScript early on because of all the hurdles I had to go through until I could feel its benefits.

If you've recently joined a TypeScript project, or are thinking of learning it for your own work, then I hope that my little blog post will help make your transition a little easier. These are probably the things that I wish I had known when starting out with TypeScript, but nobody showed me.

Without further ado, here's a list of of cool & useful tricks that make your life way easier when working with TypeScript.

1. Use `Ctrl + Space` to see all the available props of a component, or all the available keys of an object.

Don't be a noob. Switching between files or Googling documentation is for people who've got nothing better to do with their time ;) It's much easier to see all available variables immediately, in a drop down menu right under your code.

Much more helpful than having 20 Chrome tabs open, right?

If you're dealing with popular libraries, 9 times out of 10 the variable name will be descriptive enough for you to know what it's supposed to be used for. If you're confused by the function of a variable in your own code (or your colleague's code!), then you'll see immediately which variables may need to be renamed, or even refactored.

2. Use `as` when you know the type of your variable better than your linter.

It happens to all of us. You try to pass in a variable that may be a string, TypeScript screams at you that it may also be undefined, which is unacceptable. But you know for a fact that this variable will never be undefined where you're using it, because you controlled for that ages ago. And perhaps you don't want to write a slew of if-statements.

The easy solution is to just use as:



interface Props { word?: string }

// let's say that we definitely passed in
// a word to props in another file
const { word } = props;

const logWord = (word: string) => {
    console.log(`The word is: ${word}`)
}

// woops, Typescript error! word is required!
logWord(word);

// no error
logWord(word as string)

The example above may make it look like using as would have to be bad practice. Why make the prop optional if you need to use it later? True, but that's only because I couldn't think of a better example. In fact, this issue pops up quite often, especially when working with 3rd party libraries.

Sooner or later, you will probably encounter a situation in which it's useful to have as in your mental toolkit, and in which using as solves the problem 5 times faster than if you insisted on making your code logic absolutely foolproof and TypeScript-friendly.

Using as is called type-assertion, and it can also be done by putting the type in brackets before the variable:



// type assertion with 'as'
const wordLength = (word as string).length;

// type assertion with brackets
const wordLength = (<string>word).length

3. Use `Pick` and `Omit` to efficiently create typed sub-components

Writing interfaces for every sub-component is repeating yourself. And as every clever software book will tell you, the first rule of programming is Don't Repeat Yourself!

Try this:




interface PersonProps {
    name: string,
    age: number,
    imageUrl: string,
    location: string,
    description: string,
}


const PersonContainer = (props: PersonProps) => {
    const { name, age, imageUrl, location, description } = props;

    return (
        <div>
            <img src={imageUrl} />
            <h2>{name}, {age}</h2>
            <h3>{location}</h3>
            <p>{description}</p>
        </div>
    );
}   

/**
* Let's say you only want to display some of the 
* person's info in a summary card, which can be 
* pressed for details
*/
type CardProps = Pick<PersonProps, 'name' | 'age' | 'imageUrl' >;

const PotentialRomanticInterest = (props: CardProps) => {
    const { name, age, imageUrl } = props;

    return (
        <div>
            <img src={imageUrl} />
            <h2>{name}, {age}</h2>
        </div>
    );
}

/**
* What if you've got a lot of props, but you want
* to leave some out?
* 
* You can make a new type/interface with all 
* the same props as your other interface (here, 
* PersonProps), but with some omitted.
*/
type BlindDateProfile = Omit<PersonProps, 'imageUrl'>;

const PotentialRomanticInterest = (props: BlindDateProfile) => {
    const { name, age, location, description } = props;

    return (
        <div>
            <img src={'images/incognito-image.png'} />
            <h2>{name}, {age}</h2>
            <h3>{location}</h3>
            <p>{description}</p>
        </div>
    );
}

There's more selectors where that came from. Pick and Omit may be the simplest and most common, but there are plenty of other useful ones, like Record, Partial, or Parameters. If you want to dive deeper, check out TypeScript's Utility types documentation.

4. `Cmd + click` on things to explore what they expect.

All right, this isn't really a TypeScript trick. But a typical TS developer probably spends a lot of time command-clicking his various 3rd party library functions. With 3rd party libraries, I often find it much easier to figure out what various parameters of a function are for by just clicking around the TypeScript definitions, instead of reading the documentation.

Cmd + click should show you what the type is all about. Often you don't even have to leave your open tab, but you can if you want to! Just click the popup's header to explore the full file.

Don't be afraid of type definition files. They're there for the linter, but they're also there for you, if you'll grant them your attention.

Another trick: say you're using a 3rd party library function, and it takes in a complicated parameters object. Well, you can often simply import the parameter object's type, define your variable to be the same type, and get friendly warnings until you fill out every missing property. (And if the arguments' types are not exported, you can always use the built-in Parameters type to get them yourself).



import { doSomething } from 'cool-library';

// These types are often exported, but if not, don't fear! `Parameters<>` can usually help you out
type DoSomethingArgs = Parameters<typeof doSomething> // <-- an array;

type FirstArg = DoSomethingArgs[0] // <-- the first argument;

const input: FirstArg = { complicatedKey: 'complicatedValue' } // <-- now this object will have autocomplete, and red warning squiggles :)

doSomething(input);

This tip works even better when you couple it with the auto-complete trick from tip #1, and the auto-import trick from tip #6.

5. If you have a list of options, try writing your own type instead of using a generic `string` or `number` type

Let's say your passing in some names to your function:



// okay
interface Props {
    name: string
}

This will work. But what if you know that your name should be one of three, and nothing else? Perhaps you want your TypeScript error to warn you if you pass in and unacceptable name.



// better
type StarterPokemon = 'Bulbasaur' | 'Charmander' | 'Squirtle';

interface Props {
    name: StarterPokemon
}

This way, the name prop can only be one of the three strings specified in the StarterPokemon type.

Writing your own stricter types is useful because you might forget later which options you have available, or another developer might take over the project and not know which Pokémon are available as starters and break the rule somewhere. Having a strict list of options prevents such a thing from occurring:



const chooseStarterPokemon = (name: StarterPokemon) => {
    setPokemon(name);
}

chooseStarterPokemon('Pikachu'); // error!
// Type '"Pikachu"' is not assignable to type 'StarterPokemon'.

Another bonus is that you will later be able to mouse over the StarterPokemon type wherever you use it to get a reminder of what were the options. You can even add comments:



type StarterPokemon = 'Bulbasaur' // grass
    | 'Charmander' // fire
    | 'Squirtle' // water
;

/** 
* Make sure to add that finaly semi-colon,
* or else the mouse-over info will stop after
* 'Squirtle' and won't show the final comment
*/

As a general tip, you might find it helpful to try to write your types so that you could later autocomplete your way through the whole project by using the control + space tip from #1. To borrow from Einstein, try to make your types as restrictive as possible, but no more so than needed.

6. Auto-import all missing variables with `Cmd + .`

Many VS Code users know that you can auto-import individual things by just typing out the first few characters and then selecting the first VS Code dropdown suggestion. But you can also import all missing variables that are already declared in the file.

If you're using TypeScript, all you have to do is click on an undefined variable/function/type and press Cmd + .. VS Code should be able to suggest to you some options for where to import it from. If you've got several undefined items, it should even offer to 'Add all missing imports'.

Why import stuff manually when VS code can do it all in one click?

This trick works for both 3rd party libraries and your own code, as long as everything is exported correctly and written in TypeScript. And it nearly always works exactly as expected.

In fact, most of the time I don't even check that the imports came from the right place after doing this. Also, you usually learn pretty quickly which things VS Code tends to import from the wrong places. For example, for me it often imports the Lodash 'get' function from the wrong library, so that is one of the few things I import manually.

7. Get optional props the smart way using a `?` operator ("Optional chaining")

Have you ever had to do this?



interface Item {
    prop?: {
        subprop?: string;
    }
}

const value = item && item.prop && item.prop.subprop || 'default';

Seeing several && like that makes the code hard to understand at first glance. Wouldn't it be nice if you could tell TypeScript to get that deeply nested value, only if item and prop actually exist as well?

Well, it turns out there is! Try this:



const value = item?.prop?.subprop || 'default';

The ? operator is a sneaky way to tell TypeScript (and newer versions of JavaScript) to only go deeper if the higher-up key exists. In other words, only look for prop if item is defined and an is object, and only look for subprop if prop is defined and is an object.

The official name for this syntax is "optional chaining". It's easy and intuitive, and it'll probably save you a few lines of code.

8. Work with old JS files by enabling `allowJs` in `tsconfig.json`

This is a quick and easy tip that might not be obvious for the beginners out there.

You can easily mix TypeScript and plain old JavaScript files. All you have to do is make a little edit in your tsconfig.json file:



{
  "compilerOptions": {
    "allowJs": true,
    // ... other options
  }
}

Now your TS compiler won't block your development. But you'll probably have to use a lot of any types for any JS files you import.

9. Automatically refactor your typed objects into a named interface

Let's say you have a function that takes in a long object:



renderFAQItem = (item: { faqQuestion?: string, faqAnswer?: string }) => {
    return (
        // component
    )
}

The { faqQuestion?: string, faqAnswer?: string } definition makes this line of code too long. Worse, it also makes your code a bit less maintainable.

Thankfully VS Code lets you turn it into a named interface at the click of a button:

In one click, VS code can make a named interface for you at the top of the file.

That light bulb is actually quite handy, if you know how to use it. It can also refactor variables into constants, lines into functions, generate get/set methods for classes, and more. There's a whole section on refactoring in the VS Code TypeScript documentation.

10. Combine TypeScript with JSDoc for awesome documentation right in your VS Code.

JSDoc is a pretty awesome skill to have for any JavaScript project. And fortunately it can be combined with type definitions as well.

VS Code automatically recognizes JSDoc comments when you use a multiline comment that starts with two asterisks: /** Insert content here */. You can also add some keywords (marked by @-symbols) for even more intellisense. And the great thing about JSDoc comments is that, unlike regular // comments, the things you write down will be visible on-hover, anywhere in your project!

Add JSDoc comments to your interface properties, and you will be able to see a description for that property when hovering over it. This will work even if you use this component in another file!

This is a great addition to your codebase when working in teams, when you want to give other developers a clearer explanation of what your code is supposed to do, and how it's supposed to be used.

Many of the best libraries, such as Material UI, annotate their TS definitions with JSDoc comments, so you could see the documentation for that property right in your VSCode tab, without opening any links. Often they even include the links anyway, in case you're hungry for more info :)

Many of the best libraries heavily annotate their types with JSDoc comments, and often include links to more complete documentation.

These are the main things I wish I knew when starting out with TypeScript.

Keep in mind that TypeScript was created to help you, not to annoy you. As a rule of thumb, I try to write my TS in such a way so that I would later be able to autocomplete my code as much as possible.

I hope these tips could be helpful for you. Good luck, and have fun!

Creating side effects with the onChange callback in Redux Form (TypeScript included!)

Deckstar — Fri, 16 Oct 2020 19:44:42 +0000

Redux Form is a common way to handle forms in React. But as with any large, complicated library, there are always a couple of features that may not seem obvious at first. In this article, we will take a look at how to use the onChange callback in the reduxForm({}) config.

The use case

This function is useful when you want to introduce some side effects to your forms. This side effect could be anything: maybe you want to fetch data for a dropdown. Or maybe you just want some values to change automatically.

In my case, I was developing a form for granting participation credits to students for showing up to experiments. Say you’re a professor: a student shows up to your experiment, so you mark him as “participated” and grant him, for example, 5 credits for his performance.

A simple credit granting form. You’re a professor running an experiment, and your university’s budget department demands that you submit a form for each student saying how they participated, and how many credits they should get.

Here’s where the onChange comes in: another student didn’t show up, with neither an excuse nor a warning. So you mark him as a “no-show”. If a student is a no-show, you probably want him to get zero credits, right?

Now, wouldn’t it be nice if your Redux Form automatically chose zero credits for the student if you deemed them a “no-show”? That certainly sounds like better UX to me. But beyond UX, you may very well need such functionality in a case like this, where granting credit to a non-participant doesn’t make any sense, and probably breaks the rules of your university’s budget allocation.

Wouldn’t it be nice if selecting the big red X category automatically set the credits to zero?

Of course, you could just add some logic in your component, or in your Redux action, or in your backend. But it’s probably more convenient to have a simple solution that immediately solves the need for visual logic, Redux state logic, and the eventual form submission logic as well.

Enter the onChange callback: a simple solution to immediately handle the change according to your rules, leaving the rest of your component, reducers and backend none the wiser that a participant could’ve theoretically been in the big red X category and still gotten some points.

How to implement

Let’s say our form component looks like this:

import React, { Component } from 'react';
import { reduxForm } from 'redux-form';
// etc. sub-component imports

class ParticipantModal extends Component {
  render() {
    return (
      <Container>
        <Header />
        <ScrollView>
          <CreditStatusButtons />
          <CreditCount />
        </ScrollView>
        <SaveButton />
      </Container>
    )
  }
}

const ParticipantForm = reduxForm({
  form: "participantForm",
})(ParticipantModal)

export default ParticipantForm;

We start out with a simple modal with some sub components (the code for which is not important for this illustration). The way Redux Form works is that our ParticipantModal component automatically gets access to an auto-generated object called “form”, which lives in our Redux state and includes pretty much everything needed to make a nice, reactive form. Redux Form takes care of most things, but for our “set credits to zero automatically” we will need to write a little custom logic.

We start out by writing out what we actually want to happen and when. So we write a handleOnFormChange function. Let’s say that we have two variables in this form: the studentStatus (participated, excused, no-show, etc.) and the creditValue (the number of credits to grant).

We can start out by adding an “onChange” field into our reduxForm config on the bottom. Then we declare a function that we want to be called when a form value (any value) changes. The config will automatically pass in four variables into this function, all of which we will need: newValues, dispatch, props and previousValues (in that order!).

const handleOnFormChange = (newValues, dispatch, props, previousValues) => {
  const { studentStatus: newStudentStatus } = newValues;
  const {
    studentStatus: prevStudentStatus,
    creditValue: prevCreditValue,
  } = previousValues;
  const { change: changeField } = props;

  /*
    if the user sets the participant as a "no show",
    then their credit value should be automatically set to zero
  */
  if (
    newStudentStatus !== prevStudentStatus && // to prevent dispatching every time
    newStudentStatus === 'noShow' &&
    prevCreditValue > 0
  ) {
    dispatch(changeField('creditValue', 0));
  }
};

const ParticipantForm = reduxForm({
  form: 'participantForm',
  onChange: handleOnFormChange, // <-- add this
})(ParticipantModal);

newValues and previousValues are self-explanatory: they are the form values that were stored in the Redux state before and after the user changed something. Dispatch is the Redux dispatch function that is used with every Redux action & reducer. And props are the properties that reduxForm passes into your component, from which we destructure the change function. (I also rename it to changeField, to make it more obvious.) This function takes in the name of the value that we want to change (in our case, the creditValue), and the new value we want to set (zero). Make sure to check previous values so the dispatch is called only when you change the status!

And just like that, we’re done! With this little bit of logic, we have achieved the functionality that we wanted.

Adding TypeScript

This particular project required TypeScript. Though lately I’ve been becoming more and more of a TypeScript fan, one thing I never liked was spending a lot of time looking for interfaces / types for 3rd party libraries.

Well I’ve got you covered. Simply copy paste the type imports & uses below, and your linter should get rid of quite a few red lines. You’re going to need Dispatch from ‘react’ and DecoratedFormProps from ‘redux-form’.

import React, { Component, Dispatch } from 'react';
import { reduxForm, DecoratedFormProps } from 'redux-form';

You’ll also need to declare your own interface for the values in your form.

interface YourForm {
  studentStatus: string;
  creditValue: number;
}

Add them to your “handleOnFormChange” function.

With that, our final result should look something like this:

import React, { Component, Dispatch } from 'react';
import { reduxForm, DecoratedFormProps } from 'redux-form';
// etc. other component imports

interface YourForm {
  studentStatus: string;
  creditValue: number;
}

class ParticipantModal extends Component {
  render() {
    return (
      <Container>
        <Header />
        <ScrollView>
          <CreditStatusButtons />
          <CreditCount />
        </ScrollView>
        <SaveButton />
      </Container>
    );
  }
}

const handleOnFormChange = (
  newValues: YourForm,
  dispatch: Dispatch<any>,
  props: DecoratedFormProps<YourForm, {}, string>,
  previousValues: YourForm
) => {
  const { studentStatus: newStudentStatus } = newValues;
  const {
    studentStatus: prevStudentStatus,
    creditValue: prevCreditValue,
  } = previousValues;
  const { change: changeField } = props;

  /*
    if the user sets the participant as a "no show",
    then their credit value should be automatically set to zero
  */
  if (
    newStudentStatus !== prevStudentStatus && // to prevent dispatching every time
    newStudentStatus === 'noShow' &&
    prevCreditValue > 0
  ) {
    dispatch(changeField('creditValue', 0));
  }
};

const ParticipantForm = reduxForm({
  form: 'participantForm',
  onChange: handleOnFormChange,
})(ParticipantModal);

export default ParticipantForm;

And that’s it! 🙂

P.S.: “But I’m still getting a TypeScript linter error?”

At the end of this, you may see a linter error at the bottom. Specifically, the ParticipantModal component that gets passed into reduxForm will have a warning that says something like Argument of type 'typeof ParticipantModal' is not assignable to parameter of type 'ComponentType<InjectedFormProps<FormValues, {}, string>>'.

I’ll be honest, I have no idea how to fix this linter error. I’ve tried and I’ve Googled it a dozen times, to no avail. I’ve just accepted that all my Redux Form components will have one TypeScript error on the bottom.

If you find a solution, would you please kindly share it with me? As a token of my gratitude, I promise I’ll send you the best picture of a cookie I can find 😇

Thanks for reading!

Edit on 2 December 2020: TypeScript linter error solved

Here's how to solve that TypeScript error above. Change the following lines as follows:

// import { reduxForm, DecoratedFormProps } from 'redux-form'; // old
import { reduxForm, DecoratedFormProps, InjectedFormProps } from 'redux-form';

// ...

// class ParticipantModal extends Component { // old
class ParticipantModal extends Component<Props, InjectedFormValues<YourForm, Props>> {
// Props is the interface with the normal, non-form-related props of this component 

// ...

  // props: DecoratedFormProps<YourForm, {}, string>, // old
  props: DecoratedFormProps<YourForm, Props, string>, 

// ...

// const ParticipantForm = reduxForm({ // old
const ParticipantForm = reduxForm<YourForm, Props>({

Other lines shouldn't need any changes.

If your component has no Props, you can replace the "Props" interface with an empty object, e.g. class ParticipantModal extends Component<{}, InjectedFormValues<YourForm, {}>>.

Thanks again for reading, and good luck with your forms!

Forem: Deckstar

React Pro Tip #2 — How to Type `this.props` to Include `defaultProps`

TLDR

Case 1: Simple

Case 2: Slightly more complicated

Explained

Drawbacks

Conclusion

Further reading:

React Pro Tip #1 — Name your `useEffect`!

TLDR

Do this:

Not this:

What for?

Backstory

Drawbacks

Conclusion

Further reading:

How to "Git Copy": copying files while keeping git history

Table of Contents

Motivation

Two use cases:

The Script

Demo

Pros and cons of this method

Advantages:

Disadvantages:

Conclusion

Further reading

Gatsby JS — How to solve FOUC when using tss-react and Material UI v5

TLDR:

Showcase:

Explained

Step 1: make an emotion cache that can be used both on the client and the server

Step 2: create a gatsby-srr.js file, and add the generated styles to the server-side <head>-components

Step 3: Remove gatsby-plugin-material-ui from gatsby-config.js to avoid conflicts.

TypeScript & VS Code tricks for beginners: 10 things I wish I knew when starting out

1. Use Ctrl + Space to see all the available props of a component, or all the available keys of an object.

2. Use as when you know the type of your variable better than your linter.

3. Use Pick and Omit to efficiently create typed sub-components

4. Cmd + click on things to explore what they expect.

5. If you have a list of options, try writing your own type instead of using a generic string or number type

6. Auto-import all missing variables with Cmd + .

7. Get optional props the smart way using a ? operator ("Optional chaining")

8. Work with old JS files by enabling allowJs in tsconfig.json

9. Automatically refactor your typed objects into a named interface

10. Combine TypeScript with JSDoc for awesome documentation right in your VS Code.

Creating side effects with the onChange callback in Redux Form (TypeScript included!)

The use case

How to implement

Adding TypeScript

P.S.: “But I’m still getting a TypeScript linter error?”

Edit on 2 December 2020: TypeScript linter error solved

Step 1: make an emotion `cache` that can be used both on the client and the server

Step 2: create a `gatsby-srr.js` file, and add the generated styles to the server-side `<head>`-components

Step 3: Remove `gatsby-plugin-material-ui` from `gatsby-config.js` to avoid conflicts.

1. Use `Ctrl + Space` to see all the available props of a component, or all the available keys of an object.

2. Use `as` when you know the type of your variable better than your linter.

3. Use `Pick` and `Omit` to efficiently create typed sub-components

4. `Cmd + click` on things to explore what they expect.

5. If you have a list of options, try writing your own type instead of using a generic `string` or `number` type

6. Auto-import all missing variables with `Cmd + .`

7. Get optional props the smart way using a `?` operator ("Optional chaining")

8. Work with old JS files by enabling `allowJs` in `tsconfig.json`