Dave Ceddia

Delete Git Branches That Have Been Merged

2022-08-04T15:05:07+00:00

Got a lot of old git branches hanging around? Here’s a little script that will delete the branches that have been marged.

It’ll print out the branches to be deleted, and then prompt for whether you want to delete them.

If your top-level branch isn’t called “main”, customize the MAIN variable to match.

Script: Delete old git branches

#!/bin/bash

# Change this to match the name of your top level branch
MAIN=main

echo "These branches have been merged into $MAIN and will be deleted:"
echo
git branch --merged $MAIN | grep -v "^\* $MAIN"
echo

read -p "Continue? [y/N] " -n 1 -r
echo
if [[ ! $REPLY =~ ^[Yy]$ ]]
then
  exit 1
fi

git branch --merged $MAIN | grep -v "^\* $MAIN" | xargs -n 1 -r git branch -d

Copy/paste this into a file in your repo or elsewhere (like git-cleanup.sh) and make it executable with chmod +x git-cleanup.sh

Bonus: if you want this file to be ignored, but you don’t want to clutter up the shared .gitignore file with your own local scripts, you can edit .git/info/exclude and list this file there. That file works as a local gitignore.

Delete Git Branches That Have Been Merged was originally published by Dave Ceddia at Dave Ceddia on August 04, 2022.

How to Run SketchUp Make 2017 on an M1 Mac with macOS Monterey

2022-07-14T00:22:58+00:00

I tried to run the old standalone version of SketchUp Make 2017 on my modern M1 Mac running macOS Monterey 12.4 recently. At first it went pretty badly, crashing on startup with the error “SketchUp quit unexpectedly.”

But I got it working!

Here’s how to get it running by removing the code signature.

The main clue came when I tried running it from the Terminal, to see if it would show a more useful error. I got the same popup error, but also this:

rosetta error: /var/db/blahblah/SketchUp.aot: attachment of code signature supplement failed: 1
zsh: trace trap  /Applications/SketchUp\ 2017/SketchUp.app/Contents/MacOS/SketchUp

“attachment of code signature supplement failed”, eh?

We’ll just remove that code signature, then… from absolutely everything inside the app.

To do this, launch the Terminal app (from under Applications > Utilities), copy all of this text, paste it into the terminal window, and press Enter.

codesign --remove-signature --deep /Applications/SketchUp\ 2017/SketchUp.app
codesign --remove-signature --deep /Applications/SketchUp\ 2017/SketchUp.app/Contents/Frameworks/*.framework
codesign --remove-signature --deep /Applications/SketchUp\ 2017/SketchUp.app/Contents/Frameworks/*.dylib
codesign --remove-signature --deep /Applications/SketchUp\ 2017/SketchUp.app/Contents/PlugIns/*.plugin

(if SketchUp is installed in a different folder on your machine, you’ll have to change these paths to match)

With all that done, I was able to launch SketchUp under Rosetta!

My guess is that the code signing certificate format changed in one of the newer macOS versions. I’m not sure — but I’m glad to have SketchUp working again!

One (maybe?) important detail is that I have System Integrity Protection (SIP) disabled on my machine. I’m not sure if this matters. (I didn’t test SketchUp with SIP enabled). You can google for how to disable SIP if removing the code signature isn’t enough to get it working.

How to Run SketchUp Make 2017 on an M1 Mac with macOS Monterey was originally published by Dave Ceddia at Dave Ceddia on July 14, 2022.

Installing a Code Signing Cert from Sectigo (to sign an Electron app on Windows)

2022-03-11T21:28:11+00:00

So, you bought a code signing certificate for your Electron app. One step closer to being able to release your app on Windows. Congrats!

Finally, 3 weeks later, after a few phone calls, Sectigo issued the certificate. Woohoo! The email went to spam and you didn’t see it for 3 days, but hey, we’re making progress.

In their email, they say in big red letters that you must use Internet Explorer to download it (or an ancient version of Firefox).

And then you try that, and it fails. Because when you ordered the cert, you didn’t use the on-page tool that required using an ancient web browser. You used OpenSSL to create your certificate signing request (CSR) and private key.

So you call them, and they tell you to call your reseller. Wait – SectigoStore is not actually owned by Sectigo? Haha nope, different company.

But no matter – their lovely live chat people point you at this page of instructions for converting the code signing cert to a PFX, involving some sort of tool that may or may not be linked from that page.

So now you’re stuck. Well, I was stuck here too. Here’s what to do to download the code signing certificate to a PFX file that can actually be used to sign some code.

Download the certificate using the link in your email, but don’t use Internet Explorer. Use Chrome or Edge instead. You’ll get a user.crt file.

IE (and presumably, ancient Firefox, I didn’t try) will try to install the certificate into your system using a private key that’s already installed. But you didn’t use IE in the first place, so you don’t have a private key installed, which is why that failed.

Convert the user.crt from the binary DER format that it came with, into a PEM format that OpenSSL can work with.

openssl x509 -inform der -in user.crt -out user.pem

If your user.crt file is already in PEM format, you can skip this step. PEM format is plain text and starts with ------ BEGIN BLAH BLAH ------.

Combine the PEM certificate with the private key and the Sectigo root/intermediate CA cert into one big PFX file. Get the Sectigo CA cert at the very bottom of this page that the helpful SectigoStore chat person gave you.

openssl pkcs12 -export -in user.pem -certfile SectigoRSACodeSigningCA.crt -inkey privatekey.key -out code-signing-cert.pfx

It’ll ask you for a password. Make sure to save that somewhere. You’ll need it to do the actual code signing.

If OpenSSL hangs for you (like it did for me, using a Git Bash shell on Windows 10), prepend the commands with winpty.

And now, if you haven’t forgotten your private key password, you should be all set! The code-signing-cert.pfx

From here, since I’m using electron-builder, I made a .env file in the root of the project with 2 keys:

CSC_LINK=file:///Users/You/Projects/your-app/code-signing-cert.pfx
CSC_KEY_PASSWORD=the-password-you-hopefully-remember-from-2-paragraphs-ago

Run the build, and hopefully code signing will work! Awesome. Time to get back to real work.

Installing a Code Signing Cert from Sectigo (to sign an Electron app on Windows) was originally published by Dave Ceddia at Dave Ceddia on March 11, 2022.

Implementing A Svelte Store In Rust

2022-02-13T14:58:10+00:00

We’re going to build a Svelte store, written in Rust, and run it in an Electron app.

This spun out of a video editor which I originally built in Swift. It turns out people on Windows want to edit videos too, so now I’m rewriting it with Rust, Electron, and Svelte with an eye for performance.

Rust is a systems programming language, akin to C or C++, but safer. It’s known for being super fast.

Electron is a framework for building cross-platform desktop apps with HTML, CSS, and JavaScript. It’s known for being kinda slow and bloaty. But there’s an ace up its sleeve: Electron apps can be extended with compiled native code, and if you do the heavy stuff in native code you can a nice speed boost.

Svelte is a JavaScript UI framework – an alternative to React, Vue, Angular, or one of the other 7500 frameworks. Svelte uses a compiler to generate small, fast, reactive code.

I figured by combining them, and doing most of the heavy lifting in Rust, I’d end up with an app that feels snappy.

The full, completed project is on GitHub and it has instructions on how to run it, along with my rollercoaster of a commit history while I was trying to get it working.

Here’s what it looks like:

How Svelte Stores Work

One of the things I love about Svelte is its reactivity model, and in particular, its concept of stores. A store is a reactive variable that holds a single value.

Any part of the app can subscribe to the store, and every subscriber will be (synchronously!) notified when the store’s value is changed.

Here’s a simple example (live version here):

<script>
  import { onDestroy } from 'svelte';
  import { writable } from 'svelte/store';
  
  // Make a store
  const count = writable(0);

  // Subscribe to it, and update the displayed value
  let visibleCount = 0;
  const unsubscribe = count.subscribe(value => {
    visibleCount = value;
  });

  function increment() {
    // Replace the store's value with (value + 1)
    count.update(n => n + 1);
  }

  // Tidy up when this component is unmounted
  onDestroy(unsubscribe);
</script>

<button on:click={increment}>Increment</button>
<p>Current value: {visibleCount}</p>

You click the button, it updates. Nothing too mindblowing. But this is just the “low-level” API.

It looks a lot nicer when you introduce Svelte’s special reactive store syntax with the $ (try the live example):

<script>
  import { onDestroy } from 'svelte';
  import { writable } from 'svelte/store';
  
  // Make a store
  const count = writable(0);

  function increment() {
    $count += 1;
  }
</script>

<button on:click={increment}>Increment</button>
<p>Current value: {$count}</p>

It does the exact same thing, just with less code.

The special $count syntax inside the <p> is setting up a subscription behind the scenes, and updating that specific DOM element when the value changes. And it handles the unsubscribe cleanup automatically.

There’s also the $count += 1 (which can also be written $count = $count + 1). It reads like plain old JavaScript, but after the value is changed, this store will notify all of its subscribers – in this case that’s just the $count in the HTML below.

The Svelte docs have a great interactive tutorial on stores if you want to learn more.

The Important Thing is the Contract

It’s easy to look at code like this and assume it’s all magic, especially when there’s fancy syntax like $store.

There’s a chunk of data-intensive code that I wrote in JS instead of Rust because I had this mindset of, “I want the reactivity so it has to be in JavaScript”.

But if you take a step back and look at the underpinnings of how the magic actually works, sometimes you can find new and interesting ways to extend it!

Svelte stores were designed well to allow this: they follow a contract.

The short version is that in order to be a “Svelte store,” an object needs:

A subscribe method that returns an unsubscribe function
A set method if you want to make it writable
It must call the subscribers synchronously (a) at subscribe time and (b) any time the value changes.

If any JS object follows these rules, it’s a Svelte store. And if it’s a Svelte store, it can be used with the fancy $store syntax and everything!

Calling Rust From JavaScript

The next piece of this puzzle is to write some Rust code that can be exposed as an object in JavaScript.

For this, we’re using napi-rs, an awesome framework for connecting Rust and JavaScript together. The creator, LongYinan aka Broooooklyn is doing amazing work on it, and the latest updates (in v2) have made the Rust code very nice to write. Here’s a taste, the “hello world” of Rust functions:

#[macro_use]
extern crate napi;

/// import the preludes
use napi::bindgen_prelude::*;

/// annotating a function with #[napi] makes it available to JS,
/// kinda like `export { sum };`
#[napi]
pub fn sum(a: u32, b: u32) -> u32 {
  a + b
}

Then in JavaScript, we can do this:

// Hand-wavy pseudocode for now...
// The native module has its own folder and
// build setup, which we'll look at below.
import { sum } from './bindings';

console.log(sum(2, 2)) // gives correct answer

A Boilerplate Project with Electron, Rust, and Svelte

We’ve got the big pieces in mind: Electron, Svelte stores, Rust that can be called from JS.

Now we just need to… actually wire up a project with 3 different build systems. Hoorayyyyy. I hope you can hear the excitement in my voice.

So, for this prototype, I took the lazy way out.

It’s a barebones Electron app with the Svelte template cloned into one subfolder, and the native Rust module in another (generated by the NAPI-RS CLI).

The dev experience (DX) is old-school: quit the whole app, rebuild, and restart. Sure, some sort of auto-building, auto-reloading Rube Goldberg-esque tangle of scripts and configuration would’ve been neat, but I didn’t wanna.

So it has this mile-long start script that just cd’s into each subfolder and builds it. It’s not pretty, but it gets the job done!

  "scripts": {
    "start": "cd bindings && npm run build && cd .. && cd ui && npm run build && cd .. && electron .",
    "start:debug": "cd bindings && npm run build:debug && cd .. && cd ui && npm run build && cd .. && electron .",
    "start:clean": "npm run clean && npm run start:debug",
    "clean": "cd bindings && rm -rf target"
  },

We’re not going for awesome DX here. This is a prototype. Awesome DX is Future Work™.

Beginning To End: How It Works

Personally I really like to trace the execution from the very first entry point. I think it helps me understand how all the pieces fit together. So here’s the chain of events that leads to this thing working, with the relevant bits of code:

1. You run npm start. It builds everything, and then runs electron .

package.json

"start": "cd bindings && npm run build && cd .. && cd ui && npm run build && cd .. && electron .",

2. Electron finds and executes main.js because package.json tells it to (via the main key)

package.json

{
  "name": "electron-quick-start",
  "version": "1.0.0",
  "description": "A minimal Electron application",
  "main": "main.js",
  ...
}

3. main.js spawns a BrowserWindow, and loads up index.html

main.js

function createWindow() {
  // Create the browser window.
  const mainWindow = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      contextIsolation: true,
      // Preload will make the native module available
      preload: path.join(__dirname, 'preload.js')
    }
  })

  // Load the index.html of the app.
  mainWindow.loadFile('index.html')
}

4. main.js also specifies a preload.js, where you’re allowed to expose native modules. This is where the Rust module is imported and exposed as window.Napi. (See Security below)

preload.js

// Make native bindings available to the renderer process
window.Napi = require('./bindings');

5. index.html loads the Svelte app’s JavaScript that was built in Step 1

index.html

<html>
  ...
  <body>
    <!-- You can also require other files to run in this process -->
    <script src="./ui/public/build/bundle.js"></script>
  </body>
</html>

6. Svelte has its own ui/main.js, which imports and creates the App component, and mounts it at document.body.

ui/main.js

import App from './App.svelte';

const app = new App({
  target: document.body,
});

export default app;

7. App.svelte instantiates our Rust store with an initial value, which calls the constructor in Rust.

ui/App.svelte

<script>
  import Counter from "./Counter.svelte";
  let showCounter = true;
  let counter = new Napi.Counter(42);
</script>

8. Since Svelte needs to render the counter, it immediately calls .subscribe with a callback, which calls subscribe in Rust.

ui/public/build/bundle.js [compiled by Svelte]

function instance($$self, $$props, $$invalidate) {
  let $counter;
  let showCounter = true;
  let counter = new Napi.Counter(42);
  component_subscribe($$self, counter, value => $$invalidate(1, $counter = value));
  const click_handler = () => $$invalidate(0, showCounter = !showCounter);
  const click_handler_1 = () => set_store_value(counter, $counter = Math.floor(Math.random() * 1234), $counter);
  return [showCounter, $counter, counter, click_handler, click_handler_1];
}

9. The subscribe function, according to the contract, needs to immediately call the provided callback with the current value, so it does that, and then saves the callback for later use. It also returns an unsubscribe function that Svelte will call when the component is unmounted.

#[napi]
impl Counter {
  // ...

  #[napi]
  pub fn subscribe(
    &mut self, env: Env, callback: JsFunction
  ) -> Result<JsFunction> {
    // Create a threadsafe wrapper.
    // (to ensure the callback doesn't 
    // immediately get garbage collected)
    let tsfn: ThreadsafeFunction<u32, ErrorStrategy::Fatal> = callback
      .create_threadsafe_function(0, |ctx| {
        ctx.env.create_uint32(ctx.value).map(|v| vec![v])
      })?;

    // Call once with the initial value
    tsfn.call(self.value, ThreadsafeFunctionCallMode::Blocking);

    // Save the callback so that we can call it later
    let key = self.next_subscriber;
    self.next_subscriber += 1;
    self.subscribers.borrow_mut().insert(key, tsfn);

    // Pass back an unsubscribe callback that
    // will remove the subscription when called
    let subscribers = self.subscribers.clone();
    let unsubscribe = move |ctx: CallContext| -> Result<JsUndefined> {
      subscribers.borrow_mut().remove(&key);
      ctx.env.get_undefined()
    };

    env.create_function_from_closure("unsubscribe", unsubscribe)
  }
}

Security: Electron and `contextIsolation`

Electron is split into 2 processes: the “main” one (which runs Node, and is running main.js in our case) and the “renderer”, which is where your UI code runs. Between the two sits the preload.js. Electron’s official docs explain the process model in more detail.

There are a few layers of security in place to prevent random scripts from gaining unfettered access to your entire computer (because that would be bad).

The first is the nodeIntegration flag, defaulted to false. This makes it so that you can’t use Node’s require() inside the renderer process. It’s a little annoying, but the upside is that if your Electron app happens to open (or is coerced into opening) a sketchy script from somewhere, that script won’t be able to import Node modules and wreak havoc.

The second is the contextIsolation flag, which defaults to true. This makes the preload script, which runs inside the renderer, can’t access window and therefore can’t expose any sensitive APIs directly. You have to use the contextBridge to expose an API that the renderer can use.

Why am I telling you all this? Well, if you look at the preload.js example above, you’ll see that it sets window.Napi directly. It’s not using contextBridge, and contextIsolation is disabled in this project. I tried turning it on, but evidently constructors can’t be passed through the bridge. There might be an alternative way to solve this – if you know of one please let me know!

If your app doesn’t load external resources, and only loads files from disk, my understanding is that leaving contextIsolation disabled is ok.

I’m writing this as a proof of concept WITH THE CAVEAT that this is less secure than it could be (if you have ideas for improvement, let me know on Twitter).

How the Rust Works

The short answer is: it follows the Svelte store contract :) Let’s see how.

It all happens in one file, bindings/src/lib.rs.

First, there’s a struct to hold the current value of the counter, along with its subscribers.

I don’t think the ThreadsafeFunctions can be compared for equality, so I put them in a map instead of a vector, and used the next_subscriber to hold an incrementing key to store the subscribers.

#[napi]
pub struct Counter {
  value: u32,
  subscribers: Rc<RefCell<HashMap<u64, ThreadsafeFunction<u32, ErrorStrategy::Fatal>>>>,
  next_subscriber: u64,
}

Then there are a few functions implemented on this struct. There’s the constructor, which initializes a Counter with no subscribers:

#[napi]
impl Counter {
  #[napi(constructor)]
  pub fn new(value: Option<u32>) -> Counter {
    Counter {
      value: value.unwrap_or(0),
      subscribers: Rc::new(RefCell::new(HashMap::new())),
      next_subscriber: 0,
    }
  }

And there are increment and set functions that do nearly the same thing. Of the two, set is special in that it’s the one that makes this store “writable” in the eyes of Svelte. When we write $count = 7 in JS, that will ultimately call into set here.

#[napi]
pub fn increment(&mut self) -> Result<()> {
  self.value += 1;
  self.notify_subscribers()
}

#[napi]
pub fn set(&mut self, value: u32) -> Result<()> {
  self.value = value;
  self.notify_subscribers()
}

After modifying the value, those functions call notify_subscribers. This one doesn’t have the #[napi] annotation, which means it won’t be callable from JS. This iterates over the subscribers and calls each one with the current value.

Because self.subscribers is an Rc<RefCell<...>> we need to explicitly borrow() it before iterating. This borrow happens at runtime, as opposed to the usual compile-time borrow-checking done by Rust. If something else has this borrowed when we try to borrow it here, the program will panic (aka crash).

I’m reasoning this is panic-free because both the notify_subscribers and the subscribe (the other place that borrows this variable) are running in the single JS main thread, so it shouldn’t be possible for them to step on each others’ access.

fn notify_subscribers(&mut self) -> Result<()> {
  for (_, cbref) in self.subscribers.borrow().iter() {
    cbref.call(self.value, ThreadsafeFunctionCallMode::Blocking);
  }
  Ok(())
}

Most of the real work happens inside subscribe. There are some comments, but also some subtleties that took me some time to figure out.

First, it wraps the callback with a ThreadsafeFunction. I think the reason this works is that ThreadsafeFunction internally sets up a reference counter around the callback. I tried without this at first, and it turned out that the callback was getting garbage-collected immediately after subscribing. Despite storing the callback (and making Rust happy about its ownership), attempting to actually call it was failing.

The ErrorStrategy::Fatal might look alarming, but the alternative, ErrorStrategy::CalleeHandled, doesn’t work at all here. The CalleeHandled style uses Node’s callback calling convention, where it passes the error as the first argument (or null). That doesn’t match Svelte’s store contract, which only expects a single argument. The Fatal strategy passes the argument straight through.

The create_threadsafe_function call itself has a lot going on. The closure being passed in |ctx| { ... } will get called whenever we run .call() on the threadsafe function. The closure’s job is to take the value you pass in and transform it into an array of JavaScript values. So this closure takes the u32 value, wraps it in a JsNumber with create_uint32, and then puts that in a vector. That vector, in turn, gets spread into the arguments to the JS callback.

Saving the callback is important so we can call it later, so self.subscribers.borrow_mut().insert(key, tsfn); does that. We need the borrow_mut because we’re doing runtime borrow checking here.

I initially went with borrow checking at compile time, but the unsubscribe closure threw a wrench in the works. See, we need to add something to the hashmap at subscribe time, and we need to remove something from the same hashmap at unsubscribe time. In JS this is a piece of cake. In Rust, because of the way ownership works, only one thing can “own” self.subscribers at a time. If we moved it out of self and into the unsubscribe closure, then we couldn’t add any more subscribers, or notify them.

The solution I found was to wrap the HashMap with Rc<RefCell<...>>. The Rc part means that the innards can be shared between multiple owners by calling .clone(). The RefCell part means we can mutate the internals without having to pass the borrow checker’s strict rules about mutation. The tradeoff is that it’s up to us to make sure we never have overlapping calls to .borrow() and .borrow_mut(), or the program will panic.

#[napi]
impl Counter {
  // ...

  #[napi]
  pub fn subscribe(
    &mut self, env: Env, callback: JsFunction
  ) -> Result<JsFunction> {
    // Create a threadsafe wrapper.
    // (to ensure the callback doesn't 
    // immediately get garbage collected)
    let tsfn: ThreadsafeFunction<u32, ErrorStrategy::Fatal> = callback
      .create_threadsafe_function(0, |ctx| {
        ctx.env.create_uint32(ctx.value).map(|v| vec![v])
      })?;

    // Call once with the initial value
    tsfn.call(self.value, ThreadsafeFunctionCallMode::Blocking);

    // Save the callback so that we can call it later
    let key = self.next_subscriber;
    self.next_subscriber += 1;
    self.subscribers.borrow_mut().insert(key, tsfn);

    // Pass back an unsubscribe callback that
    // will remove the subscription when called
    let subscribers = self.subscribers.clone();
    let unsubscribe = move |ctx: CallContext| -> Result<JsUndefined> {
      subscribers.borrow_mut().remove(&key);
      ctx.env.get_undefined()
    };

    env.create_function_from_closure("unsubscribe", unsubscribe)
  }
}

That about wraps this up!

I hope I conveyed that this took a good chunk of time fiddling around and running into dead ends, and I’m not sure if I did this the “right” way or if I just happened to stumble into something that works. So please let me know if you have any ideas for improvements. Pull requests welcome :)

Implementing A Svelte Store In Rust was originally published by Dave Ceddia at Dave Ceddia on February 13, 2022.

Interview Questions to Ask Your Interviewer

2022-02-08T04:23:55+00:00

On Twitter, Kyle Shevlin was talking about how at the end of a software engineering interview, they’ll often offer a painfully-small amount of time to ask some of your own questions.

The worst part is, I often just blank in the 5 minute question time. I’ll come up with something because I’m good on my feet, but deep down it feels ineffectual. I’m not getting what I need in that time period, so let me just use the bathroom before the next interview.

— @kyleshevlin

I mentioned that I had a go-to list of questions that I literally printed and brought with me, and would bring out during this 5-minute lightning round. I definitely felt like a huge nerd pulling a set of printed questions out of a binder.

But it turned out to be really helpful, and at a couple of these interviews, my interviewer actually said, “Wow! That’s a lot of questions!” (it was 2 full pages) and offered that if there were any we didn’t get to, that I could send them over email.

This was years ago by the way, long before COVID, when pretty much every interview was in-person. The shock factor of pulling out 2 pages of questions wouldn’t translate so well to Zoom, haha. But still: if time runs out, you can mention that you still have a bunch of questions, and could please email them afterward.

Interview Questions for Your Interviewer

Here in its raw unedited form are the questions I used.

They’re short on purpose, because I wanted to be able to skim the list quickly under pressure.

I suggest, if you decide to use these, to read them over and make sure you have an idea of how you’d form them into actual human sentences… or, if you think that might trip you up, then expand them on the page before you head into ~~battle~~ the interview.

And hopefully, by the time you get to these questions, you’ll already have answers to some of them. (Another benefit of them being short: you can scan past those ones quickly)

How big is the company?

Why did you choose to work here?

Do you enjoy this particular project?

Is there flexibility within the org to move around to different projects?

What's a typical day like?


Software dev process? (agile/tdd/pairing?)

Bug tracking system?

Version control system?

Dev. desktop vs server OS? Developer machine hardware?


Is the product live in production? If not, what's the schedule for developing it?

How often are releases done?

Who supports the product once it's released? Pager duty? Monitoring email?

Where do feature + bugfix requests come from?

Who does the "design" of the product? Internal designers, devs, both?

Would my work be full-stack, or focused on backend/frontend?

How big is the code base? Lots of ties to external/legacy projects?


Typical working hours? Flexibility? Crunch times?

Working from home? Regularly vs. Snow days?


Do you have a favorite part of the job? Least favorite?

Do you have a time tracking system?

Centralized IT dept?

Gov’t contractor? Clearance required? Potential for clearance?

Regulatory compliance? PCI, SOX, etc. Annual training?


Do people hang out outside work? Company outings? Lunch?

Budget for conferences?

Internal lightning talks/brown bag lunches?

Dress code?


Does the company seem stable? Profitable? Any plans to sell?

Bonus structure?

Management style/structure? Frequent catch-ups aka one-on-ones? Something else?

Room for advancement?

Learning opportunities?

I hope this helps you prepare for your interview – and not just to pass their interview, but to make sure you get to interview them a bit, too. You’ll have to work with these people, after all! It’d be good to try to figure out if you’ll enjoy it.

More Resources

Mark Erikson (@acemarke) has his own list of questions here.

Charity Majors (@mipsytipsy) has this great post titled How can you tell if the company you’re interviewing with is rotten on the inside?

If you have a list of your own somewhere, let me know and I’ll add a link here!

Interview Questions to Ask Your Interviewer was originally published by Dave Ceddia at Dave Ceddia on February 08, 2022.

Attach VSCode Debugger to native Rust in an Electron app

2021-09-23T17:57:00+00:00

I’ve been working on a video editor built on top of Electron and Rust, where Rust does the heavy lifting, and Electron (paired with Svelte) takes care of the UI.

Debugging the JS is easy enough: pop open Electron’s devtools, set some breakpoints, and you’re off to the races.

Debugging the Rust is a little harder. But it’s possible!

Here’s my setup for attaching VSCode’s debugger to the native Rust code, which is running within Electron’s renderer process.

Set up `launch.json`

VSCode’s debugger relies on a config file called launch.json. I think it can reside in a few different places; mine is in the .vscode directory in the root of my project, and it looks like this:

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit:
  // https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "type": "lldb",
      "request": "launch",
      "name": "Debug",
      "program": "${workspaceFolder}/backend/target/debug/recut",
      "args": [],
      "cwd": "${workspaceFolder}"
    },
    {
      "type": "lldb",
      "request": "attach",
      "pid": "${command:pickProcess}",
      "name": "Debug Electron Renderer",
    }
  ]
}

I have 2 configurations here:

the first is for launching the Rust executable on its own, so I can debug the Rust in isolation.
the second is for attaching to a running process

It’s the second one that we’ll focus on. That’s the one that matters for attaching to the running Electron process.

    {
      "type": "lldb",
      "request": "attach",
      "pid": "${command:pickProcess}",
      "name": "Debug Electron Renderer",
    }

I’m using a Mac, so type is lldb. This might need to be different for Windows.

The request is attach, meaning that VSCode will try to attach to an already-running process, instead of launching the app itself.

The pid is the special ${command:pickProcess} which will pop up a picker window within VSCode that’ll let you choose the process to attach to (more on that in a second).

The name is whatever descriptive name you want to use.

`pid` vs `processId` vs `processName`

There are a few different properties VSCode supports to let you choose which process to attach to.

I found this config from a StackOverflow question about attaching VSCode to a .NET Core app, and in the question, they used processId and processName instead of pid.

I’m not sure if this difference is a Mac vs. Windows thing, or if VSCode changed the names of these properties, but in my setup, processId did not work.

VSCode originally complained that it needed a “pid” so I used switched from processId to pid to get it working.

If you’re on Windows, you might need to swap out pid for something else.

Connect the Debugger to Electron’s Renderer Process

Before you can connect the debugger, the app needs to be running, so start it up however you normally do (npm run dev or whatever).

One important detail: make sure the native Rust module has been built with debug symbols included! Cargo’s --release flag will strip those out by default and you probably won’t be able to set breakpoints, so use cargo build instead of cargo build --release. You might need to modify your build scripts to make this change, if they inherently build in release mode.

In VSCode, select the Debugger from the sidebar and choose the configuration from the dropdown at the top, then click the |> Play button to launch it.

Finding the Right Process

VSCode will prompt you to select a process to attach to, and you can type to filter the list.

You can try typing “electron”, or the name of your project directory or executable to narrow it down.

This might not be terribly helpful, though. At least for me, VSCode’s dialog isn’t wide enough to show the full path, I couldn’t find a way to resize it, and hovering the rows doesn’t show the full text either.

And anyway, even if I could see the full path, they’re probably all the same.

Not a huge help.

Use Activity Monitor / Task Manager

To get a better view of the tasks, open up your OS’s task viewer. On Mac that’s Activity Monitor, under /Applications/Utilities. On Windows that’s the Task Manager.

Filter the list to just your app (“Electron” if you haven’t set the name yet, like I haven’t)

Look at the PID column for the one you want to attach to, and type that number into VSCode’s PID-picker popup.

As for which one to pick: connect to the Electron process which is running your native code.

If that’s the Main process, look for the process named just “Electron” or “YourApp”
If that’s the Renderer process, look for “Electron Helper (Renderer)” or “YourApp Helper (Renderer)”

If your code is in the Renderer process, and you have multiple windows open (e.g. Devtools), you’ll see multiple Renderer processes, which makes this harder.

I suggest closing the DevTools window if you have it popped out, and any other windows that are not the one you want to debug.

Set Breakpoints in VSCode

Once you’re connected, you should be able to set breakpoints within VSCode, inspect variables, and step in/out/continue/etc as usual.

Attach VSCode Debugger to native Rust in an Electron app was originally published by Dave Ceddia at Dave Ceddia on September 23, 2021.

Example of Using napi-rs with Electron

2021-08-21T16:35:58+00:00

You can improve the performance of your Electron apps quite a bit by offloading intensive tasks to Rust.

There are 2 main libraries out there to help you do this: Neon and napi-rs. As it stands today, Neon is more popular, with over 5700 stars on Github, whereas napi-rs has only a little over 800.

That said, stars aren’t everything! For my use case (and as of this writing) napi-rs supports an important feature that Neon doesn’t have yet: the ability for Rust to call back to a JS callback function multiple times.

I went in search of a minimal starter project to get going with Electron + napi-rs, but couldn’t find anything. Hence this post :)

TL;DR: If you just want to clone the project you can find electron-napi-rs on Github.

The rest of this post explains how the pieces fit together.

(btw if you want to use Neon instead of napi-rs, check out Mike Barber’s electron-neon-rust, which is basically the Neon version of what I’m doing here)

A Minimal Project with Electron and napi-rs

I started with the official Electron starter from electron-quick-start. That’ll get an Electron app on the screen.

Then I added the Rust module. This is more or less a copy-paste from napi-rs’s napi-derive-example, with a few relative paths changed.

I’m putting the Rust module in a directory called hi-rust inside the Electron project. We only need to add 4 files:

Cargo.toml

hi-rust/Cargo.toml

[package]
authors = ["LongYinan <lynweklm@gmail.com>"]
edition = "2018"
name = "hi-rust"
version = "0.1.0"

[lib]
crate-type = ["cdylib"]

[dependencies]
napi = "1.7.5"
napi-derive = "1.1.0"

[build-dependencies]
napi-build = "1.1.0"

(modified to use version numbers instead of relative paths for the [dependencies] and [build-dependencies])

build.rs

hi-rust/build.rs

extern crate napi_build;

fn main() {
  use napi_build::setup;

  setup();
}

(straight out of napi-derive-example)

This build.rs file is special to Rust. You can read more in the Build Scripts section of the Cargo book, but basically Rust will look for a build.rs file and run it before the build, if it’s present.

src/lib.rs

Then there’s the code itself, under the src folder:

hi-rust/src/lib.rs

#[macro_use]
extern crate napi_derive;

use napi::{CallContext, Error, JsNumber, JsObject, JsUnknown, Result, Status};
use std::convert::TryInto;

#[module_exports]
fn init(mut exports: JsObject) -> Result<()> {
  exports.create_named_method("testThrow", test_throw)?;
  exports.create_named_method("fibonacci", fibonacci)?;

  Ok(())
}

#[js_function]
fn test_throw(_ctx: CallContext) -> Result<JsUnknown> {
  Err(Error::from_status(Status::GenericFailure))
}

#[js_function(1)]
fn fibonacci(ctx: CallContext) -> Result<JsNumber> {
  let n = ctx.get::<JsNumber>(0)?.try_into()?;
  ctx.env.create_int64(fibonacci_native(n))
}

#[inline]
fn fibonacci_native(n: i64) -> i64 {
  match n {
    1 | 2 => 1,
    _ => fibonacci_native(n - 1) + fibonacci_native(n - 2),
  }
}

(also straight out of the napi-rs repo)

It exposes 2 Rust functions to JavaScript: test_throw and fibonacci are exposed as testThrow and fibonacci, respectively.

The init is effectively the “entry point” for the JS <-> Rust binding, and this file could call out to whatever Rust code you want.

package.json

Run npm init -y to initialize a default package.json, then add “build” and “install” scripts.

The build script depends on a package for copying out the built Rust binary, so install that with npm install -D cargo-cp-artifact.

hi-rust/package.json

{
  "name": "hi-rust",
  "version": "1.0.0",
  "description": "",
  "main": "index.node",
  "scripts": {
    "install": "npm run build",
    "build": "cargo-cp-artifact -nc index.node -- cargo build --message-format=json-render-diagnostics"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "cargo-cp-artifact": "^0.1.4"
  }
}

The build script effectively does 2 things:

cargo build compiles the Rust module and saves the compiled file in target/debug
cargo-cp-artifact copies that output into the root of the project as index.node

The install script just makes it easier to run. (You can npm i instead of npm run build)

Release Build

Cargo will compile a Debug build by default, which is slower and larger, but contains debugging symbols.

Make sure to compile a Release build if you want it to be faster and smaller! Append the --release flag to the end of the cargo build command if/when you want to do that.

I did this right away because my app was much slower in Debug mode.

Aside: index.js vs index.node?

An interesting thing happened when I was setting this up!

At first I didn’t change “main” at all, and left its value as the default index.js. Which… worked perfectly fine, even though there was only an index.node file present (no index.js).

I guess Node knows to look for index.node if it can’t find index.js?

Anyway, that was a little unnerving, so I changed the “main” key to point directly to index.node, and that worked fine too. I figure it’s better to point it at a file that actually exists 🤷 At the very least it’ll shave a couple cycles off the import, eh?

Build index.node

Running npm install inside the hi-rust directory will download the required packages and build the index.node file, which is our native Rust code, packaged up so that Node can require() it.

Add the Rust module as a dependency

Back in the top-level Electron project, add the Rust module as a dependency to package.json:

package.json

{
  ...

  "dependencies": {
    "hi-rust": "./hi-rust"
  }
}

Then run npm install and it’ll make a link to the project.

From here on, you can modify and rebuild the Rust project (inside hi-rust) without having to re-run npm install.

Expose the Rust module with preload.js

We have native code, it’s packaged and built as a module that Node can import. Now we need to import it inside the Electron app.

There’s 2 ways to do this: the insecure way, and the better way.

The insecure way is to set nodeIntegration: true so that we can require() node modules directly from our Electron renderer process. It makes for easier code, but the main downside is the massive security hole it opens up.

Why not to set `nodeIntegration: true` in Electron

With the insecure setup, any JS run by the renderer has full access to the user’s system. That means File APIs, Network APIs, Process APIs, etc, etc.

It can do anything the user can do. Like download and run some malicious program, or ransomware their home directory.

Writing the code with nodeIntegration: true makes for slightly less hassle at the expense of a gaping security hole.

The better way

The better way is to use Electron’s preload file to selectively expose functionality to the renderer process a.k.a. the “main world”, which is what we’ll do here.

In main.js, the Electron starter project sets up preload.js as the designated preload file. The preloader has access to both Node APIs and browser APIs, but the crucial difference is that it’s isolated: the renderer can’t reach in and call stuff from preload, unless preload has explicitly exposed it.

So we expose our Rust module from preload.js like so:

preload.js

// Import the Rust library and expose it globally as `rustLib`
// in the renderer (also accessible as `window.rustLib`)
const rustLib = require('hi-rust')
const { contextBridge } = require('electron')
contextBridge.exposeInMainWorld('rustLib', rustLib)

Note this exposes the whole library! You’ll want to pause and reflect for a second whether this is a good idea from a security standpoint. If malicious code could call any of your library’s functions, what could happen?

As a potentially safer alternative, you can expose individual functions…

preload.js

contextBridge.exposeInMainWorld('rustLib', {
  fibonacci: rustLib.fibonacci
})

Or wrap the calls in a function, to ensure only certain arguments are allowed through, or do other checks:

preload.js

contextBridge.exposeInMainWorld('rustLib', {
  fibonacci: (num) => {
    if (num > 42) return;
    return rustLib.fibonacci(num);
  }
})

You can also use Electron’s IPC system to send requests back and forth between main and renderer processes.

Call the Rust code from Electron in renderer.js

Now we can finally call the Rust function from the renderer!

Once the DOM is ready, we call rustLib.fibonacci, referencing the exposed global rustLib that came from the preload script, and store the result in an element (that we still need to create).

renderer.js

window.addEventListener('DOMContentLoaded', () => {
  const result = rustLib.fibonacci(8);
  const content = document.querySelector('#rust-content');
  content.innerHTML = `This number came from Rust! <strong>${result}</strong>`;
});

If you run this now you’ll probably get an error like “Cannot access property innerHTML of null”, because the element doesn’t exist yet.

Let’s add a div with id="rust-content" to contain the result:

index.html

<html>
  <!-- snip -->
  <body>
    <!-- snip -->
    <div id="rust-content"></div>
  </body>
</html>

It works!

At this point you should be able to run npm start from the top-level (Electron) directory, and the app should pop up with a number computed by Rust :)

…synchronously!

One thing to note that this is a synchronous call to Rust. If the fibonacci function is super slow, or we were to call some other function that blocked, our app would freeze up.

You can try this yourself: try passing a big number like 1234 to fibonacci, instead of 8.

Help! Errors!

Here are a couple errors I hit along the way and how I fixed them. If you’re following along, you probably won’t hit these, but I’m listing them here just in case.

A missing `package.json`

I got this error when I forgot to create a package.json inside the Rust library’s directory:

Internal Error: Cannot find module '/Users/dceddia/Projects/electron-napi-rs/hi-rust/package.json'
Require stack:
- /usr/local/lib/node_modules/@napi-rs/cli/scripts/index.js
Require stack:
- /usr/local/lib/node_modules/@napi-rs/cli/scripts/index.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:94:18)
    at getNapiConfig (/usr/local/lib/node_modules/@napi-rs/cli/scripts/index.js:23450:19)
    at BuildCommand.<lt;anonymous> (/usr/local/lib/node_modules/@napi-rs/cli/scripts/index.js:23579:30)
    at Generator.next (<lt;anonymous>)
    at /usr/local/lib/node_modules/@napi-rs/cli/scripts/index.js:65:61
    at new Promise (<lt;anonymous>)
    at __async (/usr/local/lib/node_modules/@napi-rs/cli/scripts/index.js:49:10)

The fix ended up being pretty simple: npm init -y created a package.json file and solved the error.

Exporting incorrectly from Electron’s `preload.js`

My first attempt to expose the Rust library to Electron’s renderer process was something like:

const rustLib = require('hi-rust');
window.rustLib = rustLib;

I was able to start Electron just fine, but it logged an error in the browser console, indicating that window.rustLib was undefined… which meant my line was being ignored.

Uncaught TypeError: Cannot read property 'fibonacci' of undefined

I think it’s because contextIsolation is ON by default, so anything added to the window object won’t be visible.

The fix was to use Electron’s contextBridge module, specifically the exposeInMainWorld function:

preload.js

const rustLib = require('hi-rust');
const { contextBridge } = require('electron');

contextBridge.exposeInMainWorld('rustLib', rustLib)

Example of Using napi-rs with Electron was originally published by Dave Ceddia at Dave Ceddia on August 21, 2021.

Escape Liquid in ConvertKit (so you can use double braces)

2021-08-13T14:02:56+00:00

Need to use double braces in your ConvertKit email? Maybe you’re trying to write some code, and the braces are getting stripped out along with everything inside.

Here’s the easy fix:

Before the opening double braces, add {% raw %}.

After the closing braces, add {% endraw %}.

Example of Escaping Double Braces in ConvertKit Liquid

I had this problem myself – some of my email content was getting stripped out, ending up like this:

<CustomButton
  green={true}
  width={64}
  options=
  onClick={doStuffFunc}
/>

And here’s what it was supposed to be, with more text on the options= line:

<CustomButton
  green={true}
  width={64}
  options={{ awesome: "yes", disabled: "no" }}
  onClick={doStuffFunc}
/>

To get that result, I changed the text of the email to wrap the double braces in a raw/endraw block:

<CustomButton
  green={true}
  width={64}
  options={% raw %}{{ awesome: "yes", disabled: "no" }}{% endraw %}
  onClick={doStuffFunc}
/>

And now it works great :)

Bonus: How to Write `{% raw %}` if you really really have to

If you need to write almost any other Liquid in your emails, and want it to appear as-is in the actual email, wrapping it in {% raw %} + {% endraw %} will do it.

But what if you want to literally include the text {% raw %} in an email?

(I had to figure this out in order to write this post, because my blog also uses Liquid for templating!)

Fair warning, this will probably hurt your eyes and brain. It hurt mine. Here’s how it do it:

{{ "{% raw" }} %}

and

{{ "{% endraw" }} %}

Here’s why this works:

{{ "{% raw" }} %}

The double braces are actually a Liquid expression (the whole yellow part)
Inside the double braces is a string surrounded by double quotes (in orange). The quotes get removed before the text is inserted into the page.
The final closing %} is plain old text, since it’s outside of the double braces. It doesn’t mean anything special to Liquid.

Liquid-ception.

Escape Liquid in ConvertKit (so you can use double braces) was originally published by Dave Ceddia at Dave Ceddia on August 13, 2021.

How to Manually Symbolicate a Crash Log from a macOS App

2021-06-26T23:37:56+00:00

Is one of your Mac apps crashing? If you got a crash report from your users, or an unsymbolicated crash log from Sentry, I’ll walk you through how to decode it into something you can use to debug the crash.

For my own app Recut, I’ve added the Sentry library to capture crash reports. For whatever reason, Sentry does not symbolicate my crash reports. I’ve uploaded the dSYMs and it just seems to ignore them. So: I’ll just symbolicate them myself!

Here’s how to do it manually. I also put together a Ruby script to symbolicate the whole crash report too.

1. Download the unsymbolicated crash report from Sentry.

On the error report, select Raw and Unsymbolicated and click Download. The Download button won’t appear until you select Raw. Don’t leave it as the default Symbolicated or else the downloaded log will have a bunch of <redacted> where the memory addresses should be.

2. Make a new empty folder

Then open a Terminal, and cd to your new folder. We’ll be copying the necessary files here, because they all need to be in one place to symbolicate properly.

3. Open Xcode and the Organizer

In Xcode, under the Window menu, click Organizer to open it up.

This contains all of the archived builds of your app.

4. Find the correct release

Match up the info from the crash log (or the info in Sentry) with your list of releases in Xcode’s Organizer, and pick the one that matches.

Symbolication won’t work right (or maybe at all?) unless all the versions match up.

In my example I’m using release 2.0.1, build 552.

5. Copy files out of the release

Right-click the release, and choose Show in Finder.

That’ll open a Finder window with a single .xcarchive file in it.

Right-click that xcarchive, and choose Show Package Contents.

You should see a bunch of folders like this:

The files we need are in 2 places:

from dSYMs: copy everything into the folder you created.
from Products/Applications: copy your app into the same folder.

Make sure that you copy these files! Do not move them.

This xcarchive is your key to the kingdom… if you lose these files, you won’t be able to symbolicate crash reports anymore. So leave the original files alone, just make copies.

6. Run the symbolicator tool

You should have a preinstalled command line tool called atos. From its man page, its job is to “convert numeric addresses to symbols of binary images or processes”.

Now in your folder you should have at least these 3 things:

the crash report file (a text file)
YourApp.app.dSYM
YourApp.app

You can manually symbolicate a single line by plugging a couple memory addresses into atos. For example, here are the first few lines of a crash in my app:

Thread 0 Crashed:
0   Recut                           0x204302872         0x204296000 + 444530
1   Recut                           0x204308b5c         0x204296000 + 469852
2   Recut                           0x204308afe         0x204296000 + 469758

To look up the function and file where this crash occurred, I’ll take the first 2 memory addresses and run atos;

atos -o Recut.app/Contents/MacOS/Recut -arch x86_64 -l 0x204296000 0x204302872

That prints out the location of the crash and I can go look it up.

closure #1 in WaveDataManager.samplesForResolution(_:) (in Recut) (WaveDataManager.swift:150)

7. Run a script to automatically symbolicate everything

I wrote a Ruby script to run the atos command on every relevant line and symbolicate the whole crash report in one go. It’s in this GitHub gist.

To use:

Download it
Make it executable chmod +x ./symbolicate.rb
Run it on your files:

symbolicate.rb 53c91214f29a42f1a0d19f86b7236e70.crash x86_64 Recut.app Recut.app.dSYM

This will print out the crash report, but with your own app’s calls symbolicated:

Thread 0 Crashed:
0   Recut                           0x204302872         closure #1 in WaveDataManager.samplesForResolution(_:) (in Recut) (WaveDataManager.swift:150)
1   Recut                           0x204308b5c         thunk for @callee_guaranteed () -> () (in Recut) (<compiler-generated>:0)
2   Recut                           0x204308afe         thunk for @escaping @callee_guaranteed () -> () (in Recut) (<compiler-generated>:0)
...

You can pass the -g to colorize the output, to highlight the lines that correspond to your app’s code.

By default it hides threads that don’t include any calls into your app code. It also hides the big list of binaries at the end of the crash report. You can turn those off with flags.

Here’s the full usage info:

Usage: symbolicate -g -b -t [crash_log] [arch] [app_bundle] [dsym]

The crash log, app, and dSYM should all be in the current working directory.

  In Xcode: Window > Organizer
  right-click the release, Show in Finder
  right-click the xcarchive, Show Package Contents
  copy files from `dSYMs` and `Products/Applications` into a new empty folder
  copy the crash log to the same folder

-g          Colorize the output to highlight this app's lines
-b          Show the 'Binary Images' section (by default this is omitted for brevity)
-t          Show all threads, including ones that have no calls to your app
crash_log   text file from Sentry
arch        x86_64 or arm64 (get this from Sentry)
app_bundle  TheApp.app (in current directory)
dsym        TheApp.app.dSYM (in current directory)

Now Go Debug!

I hope this helps you with your own app debugging journey!

How to Manually Symbolicate a Crash Log from a macOS App was originally published by Dave Ceddia at Dave Ceddia on June 26, 2021.

Using Forms in React

2021-05-12T17:05:03+00:00

No matter what kind of app you’re writing, there’s a good chance you need at least one form.

Forms in React are often a pain, filled with verbose and boilerplate-y code.

Let’s look at how to make forms in React with less pain.

In this article we’ll be focusing on using plain React, with no libraries. You’ll learn how forms really work, so you can confidently build them yourself. And if later you choose to add a form library, you’ll know how they work under the hood.

We’re going to cover:

How to create React forms without installing any libraries
The two styles of inputs in React forms
When to use Controlled vs. Uncontrolled inputs
An easy way to get values out of uncontrolled inputs

How to Create Forms with Plain React

Let’s dive right in. We’re going to build a simple contact form. Here’s the first iteration, a standalone component called ContactForm that renders a form:

function ContactForm() {
  return (
    <form>
      <div>
        <label htmlFor="name">Name</label>
        <input id="name" type="text" />
      </div>
      <div>
        <label htmlFor="email">Email</label>
        <input id="email" type="email" />
      </div>
      <div>
        <label htmlFor="message">Message</label>
        <textarea id="message" />
      </div>
      <button type="submit">Submit</button>
    </form>
  );
}

You don’t need to install a library to do any of this. React has built-in support for forms, because HTML and the DOM have built-in support for forms. At the end of the day, React is rendering DOM nodes.

In fact, for small forms, you probably don’t need a form library at all. Something like Formik or react-hook-form is overkill if all you need is a simple form.

There’s no state in here yet, and we’re not responding to form submission, but this component will already render a form you can interact with. (If you submit it, the page will reload, because submission is still being handled in the default way by the browser)

React Forms vs. HTML Forms

If you’ve worked with forms in plain HTML, a lot of this will probably seem familiar.

There’s a form tag, and labels for the inputs, same as you’d write in HTML.

Each label has an htmlFor prop that matches the id on its corresponding input. (That’s one difference: in HTML, the label attribute would be for. React uses htmlFor instead.)

If you haven’t done much with plain HTML, just know that React didn’t make this stuff up! The things React does are pretty limited, and the way forms work is borrowed from HTML and the DOM.

Two Kinds of Inputs: Controlled vs. Uncontrolled

Inputs in React can be one of two types: controlled or uncontrolled.

An uncontrolled input is the simpler of the two. It’s the closest to a plain HTML input. React puts it on the page, and the browser keeps track of the rest. When you need to access the input’s value, React provides a way to do that. Uncontrolled inputs require less code, but make it harder to do certain things.

With a controlled input, YOU explicitly control the value that the input displays. You have to write code to respond to keypresses, store the current value somewhere, and pass that value back to the input to be displayed. It’s a feedback loop with your code in the middle. It’s more manual work to wire these up, but they offer the most control.

Let’s look at these two styles in practice, applied to our contact form.

Controlled Inputs

With a controlled input, you write the code to manage the value explicitly.

You’ll need to create state to hold it, update that state when the value changes, and explicitly tell the input what value to display.

To update our contact form to use controlled inputs, we’ll need to add a few things, highlighted here:

function ContactForm() {
  const [name, setName] = React.useState('');
  const [email, setEmail] = React.useState('');
  const [message, setMessage] = React.useState('');

  function handleSubmit(event) {
    event.preventDefault();
    console.log('name:', name);
    console.log('email:', email);
    console.log('message:', message);
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="name">Name</label>
        <input
          id="name"
          type="text"
          value={name}
          onChange={(e) => setName(e.target.value)}
        />
      </div>
      <div>
        <label htmlFor="email">Email</label>
        <input
          id="email"
          type="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
        />
      </div>
      <div>
        <label htmlFor="message">Message</label>
        <textarea
          id="message"
          value={message}
          onChange={(e) => setMessage(e.target.value)}
        />
      </div>
      <button type="submit">Submit</button>
    </form>
  );
}

We’ve added 3 calls to useState to create 3 variables to hold the inputs’ values. They’re initially empty, ''.

Each input has gained a couple new props, too.

value tells the input what to display. Here, we’re passing the value from the corresponding state variable.
onChange is a function, and gets called when the user changes the input. It receives the event (commonly called e or event, but you can name it anything), and we take the input’s current value (e.target.value) and save it into state.

Notice how manual this is. With every keypress, our onChange gets called, and we explicitly setWhatever, which re-renders the whole ContactForm with the new value.

This means that with every keypress, the component will re-render the whole form.

For small forms this is fine. Really, it’s fine. Renders are fast. Rendering 3 or 5 or 10 inputs with every keypress is not going to perceptibly slow down the app.

If you have a form with tons of inputs though, this re-rendering might start to matter, especially on slower devices. At this point you might need to look into optimizations, in order to limit the re-renders to only the inputs that changed.

Or, consider how you could streamline the form so there are fewer inputs shown at once. If React isn’t happy about re-rendering 100 inputs on every keypress, I’d imagine your users aren’t very happy with seeing 100 inputs on a page either 😂

Alternatively…

Uncontrolled Inputs

If you do nothing beyond dropping an <input> in your render function, that input will be uncontrolled. You tell React to render the input, and the browser does the rest.

Uncontrolled inputs manage their own value. Just like with a plain HTML form, the value is kept in the input’s DOM node. No need to manually track it.

In the first code sample on this page, all the inputs were uncontrolled, because we weren’t passing the value prop that would tell them what value to display.

But if we’re not actively tracking the value… how can we tell what the value is?

Here’s where “refs” come in.

What is a “ref”?

React takes your JSX and constructs the actual DOM, which the browser displays. Refs tie these two representations together, letting your React component get access to the DOM nodes that represent it.

A ref holds a reference to a DOM node.

Here’s why that matters: The JSX you write is merely a description of the page you want to create. What you really need is the underlying DOM input, so that you can pull out the value.

So, to get the value from an uncontrolled input, you need a reference to it, which we get by assigning a ref prop. Then you can read out the value when the form is submitted (or really, whenever you want!).

Let’s add refs to our contact form inputs, building upon the “bare form” example from earlier:

function ContactForm() {
  const nameRef = React.useRef();
  const emailRef = React.useRef();
  const messageRef = React.useRef();

  return (
    <form>
      <div>
        <label htmlFor="name">Name</label>
        <input
          id="name"
          type="text"
          ref={nameRef}
        />
      </div>
      <div>
        <label htmlFor="email">Email</label>
        <input
          id="email"
          type="email"
          ref={emailRef}
        />
      </div>
      <div>
        <label htmlFor="message">Message</label>
        <textarea
          id="message"
          ref={messageRef}
        />
      </div>
      <button type="submit">Submit</button>
    </form>
  );
}

We did a couple things here:

created 3 refs with the useRef hook
bound the refs to the inputs with the ref prop

When the component is first rendered, React will set up the refs. nameRef.current will then refer to the name input’s DOM node, emailRef.current will refer to the email input, and so on.

These refs hold the same values as the ones you’d get if you ran a document.querySelector('input[id=name]') in your browser console. It’s the browser’s raw input node; React is just passing it back to you.

The last piece of the puzzle is how to get the values out of the inputs.

Uncontrolled inputs are the best choice when you only need to do something with the value at a specific time, such as when the form is submitted. (If you need to inspect/validate/transform the value on every keypress, use a controlled input)

We can create a function to handle form submission, and print out the values:

function ContactForm() {
  const nameRef = React.useRef();
  const emailRef = React.useRef();
  const messageRef = React.useRef();

  function handleSubmit(event) {
    event.preventDefault();
    console.log('name:', nameRef.current.value);
    console.log('email:', emailRef.current.value);
    console.log('message:', messageRef.current.value);
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="name">Name</label>
        <input
          id="name"
          type="text"
          ref={nameRef}
        />
      </div>
      <div>
        <label htmlFor="email">Email</label>
        <input
          id="email"
          type="email"
          ref={emailRef}
        />
      </div>
      <div>
        <label htmlFor="message">Message</label>
        <textarea
          id="message"
          ref={messageRef}
        />
      </div>
      <button type="submit">Submit</button>
    </form>
  );
}

Your handleSubmit function can then do whatever you need with those values: validate them, asynchronously POST them to a server, etc.

Notice we’re calling event.preventDefault() at the top. Without this, submitting the form would refresh the page.

Controlled vs. Uncontrolled: Which to Use?

Let’t go over some pros and cons of each style of input so you can decide which you want to use.

(You might’ve heard that controlled inputs are a “best practice” which of course would imply uncontrolled inputs are NOT! 😱 I’ll address this near the end.)

When and Why to Use Controlled Inputs

Of the two styles, controlled inputs are the more “React-y way” of doing things, where UI reflects state. By changing the state, you change the UI. If you don’t change the state, the UI stays the same. You don’t meddle with the underlying input in an imperative, mutable way.

This makes controlled inputs perfect for things like:

Instantly validating the form on every keypress: useful if you want to keep the Submit button disabled until everything is valid, for instance.
Handling formatted input, like a credit card number field, or preventing certain characters from being typed.
Keeping multiple inputs in sync with each other when they’re based on the same data

The buck stops with you, dear developer. Want to ignore some weird character the user typed? Easy, just strip it out.

function EmailField() {
  const [email, setEmail] = useState('');

  const handleChange = e => {
    // no exclamations allowed!
    setEmail(e.target.value.replace(/!/g, ''));
  }

  return (
    <div>
      <label htmlFor="email">Email address</label>
      <input
        id="email"
        value={email}
        onChange={handleChange}
      />
    </div>
  );
}

There are plenty of use cases where you want to react to every keypress and handle it somehow. Controlled inputs are good for that.

But there are some downsides.

Controlled Inputs are More Complex

As we’ve already seen, you have to manually manage the value of the input, which means you need (a) state to hold it and (b) a change handler function, and you need those for every input.

You can work around part of this problem by combining the inputs into one state object:

function MultipleInputs() {
  const [values, setValues] = useState({
    email: '',
    name: ''
  });

  const handleChange = e => {
    setValues(oldValues => ({
      ...oldValues,
      [e.target.name]: e.target.value
    }));
  }

  return (
    <>
      <div>
        <label htmlFor="email">Email address</label>
        <input
          id="email"
          name="email"
          value={values.email}
          onChange={handleChange}
        />
      </div>
      <div>
        <label htmlFor="name">Full Name</label>
        <input
          id="name"
          name="name"
          value={values.name}
          onChange={handleChange}
        />
      </div>
    </>
  );
}

It’s nicer, but it’s still code you need to write.

Boilerplate like this is one of the reasons React form libraries are so popular – but again, if you have 2 or 3 inputs on a page, I would argue that saving a few lines of tedium is not worth adding a form library.

Controlled Inputs Re-render on Every Keypress

Every time you press a key, React calls the function in theonChange prop, which sets the state. Setting the state causes the component and its children to re-render (unless they’re already optimized with React.memo or PureComponent).

This is mostly fine. Renders are fast. For small-to-medium forms you probably won’t even notice. And it’s not that rendering a piddly little input is slow… but it can be a problem in aggregate.

As the number of inputs grows – or if your form has child components that are expensive to render – keypresses might start to feel perceptibly laggy. This threshold is even lower on mobile devices.

It can become a problem of death-by-a-thousand-cuts.

If you start to suspect this problem in your app, fire up the Profiler in the React Developer Tools and take a measurement while you bash on some keys. It’ll tell you which components are slowing things down.

Uncontrolled Inputs Don’t Re-render

A big point in favor of using uncontrolled inputs is that the browser takes care of the whole thing.

You don’t need to update state, which means you don’t need to re-render. Every keypress bypasses React and goes straight to the browser.

Typing the letter 'a' into a form with 300 inputs will re-render exactly zero times, which means React can pretty much sit back and do nothing. Doing nothing is very performant.

Uncontrolled Inputs Can Have Even Less Boilerplate!

Earlier we looked at how to create references to inputs using useRef and pass them as the ref prop.

You can actually go a step further and remove the refs entirely, by taking advantage of the fact that a form knows about its own inputs.

function NoRefsForm() {
  const handleSubmit = e => {
    e.preventDefault();
    const form = e.target;
    console.log('email', form.email, form.elements.email);
    console.log('name', form.name, form.elements.name);
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="email">Email address</label>
        <input
          id="email"
          name="email"
        />
      </div>
      <div>
        <label htmlFor="name">Full Name</label>
        <input
          id="name"
          name="name"
        />
      </div>
      <button type="submit">Submit</button>
    </form>
  );
}

The inputs are properties on the form itself, named by their id AND their name. Yep, both.

They’re also available at form.elements. Check it out:

function App() {
  const handleSubmit = (e) => {
    e.preventDefault();
    const form = e.target;
    console.log(
      form.email,
      form.elements.email,
      form.userEmail,
      form.elements.userEmail);
  };

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="userEmail">Email address</label>
        <input id="userEmail" name="email" />
      </div>
      <button type="submit">Submit</button>
    </form>
  );
}

This prints the same input 4 times:

<input id="userEmail" name="email"></input>
<input id="userEmail" name="email"></input>
<input id="userEmail" name="email"></input>
<input id="userEmail" name="email"></input>

So we can leave off the redundant name prop from the input, if we don’t need it for anything else.

(we need to keep the id because the label’s htmlFor refers to that)

The form.elements array is useful if you need to loop over every input, like if you have a bunch of dynamically-generated ones or something.

Accessible Form Labels

Every input should have a label. Label-less inputs make trouble for screenreaders, which makes trouble for humans… and placeholder text unfortunately doesn’t cut it.

The two ways to do labels are:

Label Next To Input (2 sibling elements)

Give the input an id and the label an htmlFor that matches, and put the elements side-by-side. Order doesn’t matter, as long as the identifiers match up.

<label htmlFor="wat">Email address</label>
<input id="wat" name="email" />

Input Inside Label

If you wrap the input in a label, you don’t need the id and the htmlFor. You’ll want a way to refer to the input though, so give it an id or a name.

<label>
  Email Address
  <input type="email" name="email" />
</label>

If you need more control over the style of the text, you can wrap it in a span.

You can hide the label with CSS if you need to.

Most of the big CSS frameworks have a screenreader-only class, often sr-only, that will hide the label in a way that screenreaders will still be able to read it. Here’s a generic sr-only implementation.

One nice thing about labels is, once you have them associated correctly, the browser will translate clicks on the label as clicks on the input. This is most noticeable with radio buttons – when the label is set up right, clicking the text will select the radio, but otherwise, it’ll frustratingly ignore you.

For more specifics see Lindsey’s post An Introduction to Accessible Labeling

Reduce Form Boilerplate With Small Components

So you’ve added your labels, but these inputs are getting longer and more repetitive…

<div>
  <label htmlFor="email">Email Address</label>
  <input name="email" id="email">
</div>

You can easily move this to a component, though!

function Input({ name, label }) {
  return (
    <div>
      <label htmlFor={name}>{label}</label>
      <input name={name} id={name}>
    </div>
  );
}

Now every input is simple again.

<Input name="email" label="Email Address"/>

And if you’re using uncontrolled inputs, you can still use the trick of reading the values off the form, no refs or state required.

Is It a Best Practice to Use Controlled Inputs?

As of this writing, the React docs have a recommendation about inputs:

In most cases, we recommend using controlled components to implement forms. In a controlled component, form data is handled by a React component. The alternative is uncontrolled components, where form data is handled by the DOM itself.

They go on to say that uncontrolled inputs are the easy way out:

It can also be slightly less code if you want to be quick and dirty. Otherwise, you should usually use controlled components.

The docs don’t exactly explain their reasoning, but my hunch is their recommendation stems from the fact that controlled inputs closely follow the state-driven approach, which is React’s whole reason for existing. Uncontrolled inputs are then treated as an “escape hatch” for when the state-driven approach won’t work for whatever reason.

I agreed with this line of thinking for a while, but I’m starting to have second thoughts.

I’m coming around to the idea that uncontrolled inputs might actually be the better default.

So this might get me some flak, but I’m going to say it anyway:

If uncontrolled inputs work for your case, use ‘em! They’re easier, and faster.

I don’t think I’m alone in this. The popular react-hook-form library uses uncontrolled inputs under the hood to make things fast. And I’ve seen some React thought leaders questioning why we don’t use uncontrolled inputs more often, too. Maybe it’s time to give it some thought!

Are Uncontrolled Inputs an Antipattern?

Uncontrolled inputs are a feature like any other, and they come with some tradeoffs (which we covered above), but they’re not an antipattern.

I tend to reserve the word “antipattern” for techniques that will come back to bite you later on. React has antipatterns like

mutating state instead of using immutability
duplicating values from props into state, and trying to keep them in sync
performing side effects in the body of a component function, instead of in a useEffect hook

These are things that sometimes appear to work just fine, but are ultimately the wrong way to do it, and will cause bugs down the road.

Uncontrolled inputs are a bit unconventional today, but using them is not “doing it wrong”. It’s a matter of picking the right tool for the job. If you go in knowing their limitations, and knowing your use case, then you can be pretty confident in your choice.

Go Make Forms!

I hope this overview of forms in React was helpful! There’s lots more I could cover but honestly this was too long already 😅 If you want to see more on forms, let me know in the comments.

Using Forms in React was originally published by Dave Ceddia at Dave Ceddia on May 12, 2021.

ESLint + VSCode: How to Format Your Code Using .eslintrc

2021-04-07T14:30:31+00:00

I’ve gotten very used to having VSCode autoformat my file when I save. Usually, I use Prettier. But I joined a project that uses ESLint to manage its code style, and I wanted to match the team’s formatting.

I wanted that sweet auto-formatting on save, but using the eslintrc.json file in the project’s root dir instead of Prettier.

Most blog posts wanted to make an entire tutorial out of this… how to set up eslint, how to create the .eslintrc file, etc etc… but I didn’t need that. I have an existing project, I just want to configure VSCode to use ESLint instead of Prettier.

This turned out to only need 4 lines of settings config and a plugin.

Here’s how to do it:

1. Install VSCode ESLint Plugin

In VSCode, open the extension browser with the button on the left. On the Mac, the keyboard shortcut Cmd+Shift+X should do the same.

Search for eslint

Install the top result, called “ESLint”. (It’s this one with over 10 million downloads)

2. Configure VSCode Settings to use ESLint for Formatting

Open up VSCode’s settings. On a Mac, press Cmd+, or get there through the menus: Code > Preferences > Settings.

It’ll open the fancy settings editor, but we need the raw JSON settings file instead.

Click that tiny icon in the top-right that looks like a piece of paper with a little arrow.

Add these 4 new lines inside the top-level settings object:

{
  // ...
  "eslint.format.enable": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

The first one turns on ESLint for formatting, and the next 3 make it do the formatting when you hit save.

That should do it! Save the settings file and close it, we’re done.

Try making some changes to a file that violate some ESLint rule – maybe leaving off a semicolon if they’re required? – and pressing Save. It should auto-format.

Is the formatting still using Prettier?

I ran into a problem recently where Prettier settings were overriding the eslint settings. I’m honestly not sure how these got in there… maybe I put them in and forgot.

In any case, if you want ESLint to indent your files, make sure Prettier isn’t overriding it. Look for any lines like this, that say the defaultFormatter should be Prettier (Cmd+F or Ctrl+F for “prettier” because there might be a few!), and comment them out:

  // "[javascriptreact]": {
  //   "editor.defaultFormatter": "esbenp.prettier-vscode"
  // },

You might need to undo this if you switch back to a project that doesn’t use ES Lint.

You can also create multiple VSCode profiles if you often work in projects with different requirements.

ESLint + VSCode: How to Format Your Code Using .eslintrc was originally published by Dave Ceddia at Dave Ceddia on April 07, 2021.

How to Read React Errors (fix 'Cannot read property of undefined'!)

2021-04-01T05:02:15+00:00

Got an error like this in your React component?

Cannot read property `map` of undefined

In this post we’ll talk about how to fix this one specifically, and along the way you’ll learn how to approach fixing errors in general.

We’ll cover how to read a stack trace, how to interpret the text of the error, and ultimately how to fix it.

The Quick Fix

This error usually means you’re trying to use .map on an array, but that array isn’t defined yet.

That’s often because the array is a piece of undefined state or an undefined prop.

Make sure to initialize the state properly. That means if it will eventually be an array, use useState([]) instead of something like useState() or useState(null).

Let’s look at how we can interpret an error message and track down where it happened and why.

How to Find the Error

First order of business is to figure out where the error is.

If you’re using Create React App, it probably threw up a screen like this:

TypeError
Cannot read property 'map' of undefined
App
/src/App.js:9:13
   6 | return (
   7 |   <div className="App">
   8 |     <h1>List of Items</h1>
>  9 |     {items.map((item) => (
     |           ^
  10 |       <div key={item.id}>
  11 |         {item.name}
  12 |       </div>

Look for the file and the line number first.

Here, that’s /src/App.js and line 9, taken from the light gray text above the code block.

btw, when you see something like /src/App.js:9:13, the way to decode that is filename:lineNumber:columnNumber.

How to Read the Stack Trace

If you’re looking at the browser console instead, you’ll need to read the stack trace to figure out where the error was.

These always look long and intimidating, but the trick is that usually you can ignore most of it!

The lines are in order of execution, with the most recent first.

Here’s the stack trace for this error, with the only important lines highlighted:

TypeError: Cannot read property 'map' of undefined
    at App (App.js:9)
    at renderWithHooks (react-dom.development.js:10021)
    at mountIndeterminateComponent (react-dom.development.js:12143)
    at beginWork (react-dom.development.js:12942)
    at HTMLUnknownElement.callCallback (react-dom.development.js:2746)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:2770)
    at invokeGuardedCallback (react-dom.development.js:2804)
    at beginWork$1 (react-dom.development.js:16114)
    at performUnitOfWork (react-dom.development.js:15339)
    at workLoopSync (react-dom.development.js:15293)
    at renderRootSync (react-dom.development.js:15268)
    at performSyncWorkOnRoot (react-dom.development.js:15008)
    at scheduleUpdateOnFiber (react-dom.development.js:14770)
    at updateContainer (react-dom.development.js:17211)
    at eval (react-dom.development.js:17610)
    at unbatchedUpdates (react-dom.development.js:15104)
    at legacyRenderSubtreeIntoContainer (react-dom.development.js:17609)
    at Object.render (react-dom.development.js:17672)
    at evaluate (index.js:7)
    at z (eval.js:42)
    at G.evaluate (transpiled-module.js:692)
    at be.evaluateTranspiledModule (manager.js:286)
    at be.evaluateModule (manager.js:257)
    at compile.ts:717
    at l (runtime.js:45)
    at Generator._invoke (runtime.js:274)
    at Generator.forEach.e.<computed> [as next] (runtime.js:97)
    at t (asyncToGenerator.js:3)
    at i (asyncToGenerator.js:25)

I wasn’t kidding when I said you could ignore most of it! The first 2 lines are all we care about here.

The first line is the error message, and every line after that spells out the unwound stack of function calls that led to it.

Let’s decode a couple of these lines:

at App (App.js:9)

Here we have:

App is the name of our component function
App.js is the file where it appears
9 is the line of that file where the error occurred

Let’s look at another one:

at performSyncWorkOnRoot (react-dom.development.js:15008)

performSyncWorkOnRoot is the name of the function where this happened
react-dom.development.js is the file
15008 is the line number (it’s a big file!)

Ignore Files That Aren’t Yours

I already mentioned this but I wanted to state it explictly: when you’re looking at a stack trace, you can almost always ignore any lines that refer to files that are outside your codebase, like ones from a library.

Usually, that means you’ll pay attention to only the first few lines.

Scan down the list until it starts to veer into file names you don’t recognize.

There are some cases where you do care about the full stack, but they’re few and far between, in my experience. Things like… if you suspect a bug in the library you’re using, or if you think some erroneous input is making its way into library code and blowing up.

The vast majority of the time, though, the bug will be in your own code ;)

Follow the Clues: How to Diagnose the Error

So the stack trace told us where to look: line 9 of App.js. Let’s open that up.

Here’s the full text of that file:

import "./styles.css";

export default function App() {
  let items;

  return (
    <div className="App">
      <h1>List of Items</h1>
      {items.map(item => (
        <div key={item.id}>
          {item.name}
        </div>
      ))}
    </div>
  );
}

Line 9 is this one:

      {items.map(item => (

And just for reference, here’s that error message again:

TypeError: Cannot read property 'map' of undefined

Let’s break this down!

TypeError is the kind of error

There are a handful of built-in error types. MDN says TypeError “represents an error that occurs when a variable or parameter is not of a valid type.” (this part is, IMO, the least useful part of the error message)

Cannot read property means the code was trying to read a property.

This is a good clue! There are only a few ways to read properties in JavaScript.

The most common is probably the . operator.

As in user.name, to access the name property of the user object.

Or items.map, to access the map property of the items object.

There’s also brackets (aka square brackets, []) for accessing items in an array, like items[5] or items['map'].

You might wonder why the error isn’t more specific, like “Cannot read function `map` of undefined” – but remember, the JS interpreter has no idea what we meant that type to be. It doesn’t know it was supposed to be an array, or that map is a function. It didn’t get that far, because items is undefined.

'map' is the property the code was trying to read

This one is another great clue. Combined with the previous bit, you can be pretty sure you should be looking for .map somewhere on this line.

of undefined is a clue about the value of the variable

It would be way more useful if the error could say “Cannot read property `map` of items”. Sadly it doesn’t say that. It tells you the value of that variable instead.

So now you can piece this all together:

find the line that the error occurred on (line 9, here)
scan that line looking for .map
look at the variable/expression/whatever immediately before the .map and be very suspicious of it.

Once you know which variable to look at, you can read through the function looking for where it comes from, and whether it’s initialized.

In our little example, the only other occurrence of items is line 4:

let items;

This defines the variable but it doesn’t set it to anything, which means its value is undefined. There’s the problem. Fix that, and you fix the error!

Fixing This in the Real World

Of course this example is tiny and contrived, with a simple mistake, and it’s colocated very close to the site of the error. These ones are the easiest to fix!

There are a ton of potential causes for an error like this, though.

Maybe items is a prop passed in from the parent component – and you forgot to pass it down.

Or maybe you did pass that prop, but the value being passed in is actually undefined or null.

If it’s a local state variable, maybe you’re initializing the state as undefined – useState(), written like that with no arguments, will do exactly this!

If it’s a prop coming from Redux, maybe your mapStateToProps is missing the value, or has a typo.

Whatever the case, though, the process is the same: start where the error is and work backwards, verifying your assumptions at each point the variable is used. Throw in some console.logs or use the debugger to inspect the intermediate values and figure out why it’s undefined.

You’ll get it fixed! Good luck :)

How to Read React Errors (fix 'Cannot read property of undefined'!) was originally published by Dave Ceddia at Dave Ceddia on April 01, 2021.

React State Management Libraries and How to Choose

2021-03-17T02:53:19+00:00

The idea of state is one of the trickier things to nail down when you’re starting with React, and as your app grows, so do your state management needs.

In this post I’ll give you the Grand Tour of state management options in React and help you decide which one to use in your project.

What is State?

Just so we’re on the same page, let’s talk about state for a second.

Every interactive app involves responding to events, like when the user clicks a button, and a sidebar closes. Or someone sends a message, and it appears in a chat window.

As these events happen, and the app is updated to reflect them, we say the state of the app has changed. The app looks different than it did before, or it’s in a new mode behind the scenes.

Things like, “whether the sidebar is open or closed” and “the messages in the chat box” are pieces of state. In programming terms, you’d probably have an isSidebarOpen variable somewhere in the app set to true, and a chatMessages array with the messages you’ve received.

At any given moment, broadly speaking, the “state of your app” is determined by all of that data. All those individual variables, whether they’re stored in local component state or some third-party state management store – that’s your app’s state.

This is the high-level concept of “app state”. We aren’t talking about React-specific stuff like useState or Context or Redux or anything yet.

What is State Management?

All of those variables that decide what state your app is in have to be stored somewhere. So state management is a broad term that combines how you store the state and how you change it.

React and its ecosystem offer lots of different ways to store and manage that state. And when I say lots I mean LOTS.

Storing the Data

For storage, you can…

keep those variables in local component state – whether that’s with hooks (useState or useReducer) or in classes (this.state and this.setState)
keep the data in a store, using a third-party library like Redux, MobX, Recoil, or Zustand
you can even keep them on the window object globally

React doesn’t care an ounce where you put the data, but…

Updating the Data and Re-rendering

To make your app interactive, you need a way for React to know that something changed, and that it should re-render some (or all) components on the page.

Because React, despite its name, is not “reactive” in the way some other frameworks are.

Some frameworks “watch” for things, and update accordingly. Angular, Svelte, and Vue do this, among others.

React doesn’t, though. It does not “watch for changes” and magically re-render. You (or something) needs to tell it to do that.

with useState, useReducer, or this.setState (classes), React will re-render when you call one of the setter functions
if you keep the data in Redux, MobX, Recoil, or some other store, then that store will tell React when something has changed, and trigger the re-render for you
if you opt to keep the data globally on window, you need to tell React to update after you change that data.

Oh, and to be totally clear, I do not recommend keeping your state globally on window, for all the usual reasons that global data is to be avoided. Messy code, hard to reason about, etc etc. I only mention it to say that it’s possible, to make the point that React truly couldn’t care less where its data comes from :)

When is useState not enough?

The useState hook is perfect for small amounts of llocal component state. Each useState call can hold a single value, and while you can make that one value an object that contains a bunch of other values, it’s a better idea to split them up.

Once you get past 3-5 useState calls in a single component, things are probably going to get hard to keep track of. Especially if those bits of state depend on each other. With complex interdependencies, a proper state machine could be a better way to go.

Next up, useReducer

The next step “up” from useState is useReducer. The reducer function gives you one centralized place to intercept “actions” and update the state accordingly. A useReducer call, like useState, can only hold one value, but with a reducer it’s much more common for that single value to be an object containing multiple values. The useReducer hook makes it easier to manage that object.

Avoiding Prop Drilling with Context

Beyond useState and useReducer, the next pain point you’re likely to feel is prop drilling. This is when you have a component that holds some state, and then a child component 5 levels down needs access to it, and you have to drill that prop down through each level manually.

The easiest solution here is the Context API. It’s built into React.

// Step 1: create a context. do this outside of any components,
// at the top level of a file, and export it.
export const MyDataContext = React.createContext();

// Step 2: In the component that holds the data, import that
// context and use the Provider to pass the data down
function TheComponentWithState() {
  const [state, setState] = useState('whatever');
  return (
    <MyDataContext.Provider value={state}>
      component's content goes here
      <ComponentThatNeedsData/>
    </MyDataContext.Provider>
  )
}

// Step 3: Anywhere in the subtree under the Provider, pull out
// the `value` you passed in by using useContext
function ComponentThatNeedsData() {
  const data = useContext(MyDataContext);
  // use it
}

Despite its simplicity, Context has one important downside though, and that’s performance, unless you’re very careful about how you use it.

The reason is that every component that calls useContext will re-render when the Provider’s value prop changes. Seems fine so far, right? Components re-render when data changes? Sounds great!

But now envision what would happen if that value was an object containing 50 different bits of state that were used all over the app. And they change frequently, and independently. Every time one of those values changes, every component that uses any of them would re-render.

To avoid that pitfall, store small chunks of related data in each Context, and split up data across multiple Contexts (you can have as many as you want). Or, look into using a third-party library.

The other performance gotcha to avoid is passing a brand new object into the value of the Provider every time. It looks innocuous and it’s easy to miss. Here’s an example:


function TheComponentWithState() {
  const [state, setState] = useState('whatever');
  return (
    <MyDataContext.Provider value={{
      state,
      setState
    }}>
      component's content goes here
      <ComponentThatNeedsData/>
    </MyDataContext.Provider>
  )
}

Here we’re passing an object containing the state and its setter, setState. Those two values are fine. setState will never change, and state only changes when you tell it to. The problem is the object wrapped around them, which will be created anew every time TheComponentWithState is rendered.

You might notice that the stuff we’re talking about here isn’t really about state management as much as it just passing variables around. This is Context’s main purpose. The state itself is kept elsewhere, and Context just passes it around. I recommend reading this post on how Context differs from Redux for more detail.

Also, check out the linked references below for more on how to fix the “fresh object” problem with useCallback.

Learn More

Official docs
My egghead course on React Context for State Management

Third-Party State Management Libraries

Let’s go over the most widely-used important state management tools to know about. I’ve provided links to learn more about each one.

Redux

Redux has been around the longest of all of the libraries mentioned here. It follows a functional (as in functional programming) style, with a heavy reliance on immutability.

You’ll create a single global store to hold all of the app’s state. A reducer function will receive actions that you dispatch from your components, and respond by returning a new copy of state.

Because changes only occur through actions, it’s possible to save and replay those actions and arrive at the same state. You can also take advantage of this to debug errors in production, and services like LogRocket exist to make this easy by recording actions on the server.

Benefits

Battle tested since 2015
The official Redux Toolkit library cuts down on the boilerplate code
Great devtools make debugging simple
Time travel debugging
Small bundle size (redux + react-redux is around 3kb)
Functional style means very little is hidden behind the scenes
Has its own ecosystem of libraries for doing things like syncing to localStorage, managing API requests, and lots more

Drawbacks

The mental model will take some time to understand, especially if you’re not familiar with functional programming
Heavy reliance on immutability can make it cumbersome to write reducers (this is mitigated by adding the Immer library, or using Redux Toolkit which incldues Immer)
Requires you to be explicit about everything (this could be a pro or con, depending on what you prefer)

Learn More

Redux Docs
My free Redux Tutorial

MobX

MobX is probably the most popular alternative to Redux outside of the built-in Context API. Where Redux is all about being explicit and functional, MobX takes the opposite approach.

MobX is based on the observer/observable pattern. You’ll create an observable data model, mark your components as “observers” of that data, and MobX will automatically track which data they access and re-render them when it changes.

It leaves you free to define the data model however you see fit, and gives you tools to watch that model for changes and react to those changes.

MobX uses ES6 Proxies behind the scenes to detect changes, so updating observable data is as easy as using the plain old = assignment operator.

Benefits

Manages state in a truly “reactive” way, so that when you modify a value, any components that use that value will automatically re-render
No actions or reducers to wire up, just modify your state and the app will reflect it.
Magical reactivity means less code to write.
You can write regular mutable code. No special setter functions or immutability required.

Drawbacks

Not as widely used as Redux, so there’s less community support (tutorials, etc.), but much-loved among its users
Magical reactivity means less explicit code. (this could be a pro or a con, depending on how you feel about auto-update “magic”)
Requirement for ES6 Proxies means no support for IE11 and below. (If supporting IE is a requirement for your app, older versions of MobX can work without proxies)

Learn More

Official Intro to MobX and React
Mobx on Github
Free MobX video course on egghead by its creator Michel Weststrate

MobX State Tree

MobX State Tree (or MST) is a layer on top of MobX that gives you a reactive state tree. You’ll create a typed model using MST’s type system. The model can have views (computed properties) and actions (setter functions). All modifications go through actions, so MST can keep track of what’s happening.

Here’s an example model:

const TodoStore = types
  .model('TodoStore', {
    loaded: types.boolean,
    todos: types.array(Todo),
    selectedTodo: types.reference(Todo),
  })
  .views((self) => {
    return {
      get completedTodos() {
        return self.todos.filter((t) => t.done);
      },
      findTodosByUser(user) {
        return self.todos.filter((t) => t.assignee === user);
      },
    };
  })
  .actions((self) => {
    return {
      addTodo(title) {
        self.todos.push({
          id: Math.random(),
          title,
        });
      },
    };
  });

The models are observable, which means that if a component is marked as a MobX observer, it will automatically re-render when the model changes. You can combine MST with MobX to write reactive components without much code.

A good use case for MST is to store domain model data. It can represent relationships between objects (e.g. TodoList has many Todos, TodoList belongs to a User) and enforce these relationships at runtime.

Changes are created as a stream of patches, and you can save & reload snapshots of the entire state tree or sections of it. A couple use cases: persisting state to localStorage between page reloads, or syncing state to the server.

Benefits

The type system guarantees your data will be in a consistent shape
Automatic tracking of dependences means MST can be smart about only re-rendering the components that need to
Changes are created as a stream of granular patches
Simple to take serializable JSON snapshots of the entire state or a portion of it

Drawbacks

You need to learn MST’s type system
The tradeoff of magic vs. explicitness
Some performance overhead to patches, snapshots, and actions. If you’re changing data very rapidly, MST might not be the best fit.

Learn More

mobx-state-tree on Github
Official Getting Started Tutorial
Free MobX State Tree course on egghead by the creator

Recoil

Recoil is the newest library in this list, and was created by Facebook. It lets you organize your data into a graph structure. It’s a bit similar to MobX State Tree, but without defining a typed model up front. Its API is like a combination of React’s useState and Context APIs, so it feels very similar to React.

To use it, you wrap your component tree in a RecoilRoot (similar to how you would with your own Context Provider). Then create “atoms” of state at the top level, each with a unique key.

const currentLanguage = atom({
  key: 'currentLanguage',
  default: 'en',
});

Components can then access this state with the useRecoilState hook, which works very similarly to useState:

function LanguageSelector() {
  const [language, setLanguage] = useRecoilState(currentLanguage);

  return (
    <div>Languauge is {language}</div>
    <button onClick={() => setLanguage('es')}>
      Switch to Español
    </button>
  )
}

There’s also the concept of “selectors” that let you create a view of an atom: think derived state like “the list of TODOs filtered down to just the completed ones”.

By keeping track of calls to useRecoilState, Recoil keeps track of which components use which atoms. This way it can re-render only the components that “subscribe” to a piece of data when that data changes, so the approach should scale well in terms of performance.

Benefits

Simple API that’s very similar to React
It’s used by Facebook in some of their internal tools
Designed for performance
Works with or without React Suspense (which is still experimental as of this writing)

Drawbacks

The library is only a few months old, so community resources and best practices aren’t as robust as other libraries yet.

Learn More

Official docs
The conference talk where Recoil’s Creator Explains Recoil

react-query

React-Query stands apart from the others on the list becasue it’s a data-fetching library more than a state management library.

I’m including it here because often, a good chunk of the state management in an app revolves around loading data, caching it, showing/clearing errors, clearing the cache at the right time (or hitting bugs when it’s not cleared), etc… and react-query solves all of this nicely.

Benefits

Retains data in a cache that every component can access
Can re-fetch automatically (stale-while-revalidate, Window Refocus, Polling/Realtime)
Support for fetching paginated data
Support for “load more” and infinite-scrolled data, including scroll position recovery
you can use any HTTP library (fetch, axios, etc.) or backend (REST, GraphQL)
supports React Suspense, but does not require it
Parallel + Dependent Queries
Mutations + reactive re-fetching (“after I update this item, re-fetch the whole list”)
Supports cancelling requests
Nice debugging with its own React Query Devtools
Small bundle size (6.5k minified + gzipped)

Drawbacks

Could be overkill if your requirements are simple

Learn More

XState

This last one is also not really a state management library in the same sense as the others on this list, but it’s very useful!

XState implements state machines and statecharts in JavaScript (and React, but it can be used with any framework). State machines are a “well known” idea (in the sense of academic literature) that have been around for decades, and they do a very good job of solving tricky stateful problems.

When it’s hard to reason through all the different combinations and states a system can take on, state machines are a great solution.

As an example, imagine a complex custom input like one of those fancy credit card number inputs from Stripe – the ones that know exactly when to insert spaces between numbers and where to put the cursor.

Now think: What should you do when the user hits the Right Arrow key? Well, it depends on where the cursor is. And it depends on what text is in the box (is the cursor near a space we need to skip over? no?). And maybe they were holding Shift and you need to adjust the selected region… There are a lot of variables in play. You can see how this would get complicated.

Managing this kind of thing by hand is tricky and error-prone, so with state machines you can lay out all the possible states the system can be in, and the transitions between them. XState will help you do that.

Benefits

Simple object-based API to represent states and their transitions
Can handle complex situations like parallel states
The XState Visualizer is really nice for debugging and stepping through a state machine
State machines can drastically simplify complex problems

Drawbacks

“Thinking in state machines” takes some getting used to
The state machine description objects can get pretty verbose (but then, imagine writing it by hand)

Learn More

Official docs
free video course on egghead

“What About X?”

There are plenty more libraries I didn’t have space to cover here, like Zustand, easy-peasy, and others. Check those out though, they’re nice too :)

Tips on Learning State Management

Small examples are good for learning, but often make a library look like overkill. (“Who needs Redux for a TODO list?!” “Why did you use an entire state machine for a modal dialog?!”)

Large examples are good for seeing how to put a thing into practice, but are often overwhelming as an introduction. (“Wow, these state machine things looks WAAAY too complicated”)

Personally, when I’m brand new to a thing, I’ll start with the small “silly” examples first, even when my real goal is something bigger. I find it’s easy to get lost in the weeds with real-world examples.

Good luck on your own state management journey :)

React State Management Libraries and How to Choose was originally published by Dave Ceddia at Dave Ceddia on March 17, 2021.

State of the React Ecosystem in 2021

2021-01-20T18:30:28+00:00

What’s the best way to build React apps in 2021? What has changed since 2016? What libraries is everyone using these days?

This post is inspired by a now-deleted Reddit post from someone who had learned React in 2016, and was concerned about how to get back into it and refresh their skills.

I started using and teaching React in 2016 myself. Over the last few years, there have been some big changes in React itself, and the ecosystem has evolved quite a bit too.

Here’s where things stand in 2021.

Thinking in React: Pretty much the same

The core skill of “thinking in React” hasn’t changed much at all over the years. It’s still all about one-way data flow, props, state, and JSX. Things like being able to break a design into components are still crucial, as is deciding which components should “own” data and which should merely display it.

I still advocate for learning pure “vanilla” React before adding on a bunch of libraries.

Hooks vs Classes: Most new React components use hooks

In recent years, the biggest shift in React is from classes to hooks. Hooks were added in React 16.8 (Feb 2019), and have pretty quickly become the standard way that people write React components. You can check out the hooks intro I wrote back when they were first announced — they work the same now as they did then.

Initially, hooks look weird, especially if you’ve been programming a while. Variables that seemingly maintain state between function calls seem pretty magical. It’s more about arrays than magic, though.

Once you settle in with how hooks work, and get a feel for useState, the next big hurdle to overcome is the useEffect hook.

useEffect is the answer to how to do lifecycle methods in function components. Except it doesn’t really work the way lifecycles do, at all. It’s crucial to grasp the mental model of useEffect. Once you have that down, solving problems will get easier and easier.

The Best React Libraries in 2021

On the library front, community favorites have changed over the years, and continue to evolve.

Routing

React Router is still the dominant router (and despite the name, not actually part of React itself). It is currently up to v5 (almost v6) and the API has changed a bit since earlier versions. Less “declare your routes at the top” and more “routes are components; render them whereever”. The docs cover v5, and v6 has this preview blog. The v6 API is actually closer to v3, and having used it a bit, I think it will be a nice API.

State Management

Redux is still used in a lot of apps, hovering around 30-50% last I saw. The new official Redux Toolkit is excellent, too. It helps cut down boilerplate quite a bit, in combo with Redux’s hook. If you are going to use Redux, be sure to check those out.

Redux is less of the de-facto standard than it once was, though. More people are realizing that React’s built-in state management is enough for a lot of use cases, especially for simple ones.

There are also some newer purpose-built libraries for things that you might’ve used Redux for before. I’ll mention a couple below.

MobX is probably the most popular alternative to Redux outside of the built-in Context API. Where Redux is all about being explicit and functional, MobX takes the opposite approach. It uses ES6 Proxies behind the scenes to detect changes, so updating observable data is as easy as using the plain old = assignment operator.

I’ve used MobX State Tree on a project, and enjoyed working with it. It’s good if you have a lot of state to manage and want to create structure around it with models.

Recoil and Zustand are a couple other lightweight state management options.

There are, as ever, lots of choices in the realm of state management.

Context API

If your global state consists of a couple things that rarely change (current user, current theme, current language, etc), you don’t need a library to pass that stuff around.

The Context API + useContext are good for passing around simple global state managed by useReducer.

The Context API was re-done in React 16.3. The old contextType thing is out, and the old guidance about avoiding Context unless you’re a library maintainer has been gone for a while. The useContext hook makes it really nice to use.

There’s some long-standing confusion about whether to use Context or Redux, and what the differences are. Check out Mark Erikson’s blog post about Context vs. Redux for an in-depth comparison.

Data Fetching

On the data-fetching front, the strategy of putting everything in Redux or a global store is getting less common.

react-query does a good job at fetching data and managing loading/success/error states. It takes care of maintaining that global data cache across component boundaries without you really having to think about it. IMO it gets the abstraction right. Definitely worth a look.

Why react-query?

It’s less about the specific library and more about the pattern. (swr is another good option)

Take a common scenario like a ListPage / DetailPage for a set of items. You open the ListPage, it fetches all the widgets or whatever. Good so far.

Normally you’d probably keep that data around in Redux or something, so that when you click in to one of the DetailPages, that item has probably already been loaded. (oh! but what if the user loads a DetailPage route directly? welp, gotta fetch that item as a one-off)

And then the user clicks Back, and they’re back at ListPage again, but you already have the data so you can just display it.

It all works fine, but there are edge cases. What if an item went stale between the time the user loads ListPage and they click into a DetailPage? What if, while they were perusing the DetailPage, some new items were added to the list?

When should you re-fetch that data? And how do you deal with merging those two kinds of things – a list response that could maybe replace the whole list, and a single item response that should replace only one item? In Redux, the reducer handles that, but you’ve gotta write that stuff manually for the most part.

It all gets even more complex once you start thinking about pagination, and whether you want to cache pages, or refetch all the pages, or whatever.

All of this stuff, I think, falls under the “client data management” umbrella, and we’ve been using generic state management libraries for that for a long time now. And we have to solve these problems over and over again, or we ignore them and hope they don’t happen, or patch them as they crop up.

Libraries like react-query slice the problem up differently.

It knows you’re going to fetch data, and it knows you’re going to want to cache that data globally under some key (maybe items or a nested items[id]). It also knows that you’re going to want to update that data sometimes – based on a timer, or when the user tabs away from the app and back again, etc.

Because this stuff is stored in a globally accessible cache, every component that needs access can call useQuery('items', fetchItems) to grab that data, and it’ll automatically be fetched if it’s not already available. And it deals with idle/loading/error/success states too.

It takes any Promise-returning function, so it works with fetch or axios or whatever data fetcher you want to use.

This is what I meant when I said that I think it gets the abstraction right - we can use whatever we were already using to make the HTTP call, but react-query steps in to handle the oft-repeated heavy lifting that’s common to most data fetching use cases.

State Machines are Awesome

XState is a library for building state machines, which are excellent for representing complex logic. Actually, they’re pretty great for not-so-complex logic, too. Next time you find yourself juggling a bunch of boolean values or trying to update a bunch of variables in the right places, check out XState. egghead.io has a nice course on XState by Kyle Shevlin.

There’s an alternative called Robot and I wrote a tutorial using it to build a confirmation modal flow, if you want to get a feel for how state machines can be useful.

Bundlers

Webpack is still everywhere. It’s up to version 5 now. The config syntax changed a lot somewhere around v2 or v3.

Most people use Create React App to start new apps nowadays, which is great, and shields you from Webpack unless you really need to customize it. The defaults are pretty solid. If you need to customize things, check out craco.

For throwing together a quick demo, CodeSandbox is great, and they even have this handy https://react.new URL that’ll drop you right into a new project.

Forms

The story around forms has continued to evolve. I remember using redux-form years ago, and how the app would freeze every time I pressed a key 😂 Looking back, “keep every ounce of state in Redux” was never really a good idea.

Formik and react-hook-form seem to be the favorites right now, with hook-form gaining steam.

Suspense

React’s long-awaited Suspense feature is… still awaited. It’s in React right now, and you can try it out, but it’s in experimental mode and it’s not advisable to build production code with it. The API can still change.

Server Components

The latest advancement is components that render on the server, coupled with a server-side framework around React. These are still experimental too. Very cool though, and I suspect will change the ecosystem quite a bit. Check out the official announcement and demo video from the React team to learn more.

Now Go Build Something!

That about wraps this up. I’m sure I missed some things though. Feel free to chime in with your favorites in the comments!

State of the React Ecosystem in 2021 was originally published by Dave Ceddia at Dave Ceddia on January 20, 2021.

Using the image tag in React

2020-11-17T19:42:09+00:00

In React, image tags are a bit weird. This isn’t really React’s fault, but more a problem of where the images will reside on the server after the app is built.

I’m talking about the plain old <img src=""/> tag here. The same one you’d use in HTML.

When you img in a React component, the the src prop needs to be point at something that the server can serve.

Don’t Use a File Path From Your Computer

A common mistake for beginners is to set the src to a file path on their computer, like /Users/yourname/Projects/this-react-app/src/image.png. That won’t work.

Browsers are mostly sandboxed these days and won’t let you access files by their path on disk. If you did get that to work (maybe with file://), it’d break as soon as you deployed the app, because a web server won’t have that file in the same place! (And no, the solution is not to put it in the same place on the server :)

Two Ways to Include an Image in a React Component

With React, since there’s a build step, you need a way to include the image. There are 2 main ways to do that.

I’m going to assume a Create React App project here, where everything in the public directory gets copied to the server and everything under src is fair game for importing into JS files.

Option 1: `import` the image into the component

Put the image file somewhere under the src folder. This alone will not automatically make it available, so you have to import the image into the React component where you’re using it.

import companyLogo from './path/to/logo.jpg';

Then you can reference it by that variable name. The name can be anything you want, it doesn’t have to match the image or anything.

Wherever you want to display the image, render your img tag and pass that variable as the src:

function Home() {
  return (
    <div>
      <img src={companyLogo} alt="BigCo Inc. logo"/>
    </div>
  );
}

Note I’m using src={companyLogo} and not src="companyLogo"! If you use the quoted string "companyLogo" it will try to fetch a file at /companyLogo and that will fail. Make sure to use curly braces if you’re using an imported image. Curly braces are the way to pass JS variables as props.

Option 2: Put the image in the `public` directory

You can put the image file in the public folder (or if this is not Create React App… then any folder that will be copied to the server).

Then, assuming your server is treating the public folder as the “root” directory (/), then your images will be available relative to that – just like with plain HTML.

So if you had an image at public/images/thing.jpg, you could display that image this way:

function Home() {
  return (
    <div>
      <img src="images/logo.jpg" alt="BigCo Inc. logo"/>
    </div>
  );
}

Because this method makes the image available as a regular file on the web server, and you can test it by opening http://localhost:3000/images/logo.jpg in the browser (or, you know, your actual domain name, once it’s deployed!)

How Imported Images Work in React

First, know that imports are not handled by React at all – they’re handled by your bundler, which is probably Webpack. (if you’re using Create React App, it is definitely Webpack)

Webpack, Rollup, Parcel, and other bundlers all work conceptually the same way: when you import a static file, like an image or a CSS file, the bundler doesn’t literally paste that file in at the import location. Instead, it makes a note that this particular JS file depends on this particular image/CSS file/whatever.

Then the bundler will copy the image to the output directory with a generated unique name (like a5c8d3f89cad.jpg) and, behind the scenes, it will replace <img src={yourName}/> with <img src="a5c8d3f89cad.jpg"/>.

If the image is especially small, Webpack might even decide to inline it into the JS bundle, as an optimization.

This all happens without you having to worry about it.

The Best Way to Use the `img` tag in React?

For one-off images that are related to the component at hand, I like to import them. Imported images have the side benefit that, if the file is missing, the build will fail, and you’ll find out quick! For that reason, I lean toward importing an image if I’m going to use it.

For generic site-wide images, or where it would be annoying to manually import them, I’ll put them in public. This is especially useful when the React app is only a small slice of your overall site, and the same image should be used by both React and other non-React pages. In this case I’d rather avoid duplicating images (with the potential that the copies get out of sync).

Using the image tag in React was originally published by Dave Ceddia at Dave Ceddia on November 17, 2020.

Remove XML Tag Blocks from the command line with sed

2020-11-11T17:25:29+00:00

I had an xml file that looked something like this, and I wanted to remove all the <meta> tags from it:

<xml>
  <note>
    <to>A</to>
    <from>B</from>
    <meta>
      junk
    </meta>
    <meta>
      more junk
    </meta>
    <body>
      keep this
    </body>
  </note>
  ...
</xml>

The sed utility made quick work of it.

Some caveats: The file was already well-formatted, and these meta tags spanned multiple lines.

If your file is a jumbled mess, you might want to format it with prettier first.

Manipulating XML or HTML with tools like sed is not generally a great idea. For a general-purpose solution that can deal with all valid XML syntax you’d need a proper XML parser. But if your file is in the right shape, sed can be a quick and dirty way to get the job done.

Here’s the command I ran:

sed -i '' -e '/<meta>/,/<\/meta>/d' my-file.xml

The -i means “in-place”. It will change the file on disk. The '' is the name of the backup file – none, in this case. The Mac version of sed requires this name, though. If you’re on another system you might not need this.

The -e says to execute the regular expression that follows.

Let’s break down the expression: /<meta>/,/<\/meta>/d

The comma in the middle tells sed to look for a range of lines, and on either side of the comma is a regex. The d at the end means “delete this range”. Read about ranges in sed for more stuff you can do with them.

So we’re looking for lines starting with <meta> and ending with </meta>, and the slash needs to be escaped in the second regex, so we have /<\/meta>/.

Remove XML Tag Blocks from the command line with sed was originally published by Dave Ceddia at Dave Ceddia on November 11, 2020.

Run Code in React Before Render

2020-10-27T15:24:05+00:00

Want to run some code before your React component renders? There are a few ways to make this work, and we’ll talk about them here.

But, I have to warn you: Running code before render is usually a sign that you’re going against the grain of how React works.

TL;DR – There is no Before Render, only After

It makes perfect sense to think “I want to fetch data before my component renders”. Logical! But not how React works.

Here’s the thing:

React does not wait to render. Ever.

React will gladly kick off an asynchronous data fetch in the background, but then it will immediately proceed with rendering – whether the data has loaded or not. (and you can be almost certain that it will not have loaded yet)

There is no way to make it wait.

All is not lost, though. There’s an easy fix.

Components that render async data need to be prepared to render an empty state, at least once.

Think about what your app should look like before the data is ready. Maybe it’s empty, or maybe it’s a loading spinner, or some fancy skeleton state.

To embrace the way React works, kick off your data fetch after the first render, inside a useEffect block.

Just make sure to initialize the state to something that’s the same type as what it’ll eventually be!

Initialize State Before Render

Initializing state actually does run before the first render, and leaving it uninitialized is a common source of problems.

This leads to errors like Cannot read property 'map' of undefined' when the component tries to render before the data is ready.

If you have a call like useState() with nothing between the parens, that’s uninitialized (it’ll be undefined).

The rule of thumb is to initialize like-with-like: if the state will hold a string, initialize with a string. If it’s a number, init with a number. And so on.

Initialize Arrays

If you’re expecting an array from the server, initialize with an empty array.

const [items, setItems] = useState([]);

Initialize Objects

If you’re expecting an object, init with an object, or maybe null.

const [user, setUser] = useState(null);

Initialize State Lazily

If your init code has to do some heavy work, like mapping/filtering/reducing an array, you can wrap that initialization in a function and it will only run once:

const [products, setProducts] = useState(() => {
  return hugeListOfProducts.filter(isOnSale);
})

This is not a good place to fetch data or do anything asynchronous, though. Put async actions in a useEffect.

What Will Happen Before the Data is Ready?

Look through your code and make sure it won’t blow up if the data isn’t ready (if the value is null). Be especially careful if the data is initialized to or can become null or undefined!

return (
  <div>
    {user && user.name ? user.name : "Not loaded yet"}
  </div>
)

There are two new operators in ES2020 that can make this code simpler: optional chaining (?.) and nullish coalescing (??).

The optional chaining operator (?.) lets you safely access properties of an object that could be null.

return (
  <div>
    {user?.name || "Not loaded yet"}
  </div>
)

The nullish coalescing operator (??) returns the right-hand side when the left side is null or undefined. It’s useful in cases where you might normally use ||, like this:

return (
  <div>
    {user?.commentCount || "Not loaded yet"}
  </div>
)

This example has a bug – it will show “Not loaded yet” when commentCount is 0. Using the ?? operator instead of ||, it’ll work correctly:

return (
  <div>
    {user?.commentCount ?? "Not loaded yet"}
  </div>
)

?? works like the OR || operator, except that it doesn’t consider 0, '' or false to be falsy.

Fetch Data Before Render in the Parent

If you absolutely need to run some code before a component renders, then the solution is to avoid rendering that component at all, until you’re ready.

That means conditionally rendering it in the parent, which would look something like this. More detail in the comments:

function Child({ items }) {
  // Problem:
  // This will error if `items` is null/undefined
  return (
    <>
      {items.map(item => (
        <li key={item.id}>{item.name}</li>
      ))}
    </>
  );
}

function Parent() {
  // Uninitialized state will cause Child to error out
  const [items, setItems] = useState();

  // Data does't start loading
  // until *after* Parent is mounted
  useEffect(() => {
    fetch('/data')
      .then(res => res.json())
      .then(data => setItems(data));
  }, []);

  // Solution:
  // don't render Child until `items` is ready!
  return (
    <div>
      {items && <Child items={items}/>}
    </div>
  );
}

That’s It!

I hope that helps clear up some confusion around how to do things before mounting a React component. Just remember: There is no before, only after.

For a great deep dive into how React renders and re-renders, check out Mark Erikson’s guide to React rendering behavior.

Run Code in React Before Render was originally published by Dave Ceddia at Dave Ceddia on October 27, 2020.

Directly Open The Inspector Stylesheet in Chrome

2020-10-23T16:34:27+00:00

So you’ve added some styles to your page with Chrome’s dev tools. Awesome.

But when you click away from the element you’ve styled, the styles disappear from the sidebar! What if you were styling something that changes state, or left the DOM temporarily? How can you add on to those existing styles?

Turns out that styles you add in the Elements tab are automatically added to the inspector-stylesheet, and there are a couple ways to bring it up.

Click the `inspector-stylesheet` link beside the style

This method works great if you can see the style in the Elements sidebar.

Click the gray inspector-stylesheet link next to the style that you’ve added.

You can also create a new style (click the +) just for the sole purpose of getting the inspector-stylesheet link to appear, and then click the link.

In fact, this was the main way I got to the inspector stylesheet until I got fed up with that and decided to figure out where it is for real.

Inspector Stylesheet is in the Sources tab

The true home of the stylesheet is under the Sources tab. Open that up:

From here, look for the current page’s domain name in the list on the left.

If you’re doing local development, this will probably be localhost.

When I do this for my published site, I see the site’s domain twice. The first one is the original content that came from the server, and the second contains the inspector-stylesheet. You might have to hunt around a bit.

I’m guessing that if you added styles inside an iframe, the inspector-stylesheet would be under that iframe’s domain. I haven’t verified this though.

Have fun inspecting styles!

Directly Open The Inspector Stylesheet in Chrome was originally published by Dave Ceddia at Dave Ceddia on October 23, 2020.

Svelte with TypeScript and Jest (Starter Project)

2020-10-13T00:21:19+00:00

In the summer of 2020, Svelte added TypeScript support. Turning it on is as simple as running a single script! But the default starter project doesn’t have Jest testing set up.

I took the default Svelte starter with TypeScript and added Jest to it, along with a couple sample tests. The final project is here.

This was pieced together from info at the Svelte testing library docs, the Svelte Society repo’s testing recipes section, and the README for svelte-jester.

DIY or Use My Starter

If you want to apply the steps to an existing project of yours, or just to learn how it works, feel free to follow the steps below.

Or if you’re starting a fresh project and you just want to get going, you can clone my starter project that has all of this set up already:

npx degit 'dceddia/svelte-typescript-jest#main' your-svelte-project
cd your-svelte-project
npm install
npm test

(Don’t forget the quotes around the repo + branch name if you’re using Zsh)

You should see 2 passing tests, and be all ready to go!

Read on for the changes I made to get it working.

1. Clone the standard Svelte starter

The defacto standard way to start a new Svelte project is to use the degit tool to clone the repo while removing extra Git folders:

$ npx degit sveltejs/template svelte-typescript-jest

2. Setup Svelte + TypeScript

The official starter project can work in two modes: plain JavaScript (the default) or TypeScript.

To convert it to TypeScript, we can run the provided setupTypeScript.js to modify a few files and set up the build.

Switch into the project directory and run the script, then install all the packages.

cd svelte-typescript-jest
node scripts/setupTypeScript.js
npm install

3. Add Jest support, Testing Library, and svelte-jester

Here we’re installing a bunch of stuff:

jest to run the tests
ts-jest to let you write your tests in TypeScript
@testing-library/svelte for some useful functions to test your Svelte components with
@testing-library/jest-dom for handy DOM matcher functions like toBeInTheDocument
svelte-jester to compile Svelte components for Jest, so that Jest can use them
@types/jest to get TS to stop complaining about Jest’s globals like expect
babel-jest – optional – to let you write your tests in JavaScript
@babel/preset-env to go with babel-jest, also optional

npm install --save-dev \
    jest ts-jest \
    @testing-library/svelte @testing-library/jest-dom \
    svelte-jester @types/jest \
    babel-jest @babel/preset-env

4. Add `test` script to package.json

With this addition, you’ll be able to run npm test to run the tests, or npm run test:watch to run them & watch for changes.

package.json

{
  "scripts": {
    ...
    "test": "jest",
    "test:watch": "npm test -- --watch"
  }
}

5. Add the Jest config to package.json

We need to configure Jest to tell it what to do with .svelte, .ts, and .js files. If you only want to write test in TypeScript, you can skip the .js config.

This needs to be a top-level key in package.json, at the same level as “scripts” and “dependencies” and the others.

package.json

{
  "scripts": { ... },
  ...
  "jest": {
    "transform": {
      "^.+\\.svelte$": [
        "svelte-jester",
        {
          "preprocess": true
        }
      ],
      "^.+\\.ts$": "ts-jest",
      "^.+\\.js$": "babel-jest"
    },
    "moduleFileExtensions": [
      "js",
      "ts",
      "svelte"
    ]
  }
}

6. Create `svelte.config.js`

Make a new file at the root of the project named svelte.config.js and paste in this code.

svelte.config.js

const sveltePreprocess = require("svelte-preprocess");

module.exports = {
  preprocess: sveltePreprocess(),
};

The svelte-preprocess package comes by default with the Svelte starter project that we cloned, so we don’t need to install it.

I noticed that everything worked fine without this file until I added support for JS tests with Babel. So if you’re writing your tests in TS and skipping the Babel stuff, you might not need this.

7. Add jest to tsconfig.json

Open your tsconfig.json file, which should already exist since running the setupTypeScript.js script, and add this compilerOptions section.

tsconfig.json

{
  ...
  "compilerOptions": {
    "types": ["jest"]
  }
}

8. Create tests under `src/tests`

To verify that everything is working, create a src/__tests__/hello.test.ts file and paste this in:

Jest will look for tests under the src/__tests__ directory.

import { render } from "@testing-library/svelte";
import App from "../App.svelte";

test("should render", () => {
  const results = render(App, { props: { name: "world" } });

  expect(() => results.getByText("Hello world!")).not.toThrow();
});

Here we’re using the render function from testing-library to, well, render our Svelte component with some props. Then we check the rendered results to make sure the props we passed in did in face appear on the page.

9. Try it out!

All that’s left is to make sure everything worked. Run the tests, and you should see it pass:

npm test

Svelte with TypeScript and Jest (Starter Project) was originally published by Dave Ceddia at Dave Ceddia on October 13, 2020.

Dave Ceddia

Delete Git Branches That Have Been Merged

Script: Delete old git branches

How to Run SketchUp Make 2017 on an M1 Mac with macOS Monterey

Installing a Code Signing Cert from Sectigo (to sign an Electron app on Windows)

Implementing A Svelte Store In Rust

How Svelte Stores Work

The Important Thing is the Contract

Calling Rust From JavaScript

A Boilerplate Project with Electron, Rust, and Svelte

Beginning To End: How It Works

Security: Electron and contextIsolation

How the Rust Works

Interview Questions to Ask Your Interviewer

Interview Questions for Your Interviewer

More Resources

Attach VSCode Debugger to native Rust in an Electron app

Set up launch.json

pid vs processId vs processName

Connect the Debugger to Electron’s Renderer Process

Finding the Right Process

Use Activity Monitor / Task Manager

Set Breakpoints in VSCode

Example of Using napi-rs with Electron

A Minimal Project with Electron and napi-rs

Cargo.toml

build.rs

src/lib.rs

package.json

Release Build

Aside: index.js vs index.node?

Build index.node

Add the Rust module as a dependency

Expose the Rust module with preload.js

Why not to set nodeIntegration: true in Electron

The better way

Call the Rust code from Electron in renderer.js

It works!

…synchronously!

Help! Errors!

A missing package.json

Exporting incorrectly from Electron’s preload.js

Escape Liquid in ConvertKit (so you can use double braces)

Example of Escaping Double Braces in ConvertKit Liquid

Bonus: How to Write {% raw %} if you really really have to

How to Manually Symbolicate a Crash Log from a macOS App

1. Download the unsymbolicated crash report from Sentry.

2. Make a new empty folder

3. Open Xcode and the Organizer

4. Find the correct release

5. Copy files out of the release

6. Run the symbolicator tool

7. Run a script to automatically symbolicate everything

Now Go Debug!

Using Forms in React

How to Create Forms with Plain React

React Forms vs. HTML Forms

Two Kinds of Inputs: Controlled vs. Uncontrolled

Controlled Inputs

Uncontrolled Inputs

What is a “ref”?

Controlled vs. Uncontrolled: Which to Use?

When and Why to Use Controlled Inputs

Controlled Inputs are More Complex

Controlled Inputs Re-render on Every Keypress

Uncontrolled Inputs Don’t Re-render

Uncontrolled Inputs Can Have Even Less Boilerplate!

Accessible Form Labels

Label Next To Input (2 sibling elements)

Input Inside Label

Visually Hidden, But Still Accessible

Reduce Form Boilerplate With Small Components

Is It a Best Practice to Use Controlled Inputs?

Are Uncontrolled Inputs an Antipattern?

Go Make Forms!

ESLint + VSCode: How to Format Your Code Using .eslintrc

1. Install VSCode ESLint Plugin

2. Configure VSCode Settings to use ESLint for Formatting

Is the formatting still using Prettier?

How to Read React Errors (fix 'Cannot read property of undefined'!)

Security: Electron and `contextIsolation`

Set up `launch.json`

`pid` vs `processId` vs `processName`

Why not to set `nodeIntegration: true` in Electron

A missing `package.json`

Exporting incorrectly from Electron’s `preload.js`

Bonus: How to Write `{% raw %}` if you really really have to

Option 1: `import` the image into the component

Option 2: Put the image in the `public` directory

The Best Way to Use the `img` tag in React?