Forem: Tom VanAntwerp

How to Resize iframes with Message Events

Tom VanAntwerp — Thu, 29 Jul 2021 14:21:58 +0000

Originally published at tomvanantwerp.com.

For the past several years, whenever I needed to embed a React app into another site, I would use the Pym.js library written by NPR. With Pym, I was able to embed React apps in iframes with widths and heights that dynamically adjusted to the iframe's content. For example, if an app had conditional UI that was hidden unless you picked a certain option, I didn't need to worry that adding in the new UI would cause overflowing content in the iframe—it's height would simply adjust as the new content became visible.

But Pym is getting a bit old; I don't think it's been updated since 2018. And when I recently created my first embedded app using Svelte instead of React, I absolutely could not get Pym to play nice with it. No matter how I tried to configure it, the iframe was always the default 150px height. The time had come to ditch Pym and write the code to do this myself using the window.postMessage() method.

With postMessage, the embedded iframe site is able to send data to the parent window. Scripts in the parent window can then listen for the message event and take action based on the data sent. In this case, I'm sending a message with the clientHeight of the app content and the parent window is using that information to adjust the height of the iframe. More detailed information can be found on MDN.

Here are examples of a parent HTML page and the iframe-embedded child using the message event to set the iframe's height. In the child page, I use setInterval to regularly update the parent with the height so that I don't have to think too hard about what, precisely, might cause height changes in the app. If you know exactly what would or wouldn't trigger a change, you could send the event manually instead of updating at regular intervals.

<!-- parent.html -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    <!-- The #target is where you want to create the iframe -->
    <div id="target"></div>
    <script>
      let container = document.querySelector("#target");
      const iframe = document.createElement("iframe");
      iframe.src = "https://location.of.iframe/index.html";
      iframe.width = "100%";
      iframe.style = "border: 0";

      // contentHeight sets an arbitrary default
      // then keeps track of the last size update
      // to avoid setting height again if nothing changes
      let contentHeight = 500;
      iframe.height = contentHeight;

      window.addEventListener('load', () => {
        container.appendChild(iframe);
      });

      window.addEventListener(
        'message',
        function (e) {
          // message that was passed from iframe page
          let message = e.data;

          // before I update the height,
          // I check to see if it's defined
          // and if it's changed, and if
          // it's not the iframe default
          // of 150px
          if (
            message.height &&
            message.height !== contentHeight &&
            message.height !== 150
          ) {
            iframe.height = message.height + 'px';
            contentHeight = message.height;
          }
        },
        false
      );
    </script>
  </body>
</html>

<!-- child.html -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    <div class="resizing-app">Your app that could change size goes here.</div>
    <script>
      function resize() {
        setInterval(() => {
          // I noticed that sometimes undefined
          // was sent as the height to the parent,
          // so check for it before trying
          if (document.querySelector('.resizing-app').clientHeight) {
            window.parent.postMessage(
              { height: document.querySelector('.app').clientHeight },
              '*'
            );
          }
        }, 100); // updates ten times per second
      }

      window.addEventListener("load", resize);
    </script>
  </body>
</html>

This example only concerns itself with dynamically adjusting iframe height. But you can of course use this technique to send all sorts of messages to the parent window.

I Built a Tool to Catch Fish and Bugs in Animal Crossing with React and TypeScript

Tom VanAntwerp — Sat, 23 May 2020 19:36:24 +0000

Like many people during this pandemic, I've spent longer than I should have playing the new Animal Crossing: New Horizons for Nintendo Switch. Being a completionist and perfectionist, I've been trying to catch every fish and every bug in the game. But I was disappointed with most online lists of the fish and bugs and their available times: there was no easy way to sort and filter the lists by various criteria. On the last day of the month, I really need to know what's available today but not tomorrow. Or maybe I'm just out to make some bells today, and I want to know where to fish to get the most bang for my buck.

Dissatisfied with existing static tables, I set out to build my own tool in React which I've made available at ac-catches.com.

Collecting Data

For my data source, I used Polygon's tables for fish and insects. These tables are sortable, but have two problems. The first is that while you can "sort" based on time and month available, these sorts really don't make sense. "August" comes before "Year-round" alphabetically, but that really isn't helpful information for a catcher like myself. Second, you can't filter the table to, for example, exclude presently unavailable catches. I would spend too much time scanning each entry to see what was or wasn't currently catchable on my island. This was the pain point that inspired my tool in the first place.

If I were expecting these tables to get lots of updates, I might have written a scraper to regularly download and parse the information. But I expect this information to be static, and there's really not that much of it, so I opted to clean it by hand. Not fun, but doable. Kept things simple.

I had to decide how I wanted to represent time data to make it useful. Using a humable-readable string of the form "4 a.m. - 8 a.m., 5 p.m. - 7 p.m." wouldn't work to make the tool I needed. I realized I could fairly simply represent times and months of availability in a single string of n and y. So the months available string for a Peacock Butterfly (March through June in Northern Hemisphere), I'd end up with nnyyyynnnnnn. I chose to encode all month times as Northern Hemisphere, deciding to use code in the app to shift them by 6 months if Southern Hemisphere were toggled on.

In the end, I created two CSV files (fish.csv and bugs.csv) that looked like this:

name,location,size,price,hours,months
Bitterling,River,Smallest,900,yyyyyyyyyyyyyyyyyyyyyyyy,yyynnnnnnnyy
Pale Chub,River,Smallest,160,nnnnnnnnnyyyyyyynnnnnnnn,yyyyyyyyyyyy
Crucian Carp,River,Small,160,yyyyyyyyyyyyyyyyyyyyyyyy,yyyyyyyyyyyy
...

With this data simply encoded, I can create easy-to-read graphics showing exactly when catches were available. No more reading through text of the times and months!

When the main app component loads, a useEffect hook fetches the CSV files with axios, the results are parse with d3-dsv, and they are set to the appropriate state values from which the tables will be generated.

Using TypeScript

This was my first React project using TypeScript instead of regular JavaScript. TypeScript is all the rage, and I can see why. Using a typed language has advantages. Better auto-completion in VS Code can really speed things up and clarify what your various functions are doing. I'm sure I avoided a lot of bugs (in my code, not in Animal Crossing) this way.

But ultimately, using TypeScript cost me more time than it saved. I was constantly finding myself tweaking interfaces and doing weird arcane tricks to silence the complier's screams. I felt like I was writing a lot of boilerplate code.

Maybe most annoying was writing a declaration file for Styled Components (styled.d.ts) in order to use a theme. Every time I wanted to add to or subtract from my theme, I'd have two files to edit instead of one and would need to restart the app.

// styled.d.ts
import 'styled-components';

declare module 'styled-components' {
  export interface DefaultTheme {
    backgroundColor: string;
    containerBackgroundColor: string;
    ...
  }
}

// Theme.ts
import { DefaultTheme } from 'styled-components';

export const Theme: DefaultTheme = {
  backgroundColor: 'rgba(238, 231, 185, 1)',
  containerBackgroundColor: 'rgba(255, 249, 227, 1)',
  ...
};

The experience was irritating, and it did not feel like my code was better as a result of this extra work. I think TypeScript makes more sense on a large collaborative project, but for a simple React app like this it was a hindrance.

Styles and Animation

Styling this tool was the most fun part of building it. I tried to emulate the style of the user interfaces within the game itself, taking inspiration from the apps on the Nook Phone, the Nook Stop, and the crafting table interface.

As I mentioned earlier, I used Styled Components for my CSS. I've been a convert to CSS-in-JS for a few years now. It's a lot easier to keep track of things by grouping code by component rather than filetype.

The times and months are represented in the table with canvas elements. I originally tried SVG, but there were so many nodes that performance was suffering. This prompted me to use canvas for the first time.

Each time string is split, and then a canvas rect is drawn and colored according to the value of that piece of the string and the current time. Here's the complete component code:

import React, { useEffect, useRef } from 'react';

interface ITimes {
  times: string;
  currentTime: number;
}

const Times = ({ times, currentTime }: ITimes) => {
  const ref = useRef<HTMLCanvasElement>(null);
  // The final dimensions will be 100x25,
  // but here I scale them up so the width
  // is evenly divisible by the length of the
  // times string; this prevents visual artifacts
  // from fractions of pixels. I scale it back
  // down with inline CSS.
  const height = 60;
  const width = 240;

  useEffect(() => {
    if (ref && ref.current) {
      const canvas: HTMLCanvasElement = ref.current;
      canvas.width = width;
      canvas.height = height;
      const ctx = canvas.getContext('2d');
      // Using string length to divide width, I can use
      // this component for times of day and for months.
      const count = times.length;

      if (ctx) {
        times.split('').forEach((time, i) => {
          const color =
            time === 'y'
              ? i === currentTime
                ? 'rgba(105, 206, 107, 1)'  // color if available now
                : 'rgba(161, 222, 164, 1)'  // color if available at time `i`
              : i === currentTime
                ? 'rgba(200, 190, 150, 1)'  // color if unavailable now
                : 'rgba(225, 217, 170, 1)'; // color if unavailable at time `i`
          ctx.fillStyle = color;
          ctx.fillRect(i * (width / count), 0, width / count, height);
        });
      }
    }
  }, [currentTime, ref, times]);

  return <canvas style={{ height: '25px', width: '100%' }} ref={ref} />;
};

And here is the result: rows of easily scanable times and months! You can see how the current time and month cut through each canvas element, making it easy to see what's available at the exact moment.

I also used Framer Motion for the first time to add a little bit of animation to parts of the tool. This helps to give it a friendlier feel closer to the UI in Animal Crossing itself. You can see a bit of this animation when new tables pop in as you switch between fish and bug views.

Result

This was a fun little project. It gave me a chance to play with some things that were new to me (TypeScript, Framer Motion, and canvas) while also experimenting stylistically. And I have an easier time finding fish and insect in Animal Crossing, too!

If I keep working on this, I may refactor the app to use React context and a reducer. Currently there's a lot of top-level state and too much prop-drilling. Effective, but ugly. I've also since started playing with xstate for finite state machines, which I find very elegant. I think it would work very well for powering the tool's options' state.

If you'd like to play with the tool, it's available at ac-catches.com. And the code is available on GitHub. Feel free to check it out, or even contribute!

And good luck to you with catching those fish and bugs!

Don't Quote Environment Variables in Docker

Tom VanAntwerp — Mon, 11 May 2020 21:48:23 +0000

It's usually a good idea to store your app's environment variables separate from the app itself in a .env file. This allows you to easily have different values for development, staging, and production.

Normally when writing a .env file, you might have an unusual property like an API key that has lots of special characters. Typically you would quote this value to handle that.

# a normal environment variable, surrounded by single quotes
KEY='example bl4h 5tuFF 123@#%= ksjhbfdg'

Your system would know to treat what's inside the single quotes as the value of KEY and make it available to your app.

But Docker doesn't work this way.

Let's say you're passing a .env file into a Docker container via docker-compose.yml. Docker would interpret the quotes around the environment variables as part of the value itself!

For a real world example, here's an environment variable passed to the official WordPress Docker image and the resulting output in the container's wp-config.php file (value is random and not used for anything, obviously):

# environment variable in a .env file
WORDPRESS_DB_PASSWORD='Pr65s$CWv{P3k}4j6]I<j=U5n#keN&$D{{Uhv2@L'

// output to wp-config.php
// notice the escaped \' at the beginning and end
define( 'DB_PASSWORD', '\'Pr65s$CWv{P3k}4j6]I<j=U5n#keN&$D{{Uhv2@L\'');

The database password in wp-config.php would be incorrect because Docker considered the single quotes as part of the key value!

So as weird and wrong as it appears, when using .env files with Docker, don't quote values! The above example done correctly would then look like this:

# environment variable in a .env file
WORDPRESS_DB_PASSWORD=Pr65s$CWv{P3k}4j6]I<j=U5n#keN&$D{{Uhv2@L

// output to wp-config.php
define( 'DB_PASSWORD', 'Pr65s$CWv{P3k}4j6]I<j=U5n#keN&$D{{Uhv2@L');

Dragging SVGs with React

Tom VanAntwerp — Thu, 11 Apr 2019 20:40:56 +0000

I've recently started a new version of a mapping tool at work that lets people create choropleths from CSV files. The tool combines React and some D3 libraries to create SVG maps of the United States, including data labels.

These labels are, by default, placed at the centroid of the state's path shape, with a few offsets manually specified for some of the weirder state boundaries. But even with manual offsets, these generated labels can still be positioned poorly. I wanted the ability to click and drag these labels into a better position.

SVGs are not always accommodating. They do not implement the drag and drop API, so no ondrag events for us. And while I do use D3 libraries in this project, it's mainly just d3-geofor parsing topojson and creating the US state paths rather than creating SVG elements or managing data. React handles the programming state and component creation/modification. That means d3-drag, which seems tightly coupled to D3's paradigm for creating/modifying SVG elements in the DOM, would probably be a pain to shoehorn into this.

So, let's implement drag and drop manually!

First, here's the basic Label component. It's just two text elements inside a g element that will be added to the SVG. The component also has the style user-select: none to prevent selecting the text rather than dragging it.

const Label = ({center, adjustment, name, value}) => {
  // Use the centroid coordinates and manual adjustments
  // from props to set X and Y of label in the SVG
  const labelX = center[0] + adjustment[0];
  const labelY = center[1] + adjustment[1];

  return (
    <g style={{userSelect: 'none'}} transform={`translate(${labelX}, ${labelY})`}>
      <text>
        {name}
      </text>
      <text>
        {value}
      </text>
    </g>
  );
};

While SVG may not implement the drag and drop API, we can still use mouse events! We'll use the mousedown event to know that we're trying to drag, the mousemove event to decide how far we've dragged and update position accordingly, and the mouseup event to know that we're done dragging.

const Label = ({center, adjustment}) => {
  const [dragging, setDragging] = useState(false);

  const labelX = center[0] + adjustment[0];
  const labelY = center[1] + adjustment[1];

  return (
    <g
      style={{userSelect: 'none'}} 
      transform={`translate(${labelX}, ${labelY})`}
      onMouseDown={e => {
        // We have clicked the label, starting the drag.
        setDragging(true);
      }}
      onMouseMove={e => {
        // As long as we haven't let go of the mouse button,
        // we are still dragging.
        if (dragging) {
          // Drag behavior will go here.
        }
      }}
      onMouseUp={() => {
        // We let go of the mouse, ending our drag.
        setDragging(false);
      }}
    >
      ...
    </g>
  );
};

Our Label component now knows whether or not it is being dragged. To actually reposition the component, we need to track the coordinates we started at and how far we've dragged away from them.

const Label = ({center, adjustment}) => {
  const [dragging, setDragging] = useState(false);
  const [coordinates, setCoordinates] = useState({ x: 0, y: 0 });
  const [origin, setOrigin] = useState({ x: 0, y: 0 });

  // Add our new coordinates to the X and Y position values.
  const labelX = center[0] + adjustment[0] + coordinates.x;
  const labelY = center[1] + adjustment[1] + coordinates.y;

  return (
    <g
      style={{userSelect: 'none'}} 
      transform={`translate(${labelX}, ${labelY})`}
      onMouseDown={e => {
        // Record our starting point.
        setOrigin({ x: e.clientX, y: e.clientY });
        setDragging(true);
      }}
      onMouseMove={e => {
        if (dragging) {
          // Set state for the change in coordinates.
          setCoordinates({
            x: e.clientX - origin.x,
            y: e.clientY - origin.y,
          });
        }
      }}
      onMouseUp={() => {
        setDragging(false);
      }}
    >
      ...
    </g>
  );
};

And that's it! We've now got a drag-able label inside our SVG, and all without needing any libraries to do it.

I Broke the Refresh Button: Dealing with a Rogue Service Worker

Tom VanAntwerp — Tue, 19 Mar 2019 16:12:33 +0000

I was quite happy to launch a new version of a website last week. I was less happy when, come Monday, people were still seeing the old version. The standard "have you tried refreshing" had no effect: no matter home many times people refreshed, the old content would keep coming back. This was some aggressive caching!

The culprit was an old service-worker.js file! The old site had been built with create-react-app, which included service worker registration by default and which I hadn't paid much attention to. The new site was built with Gatsby, which doesn't include one by default.

Service workers can help you to cache your site/PWA so that it still functions while offline. Typically, a service worker will check for a new version of itself whenever you visit the associated site after a 24 hour period. But when the old service worker checked for an update, it got a 404 response and defaulted to staying alive and serving cached content no matter what.

To get clients to stop relying on the old service worker, I had to add a new "updated" service-worker.js to the site's root (where it expected to find it).

The new service worker, in its entirety:

self.addEventListener('install', () => {
  self.skipWaiting();
});

All this does is tell the browser: "Hey, I'm the new service worker, chuck out that old service worker, and, uh, that's it, we're done here."

Since this particular site never really needed a service worker in the first place, I'm happy with this no-op service worker as a quick and dirty solution. After clients grab this to replace the last service worker, a simple refresh will once again allow their browser to actually hit the Internet to grab things, and not just rely on a very stale cache.

Thanks to Jeff Posnick via StackOverflow for this simple solution! I've got a lot to learn about how service workers function, and a newfound respect for what happens if you're using them without really understanding them

Jeff PosnickFollow

I'm a member of Google's Web DevRel team, focusing on Progressive Web Apps.

Let's Do Lunch (Instead of Meetups)

Tom VanAntwerp — Tue, 26 Feb 2019 13:47:11 +0000

Confession: I'm terrible about attending Meetups.

Most Meetups where I live happen from 6pm to 8pm or later. After a long day of work, I'm tired and want to go home. And 99% of the time, I do go home. When you're exhausted, it unappealing to forego rest and relaxation for the same cheap beer and pizza that every meetup has. I'm in my 30's; my body can't handle that anymore!

It's not that I don't want to meet other developers and share knowledge. I do! But I don't do well with the late-night format. I can't be the only one.

So I've got a question: why don't we do lunch events instead?

I work with lots of economists rather than developers, and they attend so many lunch events! But I've never encountered developer lunches. Do such developer lunches exist? Have they been tried, but there was no interest? (I found a breakfast once, which was great! But then they moved it to the evening...)

Am I just being a grumpy old person? Or should developer lunches be a thing? If you had the choice between Meetups as usual or developer lunches, what would you choose?

MailChimp Email Addresses Look Weird in Outlook? Here’s How to Fix It.

Tom VanAntwerp — Wed, 16 Jan 2019 18:12:33 +0000

Originially published on Medium on September 22, 2016.

The Problem

I get emails from lots of organizations that use MailChimp. How can I tell that they use MailChimp? Because their emails always start like this:

Sender <person=example.com@mail215.atl61.mcsv.net> on behalf of Sender <person@example.com>

I use Office 365 at work and usually browse email in Outlook. And every single MailChimp email I receive that way has a garbled From address just like above.

Because the email is sent by MailChimp’s servers, the From address usually includes the domain of that MailChimp server. This causes three problems:

It’s ugly.
I might think it’s spam.
I can never whitelist emails from your domain because it’s never your domain — it’s always a different MailChimp server!

This is fairly easy to fix. All you need to do are make a few DNS tweaks to your domain and your emails will no longer show this garbled mess in the From field in Outlook.

The Fix

All you need to do are add two DNS records.

Type:  CNAME
Host:  k1._domainkey.example.com
Value: dkim.mcsv.net

Type:  TXT
Host:  example.com
Value: v=spf1 include:servers.mcsv.net ?all

That’s it! Once you’ve added/modified these DNS records, your email addresses sent from MailChimp to Outlook clients will look just fine!

You may already have a TXT record that begins v=spf1, in which case you just need to add include:servers.mcsv.net to the list of domains already in that record.

The Explanation

When Outlook shows the garbled From address in the first place, it’s because it doesn’t know if it should trust the MailChimp server as a legitimate sender for your domain. DKIM and SPF records are designed to help email servers know who can or cannot legitimately send mail on behalf of a domain. With these records in place, emails will correctly display as Sender <person@example.com> because Outlook has a way to verify that MailChimp is authorized to send mail for the example.com domain.