Sleep No More is an award winning theatrical experience that tells Shakespeare’s Scottish tragedy, through a darkly cinematic lens. The story unfolds through an awe-inspiring blend of acrobatic choreography, film noir soundtrack, and countless rooms of densely detailed atmosphere. Guests decide where to go and what to see, ensuring that everyone’s journey is unique, and each visit is different.

I researched it a tiny bit more and learned that it's best experienced without too much knowledge about what you'll experience – and I agree.

I was able to talk two other friends into going (not easy, as the price of admission is around $150) but that evening turned out to be the highlight of the trip - I even asked another friend and went again a few days later after digesting the first experience. We kept talking about it for days and it's still woven into my dreams to this day.

Some Spoiler-Free Tips

• Read at least a five-sentence summary of Macbeth. But be aware that Macbeth is just a framework and theme for Sleep No More.

• Consider taking one or two friends, but roam independently. You'll want to talk to someone after it.

• Try to guess a slow night and book the earliest slot (e.g. 7pm). My suggestions would be Sunday to Wednesday.

• Book “Oz’ Guest” (add $30) ticket for the expedited access line. It also will reserve you a seat a table at the jazz bar in lobby of the venue.

• Be there 15 minutes before your slot to be one of the first in the expedited access line.

• If you order a drink after you get to the lobby, be prepared that you might not get to drink it before being admitted into the experience (definitely go in as soon as you’re called). You might consider asking your waiter whether they can get you a water and whether you can pre-order something for after the show ends at 10pm. Consider leaving the alcohol for later to be alert for the experience.

• Optional: Consider wearing clothes that fit with the dark noir theme. But wear shoes that you can run in.

A few things that might make sense once you're in:

• Be curious and accept that you will miss things (the FOMO is strong here).

• Identifying some of the Macbeth characters will help you navigate.

• Don't be afraid of being a follower with a group of other people. Especially during the first hour where less people are in the building. But following a side character can be equally rewarding.

• Following loud music might lead you to interesting places.

Additional Reading

EDIT: Since the show has announced it's final final final extension, you might only able to see it once (if at all). So I strongly recommend making yourself familiar with the story.

You might also consider reading another spoiler-free primer for Sleep No More which has a bit more information.

from typing import NoReturn

def unreachable(v: NoReturn) -> NoReturn:
    raise AssertionError()

You can then use it with match (on Python 3.10) or is:

import enum

from .utils import unreachable

class Fruit(enum.Enum):
    APPLE = enum.auto()
    BANANA = enum.auto()

def using_match(fruit: Fruit) -> int:
    match fruit:
        case Fruit.APPLE:
            return 1
        case Fruit.BANANA:
            return 2
        case _:
            unreachable(fruit)

def using_is(fruit: Fruit) -> int:
    if fruit is Fruit.APPLE:
        return 1
    elif fruit is Fruit.BANANA:
        return 2
    else:
        unreachable(fruit)

But beware that this won't work for enums when using == as Mypy can't know whether the operator has been overridden:

def using_eq(fruit: Fruit) -> int:
    if fruit == Fruit.APPLE:
        return 1
    elif fruit == Fruit.BANANA:
        return 2
    else:
        # error: Argument 1 to "unreachable" has incompatible
        #   type "Fruit"; expected "NoReturn"  [arg-type]
        unreachable(fruit)

- const onClick = useCallback(() => console.log("Hello", name), [name]);
+ const onClick = useEvent(() => console.log("Hello", name));

Performance Optimization

When you're running into performance issues, you'll eventually discover the higher-order component memo (which is quite similar to the pre-hooks base class PureComponent). By default React will always re-render the whole subtree of a component. If one of the child components is wrapped in memo though, that component will (by default) perform a shallow equality check of its props, and prevent React from traversing the tree further if they didn't change.

Since this relies on shallow equality checks, you'll start using useCallback a lot:

function MyComponent({ name }) {
  const onClick = useCallback(() => {
    console.log("Hello", name);
  }, [name]);

  return <MyMemoButton onClick={onClick} />;
}

const MyMemoButton = memo(...);

Note how you have to pass name as a dependency here. If you didn't, then clicking the button would render a stale value: the first name that was passed to the component.

This feels very crufty and annoying, especially as the dependency list grows.

Habitual useCallback

Especially when you're working on a large application with many people, the churn when you eventually have to add memo to one component is high. You'll have to find and change all the places where props are passed to it to use useMemo or useCallback. If contexts are involved, it's even harder. It's also dangerously easy to cause a performance regression because someone passed another prop to your component and didn't make the effort to use useMemo.

The habit of using useCallback and useMemo means less churn, less regressions, less performance surprises, and less mental overhead while writing and reviewing code. You can even make this conventional, and enforce it to some extent with the jsx-no-bind ESLint rule in your codebase (which by default will not allowArrowFunctions).

Good Habit or Bad Habit

There are arguments to avoid useCallback and useMemo and only do this optimization once your app becomes slow.

The core arguments are that using them

1. makes code harder to write and read,

2. adds constant baseline cost (time and memory), and

3. adds variable memory cost (by unnecessarily holding references).

While (1) is absolutely true, (2) should be in the realm of nanoseconds and bytes, while (3) requires a bit more context:

When returning large, transformed objects from useMemo this is true. However in that case the calculation of that object was also probably expensive. So holding onto is also more likely to be preferable. When using useCallback for event handlers, they will be referenced by the DOM anyway.

If we can fix the developer experience of (1), then I'd happily accept (2) and (3) if I get a scalable application in exchange. Furthermore, it's not just about performance but also about side-effects. We'll get to that in a second.

Addressing the Developer Experience

If you have been using React for a while, you might remember that before we had hooks, this felt easier:

class MyComponent extends React.PureComponent {
  handleClick() {
    console.log("Hello", this.props.name);
  }

  render() {
    return <MyPureButton onClick={this.handleClick} />;
  }
}

With useEvent we get this experience back!

function MyComponent({ name }) {
  const onClick = useEvent(() => {
    console.log("Hello", name);
  });

  return <MyMemoButton onClick={onClick} />;
}

Side-Effects

Your codebase might have side-effects, often around data loading.

useEffect(() => {
  setOtherParties([]);
  api.listParties(date)
    .then(parties => parties.filter(b => b.host !== user))
    .then(setOtherParties);
}, [date, user, setOtherParties]);

Note how this effect triggers whenever the date or the user changes (for example when changing accounts). Extracting a predicate naively would lead to issues. Since filter is not stable, it would constantly cause the effect:

const filter = (party) => party.host !== user;

useEffect(() => {
  setOtherParties([]);
  api.listParties(date)
    .then(parties => parties.filter(filter))
    .then(setOtherParties);
}, [date, filter, setOtherParties]);

The exhaustive-deps ESLint rule (which does more than its name suggests) would call out that issue and encourage you to fix this by wrapping it in useCallback, like this:

const filter = useCallback((party) => party.host !== name, [name]);

If the name changes, the reference will change, and will cause the effect when intended. However, the lint rule can not check this across component boundaries!

Predicates, Setters & Loaders

In the situation above, useEvent would probably be wrong and a bug.

const filter = useEvent((party) => party.host !== name);

If you were to do the following, a change of the name would not cause the effect.

Effects & Events

If we look at a different example, something is wrong:

const greet = useCallback((name) => {
  console.log(lang == "es" ? "Hola" : "Hello", name);
}, [lang]);

useEffect(() => {
  greet(user.name);
}, [user]);

When the user changes, then a new greeting is emitted. But when the locale changes, the user is greeted again.

const greet = useCallback((name) => {
  console.log(lang == "es" ? "Hola" : "Hello", name);
}, [lang]);

useEffect(() => {
  greet(user.name);
}, [user]);

In this case, useEvent will give us the desired behavior.

But isn't this exactly like…

It might seem that useEvent might just be the same as some other hooks that we already have, but it's not.

// stable, but stale name on second invocation
const greet = useRef((name) => console.log(name)).current;

// stable, but stale name on second invocation
const greet = useCallback((name) => console.log(name), []);

// not stable
// useLatest coming from a library like react-use
const greet = useLatest((name) => console.log(name));

Closing Notes

So when do I use which? My rough guideline is that if a callback is named on..., handle..., dispatch..., set... and has no return value, it's a good candidate for useEvent. Otherwise there's a good chance it's more of a predicate or loader, in which case useCallback is the preferred choice still.

It would be great if the ESLint exhaustive-deps ESLint rule could treat return values of useEvent like useRef and know that they are stable, so that one doesn't need to include them in dependencies further down. I had to fork the ESLint plugin to make it do so.

As I went through our codebase, I found that I was able to change more than 90% of our useCallback to useEvent, reducing quite a bit of cruft. A great change!

React allows specifying a key property on a component. It lets React identify components and track their identities.

Iterating over Arrays

Imagine we have a stateful component EditableFruit that also has side-effects.

function EditableFruit({ value: initialValue }) {
  const [value, setValue] = useState(initialValue);

  useEffect(() => console.log("init", initialValue)); // "once" effect

  return <div>
    <label>{initialValue}</label>
    <input value={value} onChange={e => setValue(e.currentTarget.value)} />
  </div>
}

And a container that uses this component.

function Example() {
  const fruits = ["APPLE", "BANANA"];

  return <div>
    {fruits.map((fruit, index) => <EditableFruit key={SEE_BELOW} value={fruit} />)}
  </div>
}

We have a few options what to use for key.

Using a unique key

If each element has some key that is guaranteed to be unique (in this case fruit itself), always use that. When the order of the array changes, React will be able to re-associate the DOM elements and React components with the array items.

Adding an AVOCADO in the middle will log init AVOCADO. Everything "works" as one might expect.

Using the index

If no unique key exists, using the index might be the only option.

When you don’t have stable IDs for rendered items, you may use the item index as a key as a last resort.

However it means React won't be able to semantically identify elements which can lead to bugs, especially when the components contain state or effects.

Adding an AVOCADO in the middle will log init BANANA. The rendered inputs will contain the values APPLE, BANANA (!), and BANANA.

Because of this, the React documentation states that using index should be a last resort.

The ESLint rule react/no-array-index-key can detect this, forcing you to add an ignore if one really want to accept this risk. In the current codebase I'm working on (which is using TypeScript) we can use key={index!} to silence the linter.

Using the index joined with a (potentially) unique key

Using a key like ${fruit}-${index} will avoid the issue where state might be associated with the wrong component when just using index. However, this is a heavy shotgun comes at the cost of performance.

Adding an AVOCADO in the middle will log init AVOCADO and init BANANA. This makes sense when you look at what React has to do to determine the changes:

diff({
  from: ["APPLE-0", "BANANA-1"],
  to: ["APPLE-0", "AVOCADO-1", "BANANA-2"]
}) // { added: ["AVOCADO-1", "BANANA-2"], removed: ["BANANA-1"] }

There are situations where this might be acceptable, but I would be careful when performance is critical, especially when the array is large.

Not providing a key

Not providing a key is effectively the same as passing index.

The ESLint rule react/jsx-key can detect this forcing you to make a conscious choice.

Resetting a component's state

I sometimes find myself using key as a quick (and dirty) way to reset the state of a component, where I really want a big hammer.

function Example() {
  const [nonce, setNonce] = useState(Date.now());

  return <div>
    <Button onClick={() => setNonce(Date.now())} />
    <Universe key={nonce} />
  </div>
}