Forem: Lúcás Meier

React Pitfalls: useState initialization

Lúcás Meier — Thu, 09 Jan 2020 09:55:43 +0000

Summary

This is a quick post about a "gotcha" I encountered recently in a React application.
This involved the use of React's useState hook, which had a subtle difference
between how I thought the hook worked, and how it actually worked.

React Hooks

If you're already familiar with hooks in React, feel free to skip this section. This
is just a recap for those out of the loop.

Although the first real framework I worked with was Vue (I don't count the one application
I built with JQuery as having used a framework), I've been using React a ton lately, and
it's really been growing on me. There's a lot of advantages to being the "top dog" in the
framework game, and React's popularity gives you access to a large ecosystem, and great
patterns for working on frontend applications.

One thing I really like about React is the recent "hooks" feature.

Previously, react distinguished between function components, which took in some parameters,
called props, and returned some HTML to be rendered, e.g.

function TitleCard({ name }) {
  return <p>Hi my name is {name}</p>;
}

You also had class components, which at first resemble function components:

class TitleCard extends React.Component {
  render() {
    return <p>Hi my name is {this.props.name}</p>;
  }
}

But class components also have a lot of other features in addition to just rendering some data.
Notably, they have access to state:

class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = {count: 0};
  }

  render() {
    return (
      <div>
        <p>{this.state.count}</p>
        <button onClick={() => this.state.count++}>+</button>
      </div>
    );
  }
}

This component will render a count, and clicking on the button inside that component will increment
the state of that component.

Having a clear way to use state, and other effects like network requests, etc was something missing
from function components. That's where hooks come in. Hooks, in brief, allow you to use
these things in function components.

For example, if we wanted to take our Counter component from the previous example
using a function component with hooks, it'd look like this:

function Counter() {
  const [count, setCount] = React.useState(0);
  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount(c => c + 1)}>+</button>
    </div>
  );
}

The hook provides us with two values: count, and setCount. The idea is that
count always holds the current value of the state, and setCount allows us to change
this value. The cool thing is that React will always "do the right thing" and magically
update this value and rerender the component if necessary. Neat!

Rerendering

One of the core principles when working with React is that the framework strives
to make sure that the values a component logically has is always reflected on screen.
This means that if some value changes, because of a hook, or because one of the props changed,
then a rerender needs to happen to make sure that what's on screen matches what's "in the code".

For example, let's split our counter in two:

function ShowCounter({ count, setCount }) {
  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount(c => c + 1)}>+</button>
    </div>
  );
}

function Counter() {
  const [count, setCount] = React.useState(0);
  return <ShowCounter count={count} setCount={setCount}/>
}

Now the Counter component is the one actually holding the state, and the ShowCounter component
is just a simple function that shows the data given to it. In order to make sure that the user is
always seeing the actual value of the counter, React has to rerender the ShowCounter component
whenever the count passed to it changes value.

This means that React will end up executing the code of the ShowCounter function again. This
is why its important to avoid firing off network requests without useEffect inside
a function component, because you only want to do certain effects when they need to be run,
and not just when the component frivously rerenders.

State is initialised only once

Now we come to the main pitfall I want to talk about in this post.

Let's allow the user set a value for the counter:

function Counter({ initial }) {
  const [count, setCount] = React.useState(initial);
  return <ShowCounter count={count} setCount={setCount}/>;
}

Based on our previous model, if initial changes, then the component has to rerender,
and so useState gets called with initial, and so the count becomes initial, right?

Well it turns out that that's not what happens. In fact with the way useState works,
the initial value matters only the first time a component renders. After that, it will
preserve the state between renders.

This means that we need to do this instead:

function Counter({ initial }) {
  const [count, setCount] = React.useState(0);
  React.useEffect(() => setCount(initial), [initial]);
  return <ShowCounter count={count} setCount={setCount}/>;
}

We haven't gone over the useEffect hook in detail, but the way it works is that it executes
the callback function only if the values inside the array have changed. So here it will set the counter
to an initial value, but only when the initial value changes. This is the correct way to do
something like this.

Basically, to avoid this pitfall, you never want to have anything dynamic inside the call to useState.

Why is this the case?

Well, remember how we went over how React "tries to do the right thing". Well, it turns out that
by doing things this way, you actually preserve state between rerenders, which is generally the behavior you want.

For example, let's say we had something like this:

function Counter({ name }) {
  const [count, setCount] = React.useState(0);
  return (
    <div>
      <p>{name}</p>
      <p>{count}</p>
      <button onClick={() => setCount(c => c + 1)}>+</button>
    </div>
  );
}

Now we're showing a name in addition to the value of the count. We want to rerender if the count or the name
changes, since we want the user to see what the current value actually is, but we don't want the count to be
lost just because the name changed. That's why it makes sense for useState to preserve the
state between rerenders.

It'd require a lot more code to create the behavior of preserving state between rerenders if
it didn't work that way, but it didn't take much effort with useEffect to do what we wanted
in the other case. You generally want to try and make the more common use case easy
with frameworks, don't you.

Structured Immersion

Lúcás Meier — Wed, 08 Jan 2020 17:19:16 +0000

When it comes to language learning, one approach that I really subscribe to is immersion.
This means trying to absorb as much of the language as possible, as often as possible.
It's often said that "speaking with locals" is a good way to accelerate the learning process,
and there's a lot of truth with that statement.

Comprehensible Input

One aspect of immersion that's often overlooked is the idea of comprehensible input. The idea
is that the input you get in your target language is more useful if it's understandable despite
your lack of knowledge of some words or grammar. Those new language points can be assimilated because
the entire message remains comprehensible because of context, other language points you do know,
or other cues such as gestures or video.

For example, if you're trying to learn Japanese, watching anime can be great (provided you don't use subtitles),
because the language used can be simple enough to understand based on the visuals on the screen.
If you can guess what people would be saying with just a few key words, then that's a good candidate
for comprehensible input, even if you don't understand most of the actual Japanese.

Comprehensibility varies

Now, not all input is very good at being comprehensible. At the beginning, most native media
will be too difficult to be effective. If you only understand 10% of the sentences in some piece of media,
you're not going to be doing much learning with that source. Conversely, as you advance, media you completely
understand won't teach you new pieces of language, although it does help you solidify your understanding
of the language, and can help with things like pronunciation and choosing native-sounding phrasing.

Even worse is that it can actually be difficult to tell whether or not a piece of media is
at the right level before actually consuming it. Even if that piece of media is aimed at a native
audience with a similar language level to your own, it's possible that the topic might be one where
you're lacking a lot of vocabulary.

Context matters

For example, even if you've watched a lot of anime aimed at young teenagers, if you start watching
a piece of science fiction aimed at the same audience, it's possible to be lacking most of the vocabulary
they'll be using. The common, everyday phrases may be engrained, but space exploration / giant robot
jargon is likely to be completely lost on you.

Furthermore, if identifying whether or not a piece of media is going to make for good learning
is hard, then finding that media in the first place is even harder. Of course, my recommendation
would be primarily to focus on media you enjoy consuming anyways. After all, the point
of learning a foreign language as a hobby is to have fun, isn't it.

Even then, being able to organise the media you plan on consuming based on how appropriate
it would be for your level of language would help immensely in expediting the learning process.
If you could know which show to watch next based on what your current vocabulary is, that would
save a lot of time, and make immersing a lot easier.

With immersion, it's about quantity * quality, so you want to make it as easy as possible
to get a lot of good quality (i.e. level appropriate) media.

Tracking progress

One aspect of this problem that I've briefly gone over without expliciting is tracking your
progress. In order to provide such a structure, and know what media to consume next, you need
to keep good tabs on how much language you know, and the topics where your vocabulary is lacking.
Often people will use flashcard systems like Anki in order to keep track of their progress,
but mainly to remind themselves of old vocabulary to make sure they don't forget it. The problem
is that manual entries need to be created and entered into this flashcard system, even though media is often
consumed in a way where it could be entered manually.

Well, that's the introduction to some of the problems in the space of language immersion, and thankfully I think
a good deal of them can actually be addressed, thanks to the most media being digital nowadays.
Well, at least, the cheapest (free) and most easily accessible native media is going to be digital
and available on the internet.

An ideal immersion process

Ideally, here's what the daily immersion process would look like:

You arrive at the "dashboard" and have a list of media you can consume. You simply dedicate as much
time as you want that day to consuming it: you read and watch as much as you want to that day.
The media is recommended to you based on how appropriate it is for your immersion, given your current
language level. The media will have a right amount of new vocabulary and grammar to keep you stimulated
and learning, but not enough to drown you in unknown topics. Additionally, your progress is updated
based on that media you've consumed. There's no need to manually enter the new words or grammar points
that you learned.

Flashcard systems

Furthermore, the system can act as a flashcard system like Anki, where you automatically review the vocabulary
you previously learned, in order to make sure it stays fresh and accessible in your mind.
I won't go into the benefit of spaced-repetition systems like Anki, but for those that do benefit from them,
having automatic entries is indeed quite convenient.

I think that you could actually make a system providing that functionality to users.
You could keep track of a user's progress in their target language, and use that to source media
that they immerse in, and that you use to keep track of their ongoing progress.

The crux of this whole process is keeping track of a user's progress in a language. Without this
feature, none of the others are possible. All of those other aspects are consequences of exploiting
this key feature to the fullest extent.

Saving manual work

When a user sources new media for themselves, they're using their knowledge of their own progress
in order to judge whether or not that media is comprehensible enough for them. And when they're entering
new sentences into their flashcard system, they're copying over the new vocabulary from that media.
This is done, once again, using thier knowledge of their own learning process. By keeping track of
this progress in an automated fashion, we can in turn automate so many aspects of the immersion process.

Is this all just a pipe dream?

Now, that's a high level overview behind the idea behind such a system, but how feasible would
a system of this kind be? In all honesty, I'm not sure if this scales to any language. I'm not
even confident it would work as well for English as it would for Japanese. On the other hand,
Japanese is structured enough to make grammatical analysis quite easy.
Different langauges have different ways of building up sentences, which can make figuring out what
the user does and does not know in that sentence more or less difficult. Another difficulty relates
to figuring out what's comprehensible in a smart way, as we'll see later.

It might not be for Japanese

So, let's look at how realistic such a system could be, through the lens of Japanese.

Now, one of the core components of this system is figuring out what language concepts
are in a given sentence. Now, I've been using the sentence as a basic building block of media,
and it's a good unit for splitting large bits of text. Thankfully, Japanese sentences are marked by punctuation
in actual text, and multiple lines of dialogue are easy to split even without punctuation.

Luckily simple

Japanese morphology is simple, or regular enough in order to split sentences into words in quite a consistent
way. There are a handful of tools, but the one I've used most recently was
MeCab.

This tool takes the form of a command line program, that accepts a stream of sentences. The output of the tool
looks like this:

$ mecab
猫は食べた
猫 名詞,一般,*,*,*,*,猫,ネコ,ネコ
は 助詞,係助詞,*,*,*,*,は,ハ,ワ
食べ  動詞,自立,*,*,一段,連用形,食べる,タベ,タベ
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS

The first line is our sentence, "猫は食べた", literally "The cat ate". The next lines are the different words
MeCab managed to find throughout that sentence, along with their pronunciation, their part of speech, etc.
For example, the first word it gives us is "猫" meaning "cat". It tells is that it's a noun, pronounced "neko", etc.

Using MeCab, you can quite easily split native media into the words that compose it. This makes it easy to take all the "new" words
based on this classification, and add them to your flashcard system, along with the surrounding context.
Generally, you want the surrounding sentence for a given word in a flashcard system, but that's really another discussion entirely.

Except for grammar

One tricky thing that MeCab doesn't take care of, and that I haven't completely looked into solving is figuring out what grammatical
components figure in a given sentence. As we've just seen, it's quite easy to get the words in a Japanese sentence out, but it
seems much harder to get grammar out. There are some things you can do. For example, that last sentence used the past tense,
and MeCab considers the past conjugation to be a word, for some reason, so you can pick up on cues like that.

What is comprehensible enough?

Now, another problem is when to consider a piece of media suitable for consumption. Taking a sentence based approach seems
appropriate at a first glance. That is to say, we can classify each sentence with a certain comprehensibility score,
and then aggregate that score throughout the whole text, to get an overall score. We can then use that score to
rank the different pieces of media we've managed to source previously. We would also reject pieces of media
that are too comprehensible.

One simple metric would be to look at what percentage of words are known in a given sentence the user knows.
The problem with this metric comes from its simplicity: it doesn't take into account the surrounding context,
nor how easy some words are to guess. I don't have many ideas for the time being to go beyond this simple metric
however.

User input

Other approaches could include user input on whether or not they understood a sentence despite not knowing the
words in that sentence. You could use that to suggest similar sentences.

That being said, even a simple metric would help immensely in ranking texts, as comprehensibility doesn't need to
be exact to be beneficial. Even ranking materials just on the words you don't know would help immensely with triaging
all the media you have available.

Sourcing media

Now we come to the problem of sourcing media.

An advanced approach would be to scrape the web for material and build up a gigantic database of native media.
Although impressive and expansive, this approach would also be expensive, and fail to satisfy a key criteria:
providing media the user is actually interested in.

As mentioned before, having media the user actually wants to consume is actually important in keeping the
language learning process from becoming a long march of boredom.

Accepting user submissions

An easier approach that also satisfies this criterion is accepting texts from user input. The user can submit
text from subtitles or books they're reading, along with whatever sources they want to consume eventually.
The system would also need to keep track of the order of certain texts, because for certain things, like books, you might
want to read them in a linear order. In order to help with the fun of immersion, you want to respect ordering like this.
Respecting the chronological order of media also helps with understanding that media. Obviously,
for serial media, understanding the story requires having understood most of the previous parts
of the story.

This approach is also easier, because we don't have to worry about sourcing the material, and can instead
rely on the user providing us with material on their own. This is similar to how works,
where you enter text into their site, and then it augments it with dictionary entries and what not.

Presenting media

Another thing I'd like to touch on is how you present this media to the user. One disadvantage to this text based
approach is that the user has to read. What you get out of it is that you can track the progress
of the user in the media, and thus enter these new words automatically.

Augmented immersion

When presenting text to the user, you can augment it without know the user's progress, adding
things like an automatic dictionary, sentence, copying, etc. You can use the user's progress to highlight words they
don't know. You can add the words they read to the flashcard system. You can also take into account their use
of the built-in dictionary while reading the text in order to update the flashcard system.
If they've looked up a word, they don't know it as well as previously thought, so that word needs to be bumped
up the flashcard stack.

You could also just rank the pieces of media, and then let the user read them on their own time.
The disadvantage there would be losing the augmented reading experience, as well as not being able
to automatically track progress. For example, if the user is reading a novel through the augmented
portal, you can track their position and language progress through the book. If they read it on their own,
you don't know how far they've gotten to the book. You could let them tell you when they've finished the whole
book, but adding that large chunk of language after the fact isn't as useful.

Conclusion

To wrap things up, I think that immersion is very important for learning a foreign language, and that
making immersion as easy as possible helps making learning even easier. Having a system that
keeps track of your progress in a language can help save you time in learning and revising vocabulary,
and can help triage and augment the immersion process.

React, Typescript, Parcel: Setting up Hot Module Reloading

Lúcás Meier — Mon, 25 Nov 2019 21:24:47 +0000

Recently I had to setup a new greenfield project using React and Typescript. I'm a big fan of using parcel over other bundling tools like webpack. Parcel usually works with essentially no config whatsoever, and ends up being much simpler.

I did run into a few issues getting hot-module-reloading to work, so that's why I'm writing up this short post.

What is HMR?

Hot-module-reloading lets us change the code of our application while maintaining our current state and position in the website. This allows us to do things like tweak the styling of some page of our app without having to navigate all the way back to that page each time. This helps immensely when prototyping and developing an application.

Setting up a basic build

After creating an empty directory to set up the project in, we need to run a command to create an npm project:

npm init

After following the instructions in this command, you'll have a package.json file with metadata.

Essential packages

Now it's time to install the packages we'll end up using in the actual application. There are other packages we'll use as a developer, but that the end-user doesn't actually need.

npm install react react-dom

The first package is React, of course, which happens to be our framework of choice. react-dom is necessary for rendering in the browser.

Developer packages

Now we install all the tools we'll be using to develop.

npm install --save-dev parcel-bundler typescript @types/react @types/react-dom

We use --save-dev to make sure that these won't end up in the code that we end up shipping in production.

We can setup the typescript compiler with the following command:

npx tsc --init

We then need to add the following line:

"jsx": "react"

in order to get the Typescript compiler to handle our React html correctly.

Creating the basic frontend

Now we need to create a basic UI to test out the packages we've installed:

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="generator" content="parceljs" />
  </head>
  <body>
    <div id="root"></div>
    <script src="./index.tsx"></script>
  </body>
</html>

This file contains the basic HTML for our website. React will be filling in the rest, starting from the element with id root. We reference our main typescript file, which will be like this:

index.tsx

import React from 'react';
import ReactDOM from 'react-dom';
import App from './components/App';

ReactDOM.render(<App />, document.getElementById('root'));

Here we render our main App component in the element with id root. The component is defined like this:

components/App.tsx

import React, { FunctionComponent, useState } from "react";

const App: FunctionComponent = () => {
  const [count, setCount] = useState(0);
  return (
    <>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>+</button>
    </>
  );
};
export default App;

Understanding everything going on here isn't important, all that matters is having a component with a bit of state (here, the current count) so we can see whether or not HMR works. This component is just a counter we can increment with a button.

Bundling

Now, we can bundle and serve the app by adding the following script to package.json:

"scripts": {
  "dev": "parcel index.html"
}

Now in order to start up a development server, we just run npm run dev. Parcel will magically figure out how to bundle everything based on the imports in the files themselves, without any configuration from us.

We can now navigate to our frontend at http://localhost:1234 in our browser (or whatever else parcel tells us).

We should see something like this:

Now, if we change the following line in App.tsx to:

<p>The Count: {count}</p>

the entire page reloads, and the count is lost, before we see our change. This isn't ideal, because we might want to be styling or editing the logic for a specific state. Having to reset the state manually each time is a pain. This is where HMR is useful.

Setting up HMR

We first need to install a package for hot module reloading in React.

npm install --save-dev react-hot-loader

We only need this in development, hence --save-dev.

We now need to modify the root component of our app, in App.tsx:

import { hot } from 'react-hot-loader';
...
declare const module: any;
export default hot(module)(App);

This only needs to be done to the top-level component, as we add more components they can be written normally.

With this simple change, we now have HMR! In order to test this out, try incrementing the counter, and then changing the text in the component. The counter's state shouldn't change even as the text does. This is HMR in action.

Repo

I've hosted the code for this demo here

Data Races vs Race Conditions

Lúcás Meier — Mon, 01 Jul 2019 16:54:29 +0000

This is a quick post about the difference between Data Races and Race Conditions, and how data structures or patterns providing freedom from data races can fail to provide race condition freedom.

The examples will be given in Go, since that's a language with a few
of the concurrent constructs that come into play here, as well as the language that sparked this blog post in the first place.

Data Races

I agree almost entirely with
rust's definition of data races. Under this definition, a data race is when one or more threads concurrently access a location in memory / variable, at least one of which is a write, and at least one of which is not synchronized with other threads.

For example, multiple concurrent reads to an unsychronized variable are perfectly
fine:

const a = 3

func main() {
    go func() {
        fmt.Printf("Thread B: %d\n", a)
    }
    fmt.Printf("Thread A: %d\n", a)
}

Even though the order of printing will vary from execution to execution, there are no data races since both threads are merely reading from the data.

If we now have one of the threads access a mutably, we introduce a data race:

func main() {
    a := 3
    go func() {
        a = 10
    }
    fmt.Printf("Thread A: %d\n", a)
}

We can solve this by introducing a mutex to synchronize access to a:

func main() {
    a := 3
    var m sync.Mutex
    go func() {
        m.Lock()
        a = 10
        m.Unlock()
    }
    m.Lock()
    fmt.Printf("Thread A: %d\n", a)
    m.Unlock()
}

Both threads are accessing a at the same time, and one of them is writing, but since the access is synchronized, this is no longer a data race.

Race Conditions

Race conditions stem from non-determinism in concurrent programs. In theory any observable non-determinism from concurrency could be considered a race condition, but in practice what constitutes a race condition depends on what properties we want our program to respect.

Let's take the following program as an example:

func main() {
    go func() {
        for {
            fmt.Println("Thread B")
        }
    }
    for {
        fmt.Println("Thread A")
    }
}

We'll see some sort of random interleaving of the two messages:

Thread A
Thread A
Thread B
Thread A
Thread B
Thread B
...

This could be considered a race condition, if the exact order of the printing was a property we wanted our program to respect. We could use some form of synchronization to enforce that order of printing.

In practice we wouldn't consider this a race condition even if the execution isn't deterministic, because this isn't a property we care about.

In summary, a race condition is some violation of the properties our program should have arising from the concurrent execution of the program.

Race Conditions without Data Races

The reason I decided to make this post was a discussion I had recently. Someone was claiming that using Go's channels prevents race conditions because the operations are always thread safe.

It is true that Go's channels are free from data races, so long as memory isn't shared in other ways. That being, said it's pretty easy to write a program that has a race condition despite only using channels.

In this example, we'll have a simple server responding to requests to get the value of an integer, and to set the value of an integer.

The messages look like this:

type msg struct {
    id int
    amount int
}

We'll use 0 as the id for get and 1 as the id for set.

Our server type will look like this:

type server struct {
  msgs chan msg
  resps chan int
}

func newServer() *server {
  msgs := make(chan msg)
  resps := make(chan int)
  return &server{msgs, resps}
}

We have a channel to be able to send and receive messages for the server, as well as a channel for the responses to those messages.

Our server will start in the background with the following function:

func (s *server) start() {
  state := 0
  for {
    m := <-s.msgs;
    if m.id == 0 {
      s.resps <- state
    } else {
      state = m.amount
    }
  }
}

We respond to get requests by sending back the current state, and to set requests by setting the concurrent state. Since only one thread is in control of the state, interactions with the server are free from data races.

The basic operations with our server look like this:

func (s *server) get() int {
  s.msgs <- msg{0, 0}
  return <-s.resps
}

func (s *server) set(amount int) {
  s.msgs <- msg{1, amount}
}

Now with those basic operations, we can define the following function:

func (s *server) increment() {
  x := s.get()
  s.set(x + 1)
}

This function simply increments the state.

In our main function, we can do the following:

func main() {
  s := newServer()
  go s.start()
  for i := 0; i < 200; i++ {
      s.increment()
  }
  fmt.Println(s.get())
}

This will perform 200 increment operations, leaving the state at 200, as expected.

But if we start sharing these operations between threads, we'll notice a race condition:

func main() {
  s := newServer()
  go s.start()
  go func() {
      for i := 0; i < 100; i++ {
          s.increment()
      }
  }
  for i := 0; i < 100; i++ {
      s.increment()
  }
  fmt.Println(s.get())
}

We would expect to see 200, as before, but in practice we'll see a smaller number. This is a race condition. This happens because 2 threads can get the same value before setting the next one, and then both will set the same value, leading to 2 calls to increment only performing a single increment.

Simple fixes are not enough

What we want is an atomic operation. In this case an atomic increment.
An atomic increment would mean that each increment happens as a single step,and thus prevent two concurrent increments from only leading to a single operation.

We could add such an operation to our server with an additional message,
let's say with id 2:

else if m.id == 2 {
    state++
}

The problem is that the following function still wouldn't be atomic:

func (s *server) doubleIncrement() {
    s.increment()
    s.increment()
}

No matter what set of atomic operations our server provides for its state, we can't simply perform multiple operations in sequence, in an unsynchronized manner, and expect the result to also be atomic.

The full code for this example can be found here:
https://play.golang.org/p/995MLEiqIVV

Summary

Data races should not be conflated with race conditions. Just because
a data structure provides data race free operations, doesn't mean that race conditions can't happen with that data structure. Furthermore, sequencing atomic operations does not yield an atomic operations.

Designing concurrent programs without bugs is not trivial, and becomes
even more complicated once you start working with multiple computers.

Forem: Lúcás Meier

React Pitfalls: useState initialization

Summary

React Hooks

Rerendering

State is initialised only once

Why is this the case?

Further Reading

Structured Immersion

Comprehensible Input

Comprehensibility varies

Context matters

Tracking progress

An ideal immersion process

Flashcard systems

Saving manual work

Is this all just a pipe dream?

It might not be for Japanese

Luckily simple

Except for grammar

What is comprehensible enough?

User input

Sourcing media

Accepting user submissions

Presenting media

Augmented immersion

Conclusion

React, Typescript, Parcel: Setting up Hot Module Reloading

What is HMR?

Setting up a basic build

Essential packages

Developer packages

Creating the basic frontend

Bundling

Setting up HMR

Repo

Data Races vs Race Conditions

Data Races

Race Conditions

Race Conditions without Data Races

Simple fixes are not enough

Summary