Forem: Amy St. John

Dynamic Imports of JSON

Amy St. John — Sun, 18 Aug 2019 23:38:00 +0000

TL:DR

If you want to do a dynamic import of JSON with Webpack be sure to account for a JSON file not having a default export when you’re trying to extract the value and call default on the returned module to return the whole JSON object.

As someone who has been around the web development scene a long time and has often worked on large enterprise software that is behind the times, it can be hard to keep up to date with all the latest technology and trends when you don’t have opportunities to use it every day at work (and you have two small children at home to take care of). So I’ve been trying to find some extra time the last couple months to study up on all the tools that I’d be using at my new job and signed up for a Front End Masters account to help me brush up.

One of the tools I had used before but had never taken the time to fully understand was Webpack. I had only used Webpack at one previous job and only for 4 months so I knew I wasn’t using it to its fullest potential, and recently I learned how to do dynamic imports with Webpack and that was particularly exciting as someone who has specialized in front-end performance in the past. If you haven’t been introduced to dynamic imports yet it is helpful for solving performance issues by making sure you’re only serving up larger bundles of code when you actually need it, and it’s all regular JS under the hood.

Working with modern JS you often see static imports for modules:

import myLib from './myLib';

But dynamic imports aren’t grabbed from the server until runtime. Using Webpack and the dynamic import structure it creates a promise that will retrieve the chunk at runtime and allow you to act on it at that point. Simple example:

// This creates its own bundle chunk
const myLib = () => import('./myLib');

myButton.addEventListener('click', (e) => {
  // Chunk only downloads at this point and then you react to it
  myLib.then((libFunc) => {
    libFunc();
  });
});

After learning about this through the video, reading documentation and examples, and practicing it on my own I really thought I got it and was excited to put it to use. I ended up with the perfect opportunity a few weeks later at work. We had some sample JSON data that was being used as an occasional fallback to show an example graph when customer data wasn’t available. However it was being loaded with a () => require('myData.json') statement. This was problematic because those large JSON files were being included in multiple other chunks instead of just one, and all these large files were being served up whether or not the sample data was even going to be used.

Now of course there’s multiple ways you can solve that issue, and I certainly thought about just throwing the JSON onto the server and making a request for it when it was needed, but I wanted to make the minimal amount of changes possible and thought, “Why don’t we just turn this into a dynamic import?” So I quickly changed the require into an import and immediately saw the chunks change drastically— it was beautiful. The sample data files became their own chunks and those other giant chunks became much smaller. But I was having trouble accessing the information from those files, and there were a couple different reasons for that, but the one I want to focus on is the one that was so difficult to find the answer for, maybe because it seems so obvious in hindsight.

JSON files don’t have a default export. And because of the other problems I was experiencing with resolving the promise in a legacy React component, I was at first dealing with a pending promise in the debugger instead of being able to just easily see what Webpack was returning. So I spent a good amount of time searching the internet to try to figure out if there’s a special way you need to deal with JSON files when you are dynamically importing them and couldn’t initially even find examples of anyone doing dynamic imports of JSON files.

So this was frustrating but I did eventually discover an example in an answer on StackOverflow that specifically showed what I needed and realized that this info needs to exist in more places on the internet. When you are dealing with a promise of a JSON file, you need to specifically be calling default on it, which is a key in the module object returned.

Examples of just capturing the data object:

import('myData.json').then(({default: myData}) => myData);

// or

import('myData.json').then(module => module.default);

Also worth noting that this isn’t the case if you’re using Parcel or dynamic imports outside of Webpack. In those cases the JSON will just be returned; which is part of why this was so confusing.

So I’m hoping this will help anyone else who gets confused if they’re new to dynamic imports with Webpack and trying to work with JSON.

Project: Is Alameda Exploding?

Amy St. John — Fri, 17 Aug 2018 20:55:00 +0000

I live on the island of Alameda in the San Francisco Bay area. We are bordered on our east side by the Oakland Coliseum and our west side by AT&T Park just directly across the water 3 miles away. When there are fireworks in either of these places we can hear them, and sometimes see them. On holidays we hear all the surrounding fireworks. We also get Blue Angels flying over and so on.

In short, we’re used to hearing noises, and I usually turn to my husband and say, “Must be sportsball” and shrug. But a week and a half ago and we were hearing all kinds of fireworks, my husband said, “I wish there was just a site I could go to in order to verify why I’m hearing fireworks.” (It was the A’s winning a game.) Which in turn made me think of the site “Is Oakland on Fire?” and thought it’d be fun to make something simple like that.

So this week I decided to quickly bang something out and got really excited to actually be working on a personal coding project for once, since I tend to not have a lot of time for my own.

Holidays

I figured Sinatra would be perfect to quickly get something up and running since it’s only a one page site, and then started out by looking into any plugins or API’s that would easily give me a list of holidays. Since I really only care about the ones that have fireworks, I could have hard coded the information but really wanted the site to be as automated and easily maintainable as possible. I ended up finding this Holidays Ruby gem which was perfect for what I needed. It makes it easy to also check if there are any fireworks holidays that week, since for Independence Day we tend to hear things in the days before and after, even though they’re technically illegal.

FIREWORK_HOLIDAYS = [
  "Independence Day",
  "New Year's Eve",
  "Lunar New Year's Day",
  "The second day of Lunar New Year",
  "The third day of Lunar New Year"
].freeze

def check_holidays
  logger.info "Checking Holidays"
  today = Date.today
  holidays = Holidays.on(today, :us, :hk)

  # Might be the week of Independence Day, etc
  if holidays.empty? && Holidays.any_holidays_during_work_week?(today)
    holidays = Holidays.next_holidays(1, [:us, :hk])
  end

  # We only care about the holidays that might have explosions
  holidays.map { |holiday| holiday[:name] }.detect { |hol| FIREWORK_HOLIDAYS.include?(hol) }
end

There might be some additional holidays to add, but I’m going to wait to expand it. Also since holidays don’t regularly change, I will be adding caching soon.

Sports

Then I figured the most heavy duty part was going to be finding the information about the sports games. I assumed I was going to need to use web scraping to get the information and started setting up Nokogiri and HTTParty. I quickly realized, however, that all the websites I wanted information from use JavaScript to load the information in after the initial page load. I haven’t done much web scraping before and did some research about how to address this and quickly came across this page that mentions just accessing the urls that are bringing in the information, since JavaScript is usually accessing JSON anyway before manipulating it on the front-end. Of course I read this and went, “Oh duh, that’s way more straightforward.”

So I found the behind the scenes URL’s on all the sports sites and ditched Nokogiri, since it was completely unnecessary, and just started looking through all the JSON being returned to find the information that I needed for my purposes.

class Scraper
  attr_accessor :check_for_games

  ...

  def grab_page_info(team)
    case team
    when "Athletics"
      HTTParty.get(baseball_url("531221"))
    when "Giants"
      HTTParty.get(baseball_url("531220"))
    when "Warriors"
      HTTParty.get(basketball_url)
    end
  end

  def winning_baseball_game?(response)
    response = response["dates"].first

    home_game = response["date"] == simple_date && VENUE_NAMES.include?(response["games"][0]["venue"]["name"])

    return false unless home_game

    night_game = response["games"].first["dayNight"] == "night"
    is_winner = response["games"].first["teams"]["home"]["isWinner"]

    home_game && night_game && is_winner
  end

  def check_for_games
    games ||= []

    SPORTS_TEAMS.each do |team|
      puts "Checking site for #{team}"

      response = grab_page_info(team)
      return unless response.code == 200

      if team == "Warriors"
        home_game = response["games"].detect do |game|
          game["home"] == true && game["date"] == simple_date
        end

        games << team unless home_game.nil?
      else
        games << team if winning_baseball_game?(response)
      end
    end

    games
  end
end

And that was basically it. I put it up on Heroku and then started fiddling with it to make it faster. I ended up adding IronCache to store the results after the JSON had been retrieved and parsed, which was the biggest bottleneck.

Summary

It’s a bit of a frivilous project, but it was fun. Here are some of the variations of what you might see.

In the future I will probably add some checks for whether it’s Fleet Week, and other such loud disturbances to expand it. Hope the Alamedans enjoy it! You can check out the live site or view the project on Github.

A Sort of Love Letter to HTML

Amy St. John — Mon, 01 Jan 2018 17:00:00 +0000

I’ve been studying HTML since 1999, and like everything else it has grown and advanced over time, and I’m still learning new things you can do with it all the time. Unfortunately it tends to be one of the under-appreciated parts of web development, especially for those coming from a background of backend development. I want to explain some of the major points about why it is worth all developers time to fully understand it in order to have a more effective front-end.

Performance

We can all agree that we want our websites to be fast, right? One of the ways you can do that is by simply reducing the amount of DOM nodes on a page, or in other words, using less HTML elements. But wait, didn’t I just say, “Yay! HTML is the best! HTML for life!” Truth, but less is more. You want to use HTML effectively, and just like we don’t want a bunch of messy spaghetti JavaScript around, we need to respect the structure of the page and be strident about using the best tool for the job as you build the foundation of each page.

Here’s why:

The more DOM nodes you have, the longer it takes to download that page from the server. HTML usually isn’t responsible for the major chunk of page load time, that award tends to go to images and scripts, but every little bit counts!
CSS has to parse the entire DOM to figure out where it needs to apply the styles, and of course CSS performance in itself is a huge topic we won’t get into. The point is that the less unnecessary HTML elements on the page, the less work the stylesheets have to do, which results in better performance.
Likewise, when you are querying the DOM in JavaScript or jQuery, the more DOM nodes you have, the harder it has to work to find the element you want. This is why developers tend to save the queried element into a variable when they’re working with it, because it takes precious milliseconds to query it again and again. But why not make that initial search as fast as possible as well?

Every time I am working heavily on the HTML of a particular page for the first time, the first thing I’ll do is go through and rip out all the superfluous elements. I clean house, so to speak. So now you’re probably asking, “What are all these superfluous elements you keep talking about?” Basically, I’m talking about any element that does not need to be there for the look of the webpage to remain the same. The biggest offenders are pretty easy to spot.

Here’s what to keep an eye out for:

`<div>`’s and `<span>`’s that have no classes, IDs, or attributes

There might be a good reason that you have a <div> as a container for a collection of elements because of its inherent block properties, or maybe you have the styling on the parent element that targets all of its children, but more often than not if I see a bunch of plain <div>’s being nested, they are serving absolutely no purpose whatsoever. Along the same lines, those plain <span>s are usually a red flag. The entire purpose of a <span> is to be able to target something small that you want to style differently than everything else around it.

Like this span page from MDN says, “It should be used only when no other semantic element is appropriate,” and if you look at that page, you’ll see that both examples show it being added unnecessarily. The first, because it is unstyled and does absolutely nothing. The second example is unnecessary because the background-color can be put on the <li> element. A much better example of a proper use case is:

<p><span class="blueText">Blue</span> is my favorite color</p>

Where there would be a class that makes that one word Blue, and the rest of the text in the paragraph is a different color.

Another thing to look out for is multiple <br/> tags in a row. This is usually a sign that the element correct element.There are other elements that might be hanging out for no reason, too, but I’m focusing on these because they’re the two biggest offenders that I have come across.

Empty Elements

I tend to spend a lot of time in the browser’s inspector, and sometimes I’ll see multiple elements that contain nothing. Not elements like the ones in the previous section, but elements that look like they should actually be doing something, because they have IDs, classes, and/or attributes.

<div class="importantThing blueVelvet">
</div>

So I immediately wonder why it’s there and go look up the code, and it’s almost always the result of some conditional.

<div class="importantThing blueVelvet">
  <% if user.city %>
    <%= user.city %>
  <% end %>
</div>

Or what I tend to see in React code is that there won’t even be the conditional, but it’ll have a variable value there that happens to be blank, so you see nothing on the page, but these nodes still are clogging up the DOM for no reason. Now as with anything, there are perfectly good use cases for having placeholder elements in the DOM, like if you know you’re going to be loading something there dynamically, for example. But if that’s not the case then I encourage you to place the HTML elements within the conditional and if there is no conditional, add one!

Using the right tool for the job

Sometimes you can reduce the amount of nodes by simply using the proper HTML element, which is why it’s important to be familiar with them and what they do. Every HTML element has inherent properties and semantic value: there are block level elements, inline elements, elements that have more meaning than others (semantics). The elements behave in different ways and if you aren’t using them for what they were meant for, you might have to have extra elements, and you might have to add more styling than would have been necessary. A really extreme example would be putting a <div> on a page with some text that you want to click on in order to visit another page by adding an onClick handler to that <div> and then making an AJAX call or calling window.location("/link.html"). You’re probably not going to do that right? Why go to all that work, when you can simply use a normal <a> tag for your link that has all that functionality built into it?

Some less extreme, but common examples are cases like the multiple <br/> tags I mentioned above. If you are trying to put extra space between two blocks of text, then you probably aren’t using paragraph tags and should be. If you are separating out chunks of text within a single paragraph tag, then you aren’t using enough paragraph tags. Paragraph tags are block level elements that inherently have spacing above and below them.

Another example would be changing a <span> through CSS to be a block-level element instead of just using a <div>, or adding a bunch of CSS/JS to make a <div> act like a button instead of just using the <button> tag. You get a lot of functionality for free when you use the proper element. Buttons are inherently tabbable, they can use the disabled attribute, and they also have many special HTML5 attributes that can do lots of things.

In general, I encourage you to explore all that different attributes that can be used on a particular element, because that’s how you learn just how powerful HTML can be, which brings me to the next special mention: HTML5.

You might not need CSS/JavaScript

You’ve probably seen “You Might Not Need jQuery” and “You Might Not Need JS”, but I’m here to tell you that you might not need anything but HTML. If you’re an old school developer, you might not be as familiar with all the fantastic things you can do with plain old HTML elements, and I’m always surprised that HTML5 isn’t used more being that it’s pretty old now. One of the areas it really shines is with forms.

You have an input field and you only want the user to be able to enter numbers, so you have a backend validation to ensure that the value is numeric when it hits the server. Backend validations are important; they are the last line of defense before it hits the database, but why waste that time traveling all the way to the server initially? So you decide to implement some client-side validations to catch it without making a server call, and that’s pretty easy to do using isNaN(value) or $.isNumeric(value), but if you’re doing that, then you’re working way too hard. All you have to do is tell your field what type it should be: <input type="number"> and it won’t even allow the user to enter anything but numbers. “But what if I want to make sure they only enter positive numbers? Or limit it?” you might ask. You still don’t need JS. Other attributes you can use on that field are min and max.

This is just one example, but there are many other special input types that can be used in forms that almost completely eliminate the need to use JavaScript for validations or to restrict input. Some of them even do fancy things that previously developers would have used a special plugin for. You want the user to input a date and want them to be able to choose from a pop-up calendar? <input type="date"> will do this in every browser but Safari and Internet Explorer (sadly it falls back to a normal text input field), so plugins aren’t completely obsolete in that case, but it can fit a lot of use cases. Another fun one is <input type="color"> for letting users pick a color from a pop-up palette. I encourage you to explore all the different input types and their attributes.

Accessibility (A11y)

Another very important reason to understand HTML and its proper uses? Accessibility is important. I won’t elaborate all the reasons why because there are countless articles and books that will do that much better, but I will sum it up by saying that your website being accessible enhances the user experience for everyone. I’m also not going to talk about all the techniques to make your site accessible because that’s a huge topic all its own. What I want to focus on, in the spirit of this article, is how using proper HTML elements (the right tool for the job, again) will already make your webpage much more accessible than it would be otherwise.

Semantic HTML

I suppose having also studied print design and typography, that my love of clean layouts and meaningful structure has also carried over to web development. So I was pretty excited about the increase of semantic tags when HTML5 came around. Providing more meaning to the elements not only helps accessibility but is an all-around win, in my opinion. Long gone are the days where <div>s ruled the lands. Now we have <section>, <article>, <aside>, and so on. Even before HTML5 though, there were a large amount of tags that weren’t being used when they should be.

Let’s take tables for example. Tables no longer rule the web either, but they still have a good purposes and lots of associated tags that go with them. Yet somehow I’ll see table after table only make use of <table>, <tr>, and td, oftentimes with the first table row trying to act as headers. If a table has headers, it should at the very least be using <th> for the header cells, but ideally using <thead> as well. The browser will treat these differently than just another table row, and semantically it means something.

I still see <i> and <b> used more often than <em> and <strong>, probably because old habits die hard. The former still have uses, but the latter should always be used when you’re trying to place actual emphasis on something; not for styling reasons, but because of the meaning it conveys.

How proper HTML helps keyboard accessibility

All sites should be fully accessible by keyboard, and there are certain keys that users expect to be able to use to do this, because it’s the standard. Most people know they can tab through form elements and tend to do it without thinking about it. This is another case where you want to use the right tool for the job, because the exact kinds of things on the page that the user would want to navigate to are tabbable by default, without you having to do anything. This is why structure is important, and this is why the right element is important. Links, buttons, and input fields all have that functionality built in. This is why you don’t want to use a <div> in place of a <button>, or a link that doesn’t actually use an <a> tag. It is also why the order of elements matter, because tabbing follows DOM structure, and not the visual structure on the page. So if you’re floating <button>s and they appear in a different order on the page because of it, that’s going to confuse the user when the element they expect to be selected does not actually get selected.

Sometimes that’s not going to cut it. You might have a link menu hidden as a dropdown, and then you’re going to have to make that parent element open and close when tabbed to, but by being mindful of using the right elements for the job, you’re still halfway there.

Links also accept the “Enter” key by default. So if you are focused on a link and hit enter, it will go to that link. In forms, if you are focused on any input field within a form and hit enter, unless there is underlying code telling it to not behave like normal (here’s a nice article about why you should rarely suppress this), it will automatically submit the form.

How proper HTML helps screen-readers

There are a large amount of people in the world who have visibility issues, so they make use of screen-readers, and there is no feature that you as a developer turn on for this to work. A screenreader can read what’s on any website, but how much of that is coherent does depend on what you as a developer have put there. This is why the aforementioned semantics are important, but there are also some basic HTML attributes that aid screen-readers. One that most people know about is the alt attribute on images (alternative text), and yet it is so neglected. It’s often left blank when it shouldn’t be, filled in when it shouldn’t be, or the information doesn’t describe the image at all, rendering it useless. Let me hit on each of those points:

If it is important that a particular image is conveyed to the user (a graph, a visual representation of something being described, etc) then you absolutely want an alt attribute.
If the image is completely unimportant, like a visual flourish, or an icon to represent text that comes immediately before or after it, then you do not want an alt attribute. Why? You’re not only throwing a mess of unimportant information at the user, but in many cases you’re just making it repeat the same word twice, which is confusing. This is also where ARIA roles come into play, but the most basic thing you can do in this situation is to intentionally identify a blank alt="" attribute. If you don’t put in any alt attribute at all, the screenreader/browser will just guess it by reading the file name or title.
If you have an image of the user and your alt text is “User”, or it’s the logo of your company and it just says “Logo” or “Company Name”, you are not helping anyone. At the very least be a little more descriptive: “Your profile picture”, “Company Name’s logo”, but even better, be really descriptive if it’s an important visual. “Image of a brown horse with black hair” helps you imagine something much more than “Pic of horse”.

Another common misuse of HTML I come across is not labeling input fields. All input fields should have an associated label element and this is not accomplished by just having text near an input field. It may look fine to you visually and you might be able to deduce that they go together, but screen-readers won’t. Screen-readers expect that any input field that is selected should be able to tell them what that input field is for. There are two main ways to make sure your fields are labeled properly. The first is to simply wrap your input field in the <label> element like this:

<label>
  Your name
  <input type="text" name="name"/>
</label>

I know some developers might not like to use that method because they have special styling on all <label>s that they don’t want on the <input> field and that’s fair enough, you just have to get explicit, and this is where I see the HTML fall way short.

<label>Your name</label>
<input type="text" name="name"/>

The above does not associate the label with the input field. Proximity does not equal association. This is where the for attribute comes in.

<label for="userName">Your name</label>
<input type="text" name="name" id="userName"/>

The above associates the fields by matching up the for attribute with the id of the field. If your for attribute and id attribute don’t match up, then it does not work (I see this happen a lot). Sometimes you might not want the label there visually, or have an extra field associated with that same label. No problem, you can either hide the label, or add an ARIA attribute to the input field that specifies the labeling, but never just leave a field label-less. Screen-readers don’t read placeholders. I should also note that if you want your form elements to be fully accessible for all screen-readers then it’s best to cover your bases and have both the for attribute AND nest your input inside the label.

An added benefit of labeling inputs properly: they’re easier to select and click, which makes them more accessible! Especially checkboxes and radio buttons, which have a very small click area. This is because it allows you to be able to click on the label text to select the element. Also note that for radio buttons, you should use the <fieldset> tag to group the radio inputs together, where the <legend> serves as the parent label while each input still has its own.

These are things that should be considered the basics of HTML, making use of the built in attributes and structure to better serve a diverse user base.

You don’t have to work as hard

If anything else, understanding HTML should be encouraged because it makes your work easier. It can reduce the need for both styling and scripting, and makes the world wide web a happier place.

Abbreviations

HTML: HyperText Markup Language
DOM: Document Object Model
ARIA: Accessible Rich Internet Applications