lightpohl.me

Five Years of podcast-dl

2026-01-04T00:00:00Z

I recently published v11.4.0 of podcast-dl and noticed that this small project is now over five years old. It started as a simple, personal script for grabbing premium podcast feeds to host on my Plex server (it continues to do that very well), but now it's a full podcast download multitool. Need transcripts and other metadata? It can grab those. Need to name the downloaded episodes in a hyperspecific way for your app of choice? It can do that too.

The ongoing trend of podcasts transitioning to video-first might mean that tools like podcast-dl become increasingly irrelevant. Many new shows only publish to YouTube and Spotify and do not offer an RSS feed at all. Patreon-exclusive feeds now have integration with Spotify, so you can seal yourself into that tomb from the inside. Hey, at least yt-dlp works now.

For now, podcast-dl still has plenty of feeds left, and it'll stick around as long as the open web allows.

Action Button Reviews Boku no Natsuyasumi

2023-01-18T00:00:00Z

I discovered Tim Rogers and Action Button pretty late. In October of 2021, Action Button published their review of Cyberpunk 2077 — a choose-your-own-adventure style review of the most anticipated and controversial video game release of the last decade. I watched the introduction and was hooked.

11 months later, Action Button released the first episode of season two: Action Button Reviews Boku no Natsuyasumi. Like a lot of Tim Roger's work, and especially with Action Button, it's sometimes difficult to summarize a video in a way that doesn't feel like a tremendous simplification. I won't try. But I will say I feel like it's Tim Roger's best work to date and my favorite thing of 2022. I've revisited part five many times and I think about it often.

Our memory only records the cold parts. Our memory cannot replicate textures with perfection. Memory is worse than the moment. Better memory is worse than imagination.

Refresh Your React App Discretely

2022-05-14T00:00:00Z

One of the hurdles introduced by single-page apps is that users can go much longer without being updated to the latest deployed code. This affects not only custom React setups but even more opinionated options like Next.js. In a perfect world, APIs should be backwards compatible and fail gracefully when something is missed, but there's no doubt in my mind that a user with a client bundle that is several days old will be more likely to run into issues. Fortunately, there's an easy way we can update our client app with the user being none the wiser. We'll build our example with React and React Router, but the concepts apply to all client JavaScript frameworks.

Links And Anchors

The main reason users can have much longer running sessions without receiving new JavaScript is because of the nature of single-page applications. Single-page applications often utilize client-side routing, which means the full page will not be refreshed: the app will instead fetch data it needs for the next page and manipulate the browser history manually without requesting the full HTML. We could just not use client-side routing, but we will lose a lot of that speediness we associate with these feature-rich web applications. What if we could fall back to native anchors only when necessary?

function SuperLink({ href, ...other }) {
  const { shouldUseAnchor } = useSomeFunction();

  if (shouldUseAnchor) {
    return <a href={href} {...other} />;
  }

  // a React Router <Link />
  return <Link to={href} {...other} />;
}

This code looks promising. But how can we calculate shouldUseAnchor to determine which type of link to render?

git.txt

One simple option is to expose a text file with a Git hash that is generated from our source code. Wherever we expose our fonts and possible images (e.g. /static), we can place git.txt at build-time.

{
  "git:generate-hash": "git ls-files -s src/ | git hash-object --stdin > static/git.txt"
}

As part of our build command, we'll also call npm run git:generate-hash and place it into our publicly accessible directory. Now, we simply need to poll this file at regular intervals to check for updates and refresh our SuperLink component.

GitHashProvider

Any page could have a number of links on it — it would be mistake to have each instance poll for our hash file. Instead, we'll wrap our app in a React context provider so all our instances of our SuperLink can use it.

import * as React from "react";

// Some boilerplate to prepare our Context
const GitHashContext = React.createContext({
  hash: "",
  hasUpdated: false,
});

// Setup our hook that we'll use in <SuperLink />
export const useGitHash = () => React.useContext(GitHashContext);

// Function used to actually fetch the Git hash
const TEN_MINUTES_IN_MS = 60000 * 10;
async function fetchGitHash() {
  let gitHash = "";

  try {
    const result = await fetch("/static/git.txt");
    gitHash = await result.text();
  } catch (error) {
    console.error(error);
  }

  return gitHash;
}

// The provider we'll wrap around our app and fetch the Git hash
// on an interval
export const GitHashProvider = ({ children }) => {
  const [state, setState] = React.useState({ hasUpdated: false, hash: "" });

  const updateGitVersion = React.useCallback(async () => {
    const hash = await fetchGitHash();

    if (hash) {
      setState((prevState) => ({
        hash,
        hasUpdated: !!prevState.hash && prevState.hash !== hash,
      }));
    }
  }, []);

  React.useEffect(() => {
    const interval = setInterval(() => {
      updateGitVersion();
    }, TEN_MINUTES_IN_MS);

    return () => clearInterval(interval);
  }, [updateGitVersion]);

  return (
    <GitHashContext.Provider value={state}>{children}</GitHashContext.Provider>
  );
};

That's quite a bit of code, so let's walk through it. We define the boilerplate for context and the hook that will provide access to its data (GitHashContext and useGitHash). Next, we define a simple wrapper around fetch that will query our git.txt and pull out the hash.

The core logic is encapsulated within GitHashProvider. Here, we define our state and establish an interval to periodically fetch the latest Git hash. If we have already saved a Git hash before and it's different than the latest, we'll set hasUpdated to true. We keep track of the previous hash for later comparisons. We're now ready to use it in SuperLink!

function SuperLink({ href, ...other }) {
  const { hasUpdated: hasGitHashUpdated } = useGitHash();

  if (hasGitHashUpdated) {
    return <a href={href} {...other} />;
  }

  // a React Router <Link />
  return <Link to={href} {...other} />;
}

When to Use It

Depending on the application, the locations where you'd want to use our new SuperLink could change. Personally, I feel that links in your header are almost always good candidates. Imagine a user who leaves a tab open overnight and returns to SomeCoolWebApp.xyz the next day. Unbeknownst to them, the developers have deployed a crucial bugfix. Now, if the user clicks on any of these 'smart' links, they will receive the updated code. They might notice a brief page reload, but this should be infrequent enough to not be disruptive.

Persist Formik State on Refresh with React Hooks

2021-05-27T00:00:00Z

Out of all the different React form libraries I've used in different projects, Formik is currently my favorite. It's intuitive and provides lower-level API access to workaround situations a high-level only API might not anticipate.

If you're building a large form, or one that will be filled out slowly over some time, persisting its state across sessions is really important. It's especially important if you anticipate much usage on mobile where apps are often removed from memory unexpectedly when users are multitasking.

Fortunately, Formik makes adding that behavior simple, and that behavior can also be consolidated into one reusable component that you can drop into any Formik form provider.

Saving to Local Storage

Let's start by saving the form state into local storage when the form is updated. We're going to use two libraries here (react-fast-compare and use-debounce) to simplify the example code, but feel free to roll your own code or use an equivalent library as a replacement.

// FormikPersist.js
import { useEffect, useRef } from "react";
import { useFormikContext } from "formik";
import isEqual from "react-fast-compare";
import { useDebouncedCallback } from "use-debounce";

const FormikPersist = ({ name }) => {
  const { values } = useFormikContext();
  const prefValuesRef = useRef();

  const onSave = (values) => {
    window.localStorage.setItem(name, JSON.stringify(values));
  };

  const debouncedOnSave = useDebouncedCallback(onSave, 300);

  useEffect(() => {
    if (!isEqual(prefValuesRef.current, values)) {
      debouncedOnSave.callback(values);
    }
  });

  useEffect(() => {
    prefValuesRef.current = values;
  });

  return null;
};

export default FormikPersist;

Our FormikPersist component takes one prop: a name to be the unique identifier we will use to store the form in window.localStorage. Since our component will live underneath a Formik provider, we can use useFormikContext to access the current values of the form. On each render of our component, we compare the previous list of values with the current values and save the latest values to local storage if they differ. We use a debounced version of our onSave function to write to local storage so as to not write too many times in quick succession.

The hardest part is over — the rest is even easier.

Rehydrating on Refresh

Now we just need to check our local storage on component mount and initialize the form values if we find them.

// ...

// We're now grabbing 'setValues' as well
const { values, setValues } = useFormikContext();

// ...

useEffect(() => {
  const savedForm = window.localStorage.getItem(name);

  if (savedForm) {
    const parsedForm = JSON.parse(savedForm);

    prefValuesRef.current = parsedForm;
    setValues(parsedForm);
  }
}, [name, setValues]);

// ...

One alteration you might want to make to this component is to only rehydrate form values that were saved within a certain time span (e.g. the last day or the last week). To do that we would save a timestamp with the form values and compare that timestamp with the current time in this useEffect.

Putting It All Together

We now have our complete FormikPersist component that we can place under a Formik provider to handle persisting our form state on refresh.

import { useEffect, useRef } from "react";
import { useFormikContext } from "formik";
import isEqual from "react-fast-compare";
import { useDebouncedCallback } from "use-debounce";

const FormikPersist = ({ name }) => {
  const { values, setValues } = useFormikContext();
  const prefValuesRef = useRef();

  const onSave = (values) => {
    window.localStorage.setItem(name, JSON.stringify(values));
  };

  const debouncedOnSave = useDebouncedCallback(onSave, 300);

  useEffect(() => {
    const savedForm = window.localStorage.getItem(name);

    if (savedForm) {
      const parsedForm = JSON.parse(savedForm);

      prefValuesRef.current = parsedForm;
      setValues(parsedForm);
    }
  }, [name, setValues]);

  useEffect(() => {
    if (!isEqual(prefValuesRef.current, values)) {
      debouncedOnSave.callback(values);
    }
  });

  useEffect(() => {
    prefValuesRef.current = values;
  });

  return null;
};

export default FormikPersist;

// inside some render function
<Formik {...props}>
  <Form {...props}>
    <FormikPersist name="our-form" />
  </Form>
</Formik>

And that's it! Add this to your form and you'll make mobile visitors of your website much happier if their browser tab is thrown to the wind. I'm looking at you, iOS 13.