DEV Community: Andrey Okonetchnikov

Before you useState

Andrey Okonetchnikov — Fri, 11 Jun 2021 08:14:00 +0000

Imagine, you are on this amazing website that has lots of filters and you just nailed down a combination that yields perfect results and you would like to share it with your partner. You hit the "Share" button and send it over. Then the other person opens it only to see... the default page instead of filtered results. Everyone hates it! Yet we, Frontend developers, are the ones who screwed up by treating our applications' state as something that only belongs to the application and burring it in useState calls or in the Redux store. Luckily, we are the ones who can fix it!

Simply `useState`

While implementing a filter for a list of items based on a user input, most of you would probably do something like without even thinking twice (at least I did so many times!):

import * as React from "react";

const options = ["Apple", "Banana", "Cherry"];

export default function App() {
  const [query, setQuery] = React.useState(""); // set the initial state
  const results = options.filter((option) => option.includes(query)); // filter results using the state
  const handleChange = (e) => setQuery(e.target.value); // update the state based on the new value
  return (
    <>
      <input type="search" value={query} onChange={handleChange} />
      <ul>
        {results.map((result) => (
          <li key={result}>{result}</li>
        ))}
      </ul>
    </>
  );
}

Open on CodeSandbox

This does the job and gives you the user interface we wanted but the state is now not accessible by the user. You can't share the URL with another person and they won't be able to see what you saw.

Sharing the state with the user

People start using your UI and get annoyed by the fact links aren't sharable. So you decide to implement this feature on top of the existing code base. It will probably will look like this:

import * as React from "react";

const options = ["Apple", "Banana", "Cherry"];

export default function App() {
  const queryParams = new URLSearchParams(window.location.search); // get query string from the location
  const [query, setQuery] = React.useState(queryParams.get("query") ?? ""); // set the initial state to it
  const results = options.filter((option) => option.includes(query)); // filter results using the state
  const handleChange = (e) => setQuery(e.target.value); // update the state based on the new value
  return (
    <>
      <input type="search" value={query} onChange={handleChange} />
      <ul>
        {results.map((result) => (
          <li key={result}>{result}</li>
        ))}
      </ul>
    </>
  );
}

Open on CodeSandbox

Better! We can parse the URL and set the application state to reflect it but it actually doesn't update the URL as you change the input's value while typing. Let's fix it!

Reacting to the user input

import * as React from "react";

const options = ["Apple", "Banana", "Cherry"];

export default function App() {
  const queryParams = new URLSearchParams(window.location.search); // get query string from the location
  const [query, setQuery] = React.useState(queryParams.get("query") ?? ""); // set the initial state to it
  const results = options.filter((option) => option.includes(query)); // filter results using the state
  const handleChange = (e) => setQuery(e.target.value); // update the state based on the new value

  // Now that we have the new state, let's sync it with location
  React.useEffect(() => {
    // Calculate new URL based on the state
    queryParams.set("query", query);
    const newURL = "?" + queryParams.toString();
    // Update the URL in the location
    window.history.pushState({}, undefined, newURL);
  }, [queryParams, query]);

  return (
    <>
      <input type="search" value={query} onChange={handleChange} />
      <ul>
        {results.map((result) => (
          <li key={result}>{result}</li>
        ))}
      </ul>
    </>
  );
}

Open on CodeSandbox

Phew! It works but look at that code! But wait, maybe we could do better?

Use URL instead of `useState`

Think about what we're trying to do:

Derive the state from the URL
Set it as a default value of the useState call
Update the React's state in the onChange event handler using the setter function
Derive the new URL in the useEffect
Set the location to the new URL so it's in sync with the UI

What if we would treat the URL as our state container? This way we could bypass the local state completely. Here is the updated algorithm.

Derive the state from the URL
Update the location in onChange callback to keep it in sync with the UI

import * as React from "react";
import { navigate } from "@reach/router";

const options = ["Apple", "Banana", "Cherry"];

export default function App() {
  const queryParams = new URLSearchParams(window.location.search); // get query string from the location
  const query = queryParams.get("query") ?? ""; // get the query value
  const results = options.filter((option) => option.includes(query)); // filter results using the state
  const handleChange = (e) => {
    queryParams.set("query", e.target.value); // update the state based on the new value
    // Calculate new URL based on the state
    const newURL = "?" + queryParams.toString();
    // Update the URL in the location
    navigate(newURL);
  };

  return (
    <>
      <input type="search" value={query} onChange={handleChange} />
      <ul>
        {results.map((result) => (
          <li key={result}>{result}</li>
        ))}
      </ul>
    </>
  );
}

Open on CodeSandbox

Much simpler! But most importantly, not only we improved our code, but also we made our application more accessible: each filter result is now sharable using a simple link!

Final result

https://codesandbox.io/embed/before-usestate-3-jv118?autoresize=1&codemirror=1&fontsize=16&module=%2Fsrc%2FApp.js&theme=dark

Gotchas

There are a few gotchas I've discovered while implementing my state this way:

Although browsers' native History API gives a simple way of modifying the state using pushState(), it won't trigger a re-render of the React app. That's why in my last example I use @reach/router. Since most popular React frameworks like Next.js or Gatsby already have a router as a dependency, I don't consider this a problem.
Second problem is: updating the location via a router will scroll the page to the top by default in most browsers. Most of the time it shouldn't be a problem since this is desired to see top results. Depending on the layout of the page and device's resolution, though, it can be annoying. In this case there are ways of disabling it:

Prevent scroll in Next.js

const handleChange = (event) => {
  router.replace(
    {
      query: {
        q: event.target.value,
      },
    },
    undefined,
    {
      scroll: false,
      shallow: true,
    }
  )
}

Prevent scroll in Gatsby

export const shouldUpdateScroll = ({ routerProps: { location } }) => {
 return location.search === "" // Scroll to top only when we're not searching
}

Last but not least: changing the URL will re-render the whole application which can cause some performance problems for bigger and more complex applications. In this case, synchronizing the URL with the state is the only solution for now. With the concurrent mode, though, it might become much less of a problem and that's how I think frameworks should deal with complexity: developers should write the most idiomatic code and let frameworks do optimizations under the hood.

Conclusion

Next time, before you useState, stop for a second and think about your state. Most applications' state deserves to be shared with your users, so treat it as something public and put it into URL from the beginning. It will make your app more accessible and easy to use and it will make the code much simpler. A win-win situation!

P.S.: Even if you can't implement the final solution for some reason now, I still encourage you to think about the URL as an additional user interface to interact with the website and expose as much as possible to allow such interactions.

NetlifyCMS with GitHub OAuth authentication hosted on Vercel

Andrey Okonetchnikov — Sun, 23 May 2021 20:05:53 +0000

Recently, I was moving www.danielamulle.at to Vercel while transitioning to Next.js from Gatsby. The transition went quite smooth in general, but one thing I didn't expect troubles with was making NetlifyCMS work on Vercel.

NetlifyCMS is a great headless content management system that has good defaults, is flexible enough to fulfill most needs, has a pluggable API, and works well if you host your content on GitHub. I have also contributed to the project when it was at the very early stage. For obvious reasons, Netlify CMS works really well when you host on Netlify but unfortunately things become a bit more complicated if you decide to move to another hosting provider.

This is due to a requirement of GitHub’s authentication flow. To use a GitHub backend with NetlifyCMS, you have to run your own server to handle OAuth or use serverless provider like Vercel.

Netlify substitutes the need for the server and makes it work out-of-the-box but it also might feel like a verndor lock-in. Fortunately, there are open source solutions that implement everything needed but setting everything up can take some time. This is a step-by-step guide of things that worked for me.

Step 1. Configure Netlify CMS

Put you config.yml file to /public so it's accessible by NetlifyCMS when deployed to production. Open the file and additionally to your existing config you need to:

Set repo to your GitHub repo that contains the source code of your site.
Set base_url to the production domain with HTTPS protocol, for example, https://www.danielamulle.at in my case.
Add auth_endpoint: api/auth. This is the URL that NetlifyCMS will open when you click "Authenticate" button. We'll implement this endpoint in our next.js app later.

I've also enabled local_backend: true in the config to make CMS work with the local git without going over the server when in development mode. You can read about making NetlifyCMS to work with a local git repository.

Step 2. Create GitHub App

Go to GitHub and navigate to Settings → Developer settings → GitHub Apps → New GitHub App or use this direct link.

It's not important how you'll name the app since it will not be published. Fill User authorization callback URL with the URL https://<domain>/api/callback. Use exactly the URL that you entered as base_url at the previous step.

Disable Webhook checkbox and set permissions to Read & Write for "Contents":

Hit "Create app" and on the next page you'll see the app details with Client ID and Client secret. We will need those on the next step.

Step 3. Set environment secrets

Add those values to Vercel environment variables:

vercel env add secret OAUTH_CLIENT_ID <client-id-of-GitHub-App>
vercel env add secret OAUTH_CLIENT_SECRET <client-secret-of-GitHub-App>

Step 4. Setup OAuth client in Next.js app

Install https://github.com/bericp1/netlify-cms-oauth-provider-node as a dependency to your project:

npm install netlify-cms-oauth-provider-node

and create a .env file to add following configuration options:

OAUTH_CLIENT_ID=
OAUTH_CLIENT_SECRET=
COMPLETE_URL=https://<domain>/api/callback
ORIGIN=<domain>

where <domain> is your domain without https. It's important to match COMPLETE_URL here and in the GitHub App so make sure they are the same.

Then create 2 files: /src/pages/api/auth.js and /src/pages/api/callback.js

import { createVercelBeginHandler } from "netlify-cms-oauth-provider-node"

module.exports = createVercelBeginHandler({}, { useEnv: true })

import { createVercelCompleteHandler } from "netlify-cms-oauth-provider-node"

module.exports = createVercelCompleteHandler({}, { useEnv: true })

After that, push the code to production branch on Vercel and wait till it's deployed. Navigate to your site and go to the CMS URL. You should be able to authenticate with GitHub now.

Credits

Huge thanks to @bericp1 for https://github.com/bericp1/netlify-cms-oauth-provider-node and @robinpokorny for https://github.com/robinpokorny/netlify-cms-now. Robin's solution didn't work for me but it led me to the right direction.

Running Node.js natively on Apple Silicon

Andrey Okonetchnikov — Thu, 14 Jan 2021 21:35:55 +0000

I just got the one of the newest M1-based MacBooks and I wanted to get it up and running as fast as possible so I went with the Migration Assistant and migrated everything from my old MacBook Pro 2017 running macOS 10. To my surprise it worked without any issues at all (I would expect at least it requires same OS versions).

Although it already felt much faster than my previous machine even running most of the software through Rosetta 2 emulation mode, I was still curious: how much faster it actually is when running things natively.

Since the existing Homebrew installation wouldn't allow my updating or installing packages anymore because of more restrictive OS permissions, I was faced with "update the x86 homebrew" or “use an experimental cutting-edge ARM build”. I went with the latter and this post summarizes my experience.

Step 0. Remove x86 zsh binary

One of the biggest confusion for me was the fact my shell would not run in arm64 mode. This was caused by the fact I already have been using zsh shell before and it was migrated over. The new macOS Big Sur comes with zsh as a default shell so you don’t need to install it separately anymore.

https://twitter.com/okonetchnikov/status/1343140569430822914

To solve this issue I had to remove x86 compiled zsh that I installed via Homebrew. This cannot be done with brew remove since Homebrew won’t have enough permissions but you can remove zsh manually:

// 1. verify you're not running native zsh

which zsh

// 2. if it is different from /bin/zsh, run

rm "$(which zsh)"

Verify by opening a new terminal session and running arch.

➜ arch
arm64

Step 1. Install Apple Silicon version of the Homebrew

To install the ARM version of Homebrew on the Apple Silicon Mac, I used the manual "untar anywhere" method: https://docs.brew.sh/Installation#untar-anywhere

Starting from version 2.7.1, Homebrew supports Apple Silicon out-of-the-box.

This method allows installing Homebrew alongside with the x86 version which is probably a good idea for a time being since not all packages are yet pre-built for ARM. I had a few issues while building from sources, too.

After installing Homebrew into separate directory, add the following to your .zshrc file

# Support for two Homebrew installations
export PATH="/opt/homebrew/bin:/usr/local/bin:$PATH"
alias ibrew='arch -x86_64 /usr/local/bin/brew'

After that you can use both arm64 and x86 installations of Homebrew side-by-side.

For more information on Homebrew compatibility on Apple Silicon check out https://github.com/mikelxc/Workarounds-for-ARM-mac and https://soffes.blog/homebrew-on-apple-silicon

Step 2. Install node and yarn

After you have installed Homebrew, install node (which includes npm) normally running brew install node Install Yarn using brew install yarn.

To verify that you're running the Node in ARM architecture, enable the row "Architecture" in Activity Monitor,

Enable "Architecture" column with the right-click on the header. If node processes say "Apple" you're running them natively!

Step 3. Install packages to run Gatsby

After running Node natively I had issues running Gatsby project. While doing npm install in the Gatsby project, it will fail because of the binding for the Sharp — a native C library Gatsby using — needs to be compiled under the ARM architecture. It didn't work out of the box for me since some native packages were missing. I was able to resolve it following this GitHub issue https://github.com/lovell/sharp/issues/2460 and doing

cd ~/gatsby-project
brew install vips
rm -rf node_modules
npm install

After that the installation went well and I could run the project. There were no issues whatsoever running other JavaScript projects (using TypeScript or Bable).

So, how much faster is ARM Node compared to x86

I ran a few tests on the same machine and also compared build speeds with my previous MacBook Pro 2017 that has 2,9 GHz i7 Quad Core CPU and 16 GB of RAM.

Building the Next.js for https://www.monolisa.dev takes 10 seconds in arm64 Node

vs. 17 seconds when using Rosetta2 emulation and x86 Node.

The results were... astonishing!

Running x86 vs arm64 node resulted in a ~40% improvement. Building a Gatsby site with a few dozens of pages went from 55 seconds on MacBook Pro to 15 seconds on MacBook Air!

Let's not forget, MacBook Air is a fan-less machine that you can put on your lap without a risk of getting a skin burn. And my old computer was making noises similar to an airplane taking off 🤦‍♂️.

Here is the related Twitter thread: https://twitter.com/okonetchnikov/status/1346162117506985985

Next steps

I still didn't finish this, but I'd like to try cleaning up previous installation of Homebrew completely and move everything to /opt/homebrew and also try installing only native packages. It didn't work for me for fnm that I'm using to manage node versions meaning if I install a different node version over it it will use x86 build again.

Automating installation

In order to save time in the future, I have a collection of scripts that automate the process of setting up a new computer. You can find them onGitHub https://github.com/okonet/dotfiles. I've updated it accordingly so it should work on M1 Macs. Use it your own risk and please report issues and send PRs if you decide to use those scripts.

Hi, I'm Andrey Okonetchnikov

Andrey Okonetchnikov — Tue, 18 Jul 2017 09:08:21 +0000

I’m a Front End Engineer and UI & UX Designer from Russia living in Vienna, Austria and currently I work for Feedly.

I’m passionate about programming, UI and UX design, typography, music, photography, mountain biking and coffee.

I’m an engineer with a Master’s degree in Computer Science, but I’m also a designer. I love solving complex problems, no matter if it’s a design or technical challenge. I mostly design in code using JavaScript and CSS, but when it’s required I use graphic editors as well.

I believe that “No UI == Best UI” and that good UI is how things work and not just how they look. I value statistics and tend to verify my ideas using prototypes and usability tests.

I care about code readability and maintainability. I’m the author of ðŸš«ðŸ’© lint-staged – a simple tool that helps improve the code quality in teams.

When writing styles, I use CSS-modules or, when not possible, BEM and I believe that CSS-in-JS is the future of CSS.

You can find me on Twitter as @okonetchnikov

Nice to meet you.

DEV Community: Andrey Okonetchnikov

Before you useState

Simply useState

Sharing the state with the user

Reacting to the user input

Use URL instead of useState

Final result

Gotchas

Prevent scroll in Next.js

Prevent scroll in Gatsby

Conclusion

NetlifyCMS with GitHub OAuth authentication hosted on Vercel

Step 1. Configure Netlify CMS

Step 2. Create GitHub App

Step 3. Set environment secrets

Step 4. Setup OAuth client in Next.js app

Credits

Running Node.js natively on Apple Silicon

Step 0. Remove x86 zsh binary

Step 1. Install Apple Silicon version of the Homebrew

Step 2. Install node and yarn

Step 3. Install packages to run Gatsby

So, how much faster is ARM Node compared to x86

Next steps

Automating installation

Hi, I'm Andrey Okonetchnikov

Simply `useState`

Use URL instead of `useState`