DEV Community: Hack4Impact

Another way to understand JavaScript's array.reduce

Ben Holmes — Fri, 05 Feb 2021 16:26:05 +0000

If you've run the guantlet of array methods in JavaScript, you've probably hit this roadblock a few times:

Wait, how do I use the reduce function again?

I actually led a JS bootcamp with this topic for my college's Hack4Impact chapter (material 100% free-to-use here!). Questions on reduce have come up so many times, and I think I've finally found an explanation that clicks 😁 Hope it works for you too!

🎥 Video walkthrough

If you prefer to learn by video tutorial, this one's for you. You can fork this CodePen for the source material to follow along 🏃‍♂️

📝 Step-by-step cheatsheet

Let's walk our way to reduce by using what we know: good ole' for loops.

Here's an example. Say we have our favorite album on a CD (remember those? 💿), and our stereo tells us the length of each track in minutes. Now, we want to figure out how long the entire album is.

Here's a simplified approach for what we want to do:

// make a variable to keep track of the length, starting at 0
let albumLength = 0
// walk through the songs on the album...
album.songs.forEach(song => {
  // and add the length of each song to our running total
  albumLength += song.minutesLong
})

No too bad! Just loop over the songs, and accumulate the album runtime while we walk through the songs. This is basically the process you'd use in real life, tallying up the album length as you skip through the tracks on your stereo.

That word "accumulate" is pretty significant here though. In essence, we're taking this list of track lengths, and reducing them to a single accumulated number: the albumLength. This process of reducing to an accumulator should set off a light bulb in your head: 💡 we can use array.reduce!

Going from `forEach` to `reduce`

Let's try reduce-ifying our function from earlier. This is a simple, 4 step process:

Change forEach to reduce:

let albumLength = 0
album.songs.reduce((song) => {
  albumLength = albumLength + song.minutesLong
})

Move albumLength to the first parameter of the loop function, and the initial value (0) to the second parameter of reduce

// accumulator up here 👇
album.songs.reduce((albumLength, song) => {
  albumLength = albumLength + song.minutesLong
}, 0) // 👈 initial value here

Change albumLength = to a return statement. This isn't too different conceptually, since we're still adding our song length onto our "accumulated" album length:

album.songs.reduce((albumLength, song) => {
  // 👇 Use "return" instead of our = assignment
  return albumLength + song.minutesLong
}, 0)

Retrieve the result of our reduce loop (aka our total album length). This is just the value returned:

const totalAlbumLength = album.songs.reduce((albumLength, song) => {
  return albumLength + song.minutesLong
}, 0)

And that's it! 🎉

So wait, why do I even need `reduce`?

After all that work, reduce might feel like a slightly harder way of writing a for loop. In a way... it kind of is 😆

It offers one key benefit though: since reduce returns our total, function chaining is a lot easier. This may not be a benefit you appreciate right away, but consider this more complex scenario:

// Say we have this array of arrays,
// and we want to "flatten" everything to one big array of songs
const songsByAlbum = [
  ['Rap Snitches Knishes', 'Beef Rap', 'Gumbo'],
  ['Accordion', 'Meat Grinder', 'Figaro'],
  ['Fazers', 'Anti-Matter', 'Krazy World']
]
let songs = []
songsByAlbum.forEach(albumSongs => {
  // "spread" the contents of each array into our big array using "..."
  songs = [...songs, ...albumSongs]
})

This isn't too hard to understand. But what if we want to do some more fancy array functions on that list of songs?

// Ex. Make these MF DOOM songs titles all caps
let songs = []
songsByAlbum.forEach(albumSongs => {
  songs = [...songs, ...albumSongs]
})
const uppercaseSongs = songs.map(song => song.toUppercase())

All caps when you spell the man name. Rest in piece MF DOOM

This is fine, but what if we could "chain" these 2 modifications together?

// grab our *final* result all the way at the start
const uppercaseSongs = [
  ['Rap Snitches Knishes', 'Beef Rap', 'Gumbo'],
  ['Accordion', 'Meat Grinder', 'Figaro'],
  ['Fazers', 'Anti-Matter', 'Krazy World']
]
// rewriting our loop to a "reduce," same way as before
.reduce((songs, albumSongs) => {
  return [...songs, ...albumSongs]
}, [])
// then, map our songs right away!
.map(song => song.toUppercase())

Woah! Throwing in a reduce, we just removed our standalone variables for songsByAlbum and songs entirely 🤯

Take this example with a grain of salt though. This approach can hurt the readability of your code when you're still new to these array functions. So, just keep this reduce function in your back pocket, and pull it out when you could really see it improving the quality of your code.

Learn a little something?

Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!

This thing tackles the "first principles" of web development. In other words, what are all the janky browser APIs, bent CSS rules, and semi-accessible HTML that make all our web projects tick? If you're looking to go beyond the framework, this one's for you dear web sorcerer 🔮

Subscribe away right here. I promise to always teach and never spam ❤️

A shiny-on-hover effect that follows your mouse (CSS) ✨

Ben Holmes — Thu, 28 Jan 2021 17:40:13 +0000

Hover states are probably the most fun a developer can have when a designer isn't looking. You've seen the basics at this point; fade-ins, growing and shrinking, color shifts, animated rainbow gradients, etc etc etc.

But there was one animation that inspired me recently (props to Keyframers for shouting it out!)

// Detect dark theme var iframe = document.getElementById('tweet-1278384065087893505-154'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1278384065087893505&theme=dark" }

This isn't some "static" hover state that always looks the same. It actually tracks your mouse moment to make the page even more interactive. This seemed like such a cool idea... that we threw it all over our Hack4Impact site 😁

So let's explore

🎈 Why CSS variables can help us
✨ How we style our button
🪤 How we map mouse movements to a metallic shine
🔨 How to adapt this animation to any UI framework

Onwards!

Our end goal

The effect is pretty simple on the surface. Just shift the color a little bit whenever you hover over the button, plus a little circular gradient for a "metallic" sheen.

But there's a bit of added spice that CSS can't pull off on its own: We need to track your cursor position to make this interactive! Luckily, this has gotten a lot easier over the years; You won't even need a UI framework or state management to pull it off 👀

🎈 Brief primer on CSS variables

In case you haven't heard, CSS variables are kind of taking web development by storm right now. They're a bit like those $ variables preprocessors like SASS and LESS let you pull off, but with one huge benefit: you can change the value of these variables at runtime using JavaScript 😱

Let's see a simple example. Say we want to make a balloon pump, where you hit a button as fast as you can to "inflate" an HTML-style balloon.

If we didn't know anything about CSS variables, we'd probably do some style manipulation straight from JavaScript. Here's how we'd pump up a balloon using the transform property:

const balloon = document.querySelector('.balloon');
// make the balloon bigger by 50%
balloon.style.transform = 'scale(1.5)';

Or, to make the balloon just a little bit bigger on every button click:

...
const pump = document.querySelector('.pump')
// keep track of the balloon's size in a JS variable
let size = 1;
pump.addEventListener('click', () => {
  size += 0.1;
    balloon.style.transform = `scale(${size})`;
})

There's nothing wrong with this so far. But it has some growing pains:

We need to keep track of a CSS property (the balloon's scale size) using a JS variable. This could ahem balloon into a suite of state variables overtime as we animate more elements throughout our app.
We're writing our CSS using strings. This leaves a sour taste in my mouth personally, since we loose all our syntax highlighting + editor suggestions. It can also get nasty to maintain when we want that size variable in other parts of our styles. For example, what if we wanted to change the background-position as the balloon inflates? Or the height and width? Or some linear-gradient with multiple color positions?

CSS variables to the rescue

As you may have guessed, we can store this size from our code as a CSS variable!

We can use the same .style attribute as before, this time using the setProperty function to assign a value:

let size = 1;
pump.addEventListener('click', () => {
  size += 0.1;
    balloon.style.setProperty('--size', size);
})

Then, slide that variable into our transform property from the CSS:

.balloon {
  /* set a default / starting value if JS doesn't supply anything */
  --size: 1;
  ...
  /* use var(...) to apply the value */
  transform: scale(var(--size));
}

Heck, you can ditch that size variable entirely and make CSS the source of truth! Just read the value from CSS directly whenever you try to increment it:

pump.addEventListener('click', () => {
  // Note: you *can't* use balloon.style here!
  // This won't give you the up-to-date value of your variable.
  // For that, you'll need getComputedStyle(...)
    const size = getComputedStyle(balloon).getPropertyValue('--size');
  // size is a string at this stage, so we'll need to cast it to a number
  balloon.style.setProperty('--size', parseFloat(size) + 0.1)
})

There's some caveats to this of course. Namely, CSS variables are always strings when you retrieve them, so you'll need to cast to an int or a float (for decimals) as necessary. The whole .style vs. getComputedStyle is a little weird to remember as well, so do whatever makes sense for you!

Here's a fully working example to pump up your confidence 🎈

✨ Let's get rolling on our shiny button

Before putting our newfound CSS variable knowledge to the test, let's jump into the styles we'll need for this button.

Remember that we want a smooth gradient of color to follow our mouse cursor, like a light shining on a piece of metal. As you can imagine, we'll want a radial-gradient on our button that we can easily move around.

We could add a gradient as a secondary background on our button (yes, you can overlay multiple backgrounds on the same element!). But for the sake of simplicity, let's just add another element inside our button representing our "shiny" effect. We'll do this using a pseudo-element to be fancy 😁

.shiny-button {
  /* add this property to our button, */
  /* so we can position our shiny gradient *relative* to the button itself */
  position: relative;
  /* then, make sure our shiny effect */
  /* doesn't "overflow" outside of our button */
  overflow: hidden;
  background: #3984ff; /* blue */
  ...
}

.shiny-button::after {
  /* all pseudo-elements need "content" to work. We'll make it empty here */
  content: '';
  position: absolute;
  width: 40px;
  height: 40px;
  /* make sure the gradient isn't too bright */
    opacity: 0.6;
  /* add a circular gradient that fades out on the edges */
    background: radial-gradient(white, #3984ff00 80%);
}

Side note: You may have noticed our 8-digit hex code on the gradient background. This is a neat feature that lets you add transparency to your hex codes! More on that here.

Great! With this in place, we should see a subtle, stationary gradient covering our button.

🪤 Now, lets track some mouse cursors

We'll need to dig into some native browser APIs for this. You probably just listen for click 99% of the time, so it's easy to forget the dozens of other event listeners at our disposal! We'll need to use the mousemove event for our purposes:

const button = document.querySelector('.shiny-button')
button.addEventListener('mousemove', (e) => {
    ...
})

If we log out or event object, we'll find some useful values in here. The main one's we're focusing on are clientX and clientY, which tell you the mouse position relative to the entire screen. Hover over this button to see what those values look like:

This is pretty useful, but it's not quite the info we're looking for. Remember that our shiny effect is positioned relative to the button surrounding it. For instance, to position the effect at the top-left corner of the button, we'd need to set top: 0; left: 0; So, we'd expect a reading of x: 0 y: 0 when we hover in our example above... But this definitely isn't the values that clientX and clientY give us 😕

There isn't a magical event property for this, so we'll need to get a little creative. Remember that clientX and clientY give us the cursor position relative to the window we're in. There's also this neat function called getBoundingClientRect(), which gets the x and y position of our button relative to the window. So if we subtract our button's position from our cursor's position... we should get our position relative to the button!

This is probably best explored with visuals. Hover your mouse around to see how our mouse values, boundingClientRect values, and subtracted values all interact:

💅 Pipe those coordinates into CSS

Alright, let's put two and two together here! We'll pass our values from the mousemove listener:

button.addEventListener("mousemove", (e) => {
  const { x, y } = button.getBoundingClientRect();
  button.style.setProperty("--x", e.clientX - x);
  button.style.setProperty("--y", e.clientY - y);
})

Then, we'll add some CSS variables to that shiny pseudo-element from before:

.shiny-button::after {
  ...
  width: 100px;
  height: 100px;
  top: calc(var(--y, 0) * 1px - 50px);
  left: calc(var(--x, 0) * 1px - 50px);
}

A couple notes here:

We can set a default value for our variables using the second argument to var. In this case, we'll use 0 for both.
CSS variables have a weird concept of "types." Here, we're assuming we'll pass our x and y as integers. This makes sense from our JavaScript, but CSS has a hard time figuring out that something like 10 really means 10px. To fix this, just multiply by the unit you want using calc (aka * 1px).
We subtract half the width and height from our positioning. This ensures that our shiny circle is centered up with our cursor, instead of following with the top left corner.

Fade into our effect on entry

We're pretty much done here! Just one small tweak: if we leave this animation as-is, our shiny effect will always show in some corner of our button (even when we aren't hovering).

We could fix this from JavaScript to show and hide the effect. But why do that when CSS lets you style-on-hover already?

/* to explain this selector, we're */
/* selecting our ::after element when the .shiny-button is :hover-ed over */
.shiny-button:hover::after {
  /* show a faded shiny effect on hover */
  opacity: 0.4;
}
.shiny-button::after {
  ...
  opacity: 0;
  /* ease into view when "transitioning" to a non-zero opacity */
  transition: opacity 0.2s;
}

Boom! Just add a one-line transition effect, and we get a nice fade-in. Here's our finished product ✨

🔨 Adapt to your framework of choice

I get it, you might be dismissing this article with all the eventListeners thinking well, I'm sure that JS looks much different in framework X. Luckily, the transition is pretty smooth!

First, you'll need to grab a reference to the button you're shine-ifying. In React, we can use a useRef hook to retrieve this:

const ShinyButton = () => {
  // null to start
  const buttonRef = React.useRef(null)
  React.useEffect(() => {
    // add a useEffect to check that our buttonRef has a value
    if (buttonRef) {
      ...
    }
  }, [buttonRef])

  return <button ref={buttonRef}>✨✨✨</button>
}

Or in Svelte, we can bind our element to a variable:

<script>
  import { onMount } from 'svelte'
  let buttonRef
  // our ref always has a value onMount!
  onMount(() => {
    ...
  })
</script>

<button bind:this={buttonRef}>✨✨✨</button>

Aside: I always like including Svelte examples, since they're usually easier to understand 😁

Once we have this reference, it's business-as-usual for our property setting:

React example

const ShinyButton = () => {
  const buttonRef = React.useRef(null)
  // throw your mousemove callback up here to "add" and "remove" later
  // might be worth a useCallback based on the containerRef as well!
  function mouseMoveEvent(e) {
    const { x, y } = containerRef.current.getBoundingClientRect();
    containerRef.current.style.setProperty('--x', e.clientX - x);
    containerRef.current.style.setProperty('--y', e.clientY - y);
  }

  React.useEffect(() => {
    if (buttonRef) {
      buttonRef.current.addEventListener('mousemove', mouseMoveEvent)
    }
    // don't forget to *remove* the eventListener
    // when your component unmounts!
    return () => buttonRef.current.removeEventListener('mousemove', mouseMoveEvent)
  }, [buttonRef])
  ...

Svelte example

<script>
  import { onMount, onDestroy } from 'svelte'
  let buttonRef
  // again, declare your mousemove callback up top
  function mouseMoveEvent(e) {
    const { x, y } = buttonRef.getBoundingClientRect();
    buttonRef.style.setProperty('--x', e.clientX - x);
    buttonRef.style.setProperty('--y', e.clientY - y);
  }
  onMount(() => {
        buttonRef.addEventListener('mousemove', mouseMoveEvent)
  })
  onDestroy(() => {
    buttonRef.removeEventListener('mousemove', mouseMoveEvent)
  })
</script>

The main takeaway: 💡 don't forget to remove event listeners when your component unmounts!

Check out our live example on Hack4Impact

If you want to see how this works in-context, check out this CodeSandbox for our Hack4Impact site. We also added some CSS fanciness to make this effect usable on any element, not just buttons ✨

To check out the component, head over here.

Learn a little something?

Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!

Subscribe away right here. I promise to always teach and never spam ❤️

How we built an app that uses worker location history to combat wage theft

Abhinav Suri — Sat, 05 Dec 2020 19:43:07 +0000

In 2008, the Center for Urban Economic Development surveyed 4,387 low-wage workers in Chicago, Los Angeles, and New York City. They wanted to determine the extent of violations of employment laws in core sectors of the US economy.

They discovered that:

76% of those who worked more than 40 hours were not paid the legally required overtime rate.
68% of the sample experienced at least one pay-related violation in the previous work week.
The average worker lost $51 of his or her weekly earnings of $339 due to wage theft. This loss translates to over $2,652 in losses over one year (out of a total average salary of $17,616).

Furthermore, this study estimates that workers across the country lose a collective of $50 billion per year due to wage theft.

Even though this study was conducted eight years ago, the findings are still relevant: the majority of low-wage workers are the victims of wage theft. If they want to recover their lost wages, they must turn to the courts. Because so many low-wage workers work in exploitative situations, their employers fail to keep the required records that would show the number of hours that a worker may have worked or the pay that the worker received each week. Without these records, workers must rely on their evidence as to their work hours and pay.

Frequently, lawyers must rely on the clients to remember and then construct a schedule of their whereabouts for several months, which makes for a weaker case. That is where this story begins.

Over the past semester, my team and I at Hack4Impact had the opportunity to work with Community Legal Services of Philadelphia (CLS), a pro-bono legal clinic which has served over one million low-income Philadelphians since its founding in 1966.

We were tasked with creating a website to analyze a client’s Google Location History and create a timesheet for all the times a client entered and exited a user-inputted workplace. The intention was to use the worker’s google location history to supplement their own testimony to provide a more solid case as to how much the client is owed. Since most potential clients carry low-cost phones (typically Android) and do not location history tracking, this solution would prove to be incredibly helpful as a starting point for reconstructing a client’s court-admissible time sheet for their case, giving CLS lawyers + paralegals a completely new source of evidence from a reliable source.

Project User flow:

Our optimal user flow worked out to the following (note, I am putting pictures of this from our live product for you to better visualize these requirements):

undefined

A user should be able to add their LocationHistory.json file (downloaded from Google Takeout).

undefined

A user should then be able to have their location data processed and displayed on a map

undefined

A user should then be able to select a bounding box area containing the rough area of their work place.

undefined

A user should then be able to select a start day for the week and submit the file for processing.

undefined

The location history should then be processed into a .csv file. This file should have rows containing the amount of time a user spent within a bounding box for a workplace (along with start and end times).
If a user leaves and then enters a workplace, these should appear as separate rows. At the end of a week, the total amount of hours should be tabulated and displayed in a separate column.

On top of everything, all of this had to be done on the front end to avoid privacy issues with storing location data on our servers. These requirements alone seemed to be relatively easy to do. Little did I realize that parsing and displaying a LocationHistory.json file would probably be the most challenging task.

Google LocationHistory.json Structure & First Attempt At Loading:

undefined

In case you did not know, Google keeps an eye on almost everything you do. More specifically, they do keep track of your Location History if you have an android phone and have not turned it off by now. If you want, you can download your history to date by going to takeout.google.com/settings/takeout and downloading your file in JSON format (be warned…it can be enormous).

My LocationHistory.json alone was about 59.9 MB in size (I had an Android phone for about two years), but some of the clients who would be using our system could have location histories a few hundred megabytes in size. Trying to just load the whole JSON file into memory causes the browser to hang for approximately 30 seconds before triggering the classic “Aw Snap” error on chrome (usually indicating an out of memory error).

undefined

In fact, when running this on a more powerful machine, we can take a memory snapshot and try and see what is going on. For reference, I used a 59.9 MB file that I loaded into memory.

undefined

Here, we see that the resulting JS Heap size is nearly triple the actual file size. But in reality, we don’t need to store the whole array in memory, parse it for location data points, and then feed those points into a function that displays them on a map. We could just do this all on the fly…however, that is easier said than done.

Chunking & Oboe:

The first solution I thought of was to try and split the file into more manageable chunks of 512 kilobytes at a time. However, this has some inherent flaws with it, mainly that the file that I am trying to load in contains a large “string” that has the format of a JSON object (but isn’t an object yet). Thus when I decide to split and process the file in sequential pieces that are 512 KB long, I can easily run into a situation where I cut an “object” in half.

So now I needed a way to keep track of half completed objects/objects that were cut off and prepend/append them to the following chunks accordingly to make sure that everything would parse correctly. Though the Google LocationHistory.json file is relatively uniform, the way that chunks can be split is not. Luckily there is an existing library to help take care of all the edge cases that can arise. Enter Oboe.js.

Oboe.js is built for dealing with JSON coming from a streaming source. Additionally, it can load JSON trees larger than the available memory on the client as it only processes one JSON node at a time and then drops the node from the memory tree. However, I do not have a streaming source of data. Luckily, after looking around the Oboe codebase for a bit, I found that oboe can be instantiated and passed data through an emit event.

The oboe code itself is relatively easy to set up. The JSON file we are looking at has the general form of the following.

{   
  "locations": \[ {  
    "timeStampMs": ...,  
    "latitudeE7": ...,  
    "longitudeE7": ...,  
    "accuracy": ...  
  }, {  
    "timeStampMs": ...,  
    "latitudeE7": ...,  
    "longitudeE7": ...,  
    "accuracy": ...  
  },  
  ...  
  \]  
}

Per Oboe documentation, the locations node should be targeted and any sub object of that will be passed into the callback function as shown in the code sample below.

undefined
undefined

Next, we need to figure out a way to pass in chunks to this function. The chunking function itself is a little bit more complicated, but the main functionality is to process the file in 512 KB portions at a time. The function takes in the file itself (from an input) and the instance of oboe.js (in our case the os variable).

Note on line 11 the following:

oboeInstance.emit('data', chunk);

That line contains the crux of the processing by oboe. The chunk will be sent to our oboe instance in the os variable as a quasi-stream of data.

Displaying the Points:

The last thing to take care of is displaying the data. We chose to use leaflet.js because it was fairly simple to set up and it has a much more diverse 3rd party library ecosystem than Google maps (or any other map library out there that I know of).

Initializing the map on a div with id='mapid' is fairly straightforward:

However, displaying over 1 million location data points requires much more than what the base leaflet.js library can handle. Fortunately, many open source solutions utilize Hierarchical greedy clustering to cluster points at low zoom levels and de-cluster them as the zoom level increases. Vladimir Agafonkin from Mapbox wrote an excellent blog on the algorithmic side of how this process works, and I would highly encourage you to check it out.

An existing implementation of marker clustering for leaflet exists already with the PruneCluster library. This library sets itself apart from the others because it has no real upper limit to how many points it can process (it is only constrained by the computing power of the client). The resulting render and update times are amazing.

Going back to our oboe.js instance code, we can edit it slightly to account for the PruneCluster library addition:

Results:

After making all the changes above, I was finally able to do some basic tests to see if whether all these optimizations would be worth it. Below are the results (at each file size five trials were done and the time is the average).

undefined

The results were stunning. Although loading the file straight into memory was faster for smaller files, the chunking with oboe stream paid off in the end and gave a nearly linear correlation between load time and file size! In the end, we attached a loading bar to the analyzer to give the user a sense of progress and attached some load time statistics to it.

undefined

And there you have it. Parsing of Google Location History on the frontend. No server needed. In fact, I am hosting the website on github page right now at hack4impact.github.io/cls.

Overall, this project was a huge success. During the semester, I interacted with some of the incredible people at Community Legal Services to create this product which will aid many legal workers for years to come. I would highly encourage those who know how to program to volunteer their skills to assist community organizations better achieve their mission. It is an incredibly rewarding experience for both parties and will challenge you to apply your skills towards creating sustainable and functional products.

You can find the source code for the project at our repository.

My full team is: Product Manager: Krishna Bharathala, Team Members: Katie Jiang, Daniel Zhang, Santi Buenahora, and Rachel H.

By Abhinav Suri on March 20, 2017.

NextJS, Contentful CMS, GraphQL, oh my!

Ben Holmes — Wed, 04 Nov 2020 22:42:55 +0000

We built the new Hack4Impact.org in a month-long sprint once we had designs in hand. To move this fast, we needed to make sure that we used tools that played to our strengths, while setting us up for success when designers and product managers want to update our copy. As the title excitedly alludes to, NextJS + Contentful + GraphQL was the match for us!

No, this post won't help you answer what tools should I use to build our site's landing page? But it should get your gears turning on:

How to access Contentful's GraphQL endpoints (yes, they're free-to-use now!) 📝
How to talk to GraphQL server + debug with GraphiQL 📶
How we can roll query results into a static NextJS site with getStaticProps 🗞
Going further with rich text 🚀

Onwards!

Wait, why use these tools?

Some readers might be scoping whether to adopt these tools at all. As a TLDR:

NextJS was a great match for our frontend stack, since we were already comfortable with a React-based workflow and wanted to play to our strengths. What's more, NextJS is flexible enough to build some parts of your website statically, and other parts dynamically (i.e. with serverside rendering). This is pretty promising as our landing site expands, where we might add experiences that vary by user going forward (admin portals, nonprofit dashboards, etc).
Contentful is one of the more popular "headless CMSs" right now, and it's easy to see why. Content types are more than flexible enough for our use cases, and the UI is friendly enough for designers and product managers to navigate confidently. It thrives with "structured content" in particular which is great for static sites like ours! Still, if you're looking for a simplified, key-value store for your copy, there are some shiny alternatives to consider.
GraphQL is the perfect pairing for a CMS in our opinion. You simply define the "shape" of the content you want (with necessary filtering and sorting), and the CMS responds with the associated values. We'll dive into some code samples soon, but it's much simpler than a traditional REST endpoint.

Note: There's roughly 10 billion ways to build a static site these days (citation needed), with another 10 billion blog posts on how to tackle the problem. So don't take these reasons as prescriptive for all teams!

Setting up our Contentful environment

Let's open up Contentful first. If you're 100% new to the platform, Contentful documents a lot of core concepts over here to get up to speed on "entries" and "content models."

When you're feeling comfortable, whip up a new workspace and create a new content model of your choosing. We'll use our "Executive Board Member" model as an example here.

Once you've saved this model, go and make some content entries in the "Content" panel. We'll be pulling these down with GraphQL later, so I recommend making more than 1 entry to demo sorting and filtering! You can filter by your content type for a sanity check:

Before moving on, let's get some API keys for our website to use. Just head to "Settings > API keys" and choose "Add API key" in the top right. This should allow you to find two important variables: a Space ID and a Content Delivery API access token. You'll need these for some important environment variables in your local repo.

Whipping up a basic NextJS site

If you already have a Next project to work off of, great! Go cd into that thing now. Otherwise, it's super easy to make a NextJS project from scratch using their npx command:

npx create-next-app dope-contentful-example

💡 Note: You can optionally include the --use-npm flag if you want to ditch Yarn. By default, Next will set up your project with Yarn if you have it installed globally. It's your prerogative though!

You may have found a "NextJS + Contentful" example in the Next docs as well. Don't install that one! We'll be using GraphQL for this demo, which has a slightly different setup.

Now, just cd into your new NextJS project and create a .env file with the following info:

NEXT_PUBLIC_CONTENTFUL_SPACE_ID=[Your Space ID from Contentful]
NEXT_PUBLIC_CONTENTFUL_ACCESS_TOKEN=[Your Content Delivery API access token from Contentful]

Just fill these in with your API keys and you're good to go! Yes, the NEXT_PUBLIC prefix is necessary for these to work. It's a little verbose, but it allows Next to pick up your keys without the hassle of setting up, say, dotenv.

Fetching some GraphQL data

Alright, so we've set the stage. Now let's fetch our data!

We'll be using GraphiQL to view our "schemas" with a nice GUI. You can install this tool here, using either homebrew on MacOS or the Linux Subsystem on Windows. Otherwise, if you want to follow along as a curl or Postman warrior, be my guest!

Opening the app for the first time, you should see a screen like this:

Let's point GraphiQL to our Contentful server. You can start by entering the following URL, filling in [Space ID] with your API key from the previous section:

https://graphql.contentful.com/content/v1/spaces/[Space ID]

If you try to hit the play button ▶️ after this step, you should get an authorizaton error. That's because we haven't passed an access token with our query!

To fix this, click Edit HTTP Headers and create a new header entry like so, filling in [Contentful access token] with the value from your API keys:

After saving, you should see some info appear in your "Documentation Explorer." If you click on the query: Query link, you'll see an overview of all your Content models from Contentful.

Neat! From here, you should see all of the content models you created in your Contentful space. You'll notice there's a distinction between individual entries and a "collection" (i.e. executiveBoardMember vs. executiveBoardMemberCollection). This is because each represents a different query you can perform in your API call. If this terminology confuses you, here's a quick breakdown:

items highlighted in blue represent queries you can perform. These are similar to REST endpoints, as they accept parameters and return a structured response. The main difference is being able to nest queries within other queries to retrieve nested content. We'll explore this concept through example.
items highlighted in purple represent parameters you can pass for a given query. As shown in the screenshot above, you can query for an individual ExecutiveBoardMember based on id or locale (we'll ignore the preview param for this tutorial), or query for a collection / list of members (ExecutiveBoardMemberCollection) filtering by locale, amount of entries (limit), sort order, and a number of other properties.
items highlighted in yellow represent the shape of the response you receive from a given query. This allows you to pull out the exact keys of a given content entry that you want, with type checking built-in. Each of these are hyperlinks, so click on them to inspect the nested queries and response types!

Getting our hands dirty

Let's jump into an example. First, let's just get the list of names and emails for all "Executive Board Member" entries. If you're following along with your own Contentful space, just pick a few text-based keys you want to retrieve from your content model. Since we're looking for multiple entries, we'll use the executiveBoardMemberCollection query for this.

Clicking into the yellow ExecutiveBoardMemberCollection link (following the colon : at the end of the query), we should see a few options we're free to retrieve: total, skip, limit, and items. You'll see these 4 queries on every collection you create, where items represents the actual list of items you're hoping to retrieve. Let's click into the response type for items to see the shape of our content:

This looks really similar to the content model we wrote in Contentful! As you can see, we can query for any of these fields to retrieve a response (most of them being strings in this example).

Writing your first query

Alright, we've walked through the docs and found the queries we want... so how do we get that data?

Well, the recap, here's the basic skeleton of info we need to retrieve:

executiveBoardMemberCollection -> query for a collection of entries
  items -> retrieve the list items
    name -> retrieve the name for each list item
    email -> and the email

We can convert this skeleton to the JSON-y syntax GraphQL expects:

{
  executiveBoardMemberCollection {
    items {
      name
      email
    }
  }
}

... and enter this into GraphiQL's textbox and hit play ▶️

Boom! There's all the data we entered into Contentful, formatted as a nice JSON response. If you typed your query into GraphiQL by hand, you may have noticed some nifty autocomplete as you went. This is the beauty of GraphQL: since we know the shape of any possible response, it can autofill your query as you go! 🚀

Applying filters

You may have noticed some purple items in parenthesis while exploring the docs. These are parameters we can pass to Contentful to further refine our results.

Let's use some of the collection filters as an example; say we only want to retrieve board members that have a LinkedIn profile. We can apply this filter using the where parameter:

As you can see, where accepts an object as a value, where we can apply a set of pre-determined filters from Contentful. As we type, we're greated with a number of comparison options that might remind you of SQL, including the exists operator for nullable values. You can find the complete list of supported filters in the docs off to the right, but autocomplete will usually take you to the filter you want 💪

In our case, our query should look something like this:

executiveBoardMemberCollection(where: {linkedIn_exists: true}) { ... }

...and our result should filter out members without a LinkedIn entry.

Pulling our data into NextJS

Alright, we figured out how to retrieve our data. All we need is an API call on our NextJS site and we're off to the races 🏎

Let's pop open a random page component in our /pages directory and add a call to getStaticProps():

// pages/about
export async function getStaticProps() {
  return {
    props: {
      // our beautiful Contentful content
    }
  }
}

If you're unfamiliar with Next, this function allows you to pull in data while your app is getting built, so you access that data in your component's props at runtime. This means you don't have to call Contentful when your component mounts! The data is just... there, ready for you to use 👍

💡 Note: There's a distinction between getting these props "on every page request" versus retrieval "at build time." For a full rundown of the difference, check out the NextJS docs.

Inside this function, we'll make a simple call to Contentful using fetch (but feel free to use axios if that's more your speed):

export async function getStaticProps() {
  // first, grab our Contentful keys from the .env file
  const space = process.env.NEXT_PUBLIC_CONTENTFUL_SPACE_ID;
    const accessToken = process.env.NEXT_PUBLIC_CONTENTFUL_ACCESS_TOKEN;

  // then, send a request to Contentful (using the same URL from GraphiQL)
  const res = await fetch(
      `https://graphql.contentful.com/content/v1/spaces/${space}`,
      {
        method: 'POST', // GraphQL *always* uses POST requests!
        headers: {
          'content-type': 'application/json',
          authorization: `Bearer ${accessToken}`, // add our access token header
        },
        // send the query we wrote in GraphiQL as a string
        body: JSON.stringify({
          // all requests start with "query: ", so we'll stringify that for convenience
          query: `
          {
            executiveBoardMemberCollection {
              items {
                name
                email
              }
            }
          }
                `,
        },
      },
    );
    // grab the data from our response
    const { data } = await res.json()
  ...
}

Woah, that's a lot going on! In the end, we're just re-writing the logic that GraphiQL does under the hood. Some key takeaways:

We need to grab our API keys for the URL and authorization header. This should look super familiar after our GraphiQL setup!
Every GraphQL query should be a POST request. This is because we're sending a body field to Contentful, containing the "shape" of the content we want to receive.
Our query should start with the JSON key { "query": "string" }. To make this easier to type, we create a JavaScript object starting with "query" and convert this to a string.

🏁 As a checkpoint, add a console.log statement to see what our data object looks like. If all goes well, you should get a collection of contentful entries!

Now, we just need to return the data we want as props (in this case, the items in our executiveBoardMemberCollection):

export async function getStaticProps() {
    ...
  return {
    props: {
        execBoardMembers: data.executiveBoardMemberCollection.items,
    },
  }
}

...and do something with those props in our page component:

function AboutPage({ execBoardMembers }) {
  return (
    <div>
        {execBoardMembers.map(execBoardMember => (
        <div className="exec-member-profile">
            <h2>{execBoardMember.name}</h2>
          <p>{execBoardMember.email}</p>
        </div>
      ))}
    </div>
  )
}

export default AboutPage;

Hopefully, you'll see your own Contentful entries pop onto the page 🎉

Writing a reusable helper functions

This all works great, but it gets pretty repetitive generating this API call on every page. That's why we wrote a little helper function on our project to streamline the process.

In short, we're gonna move all our API call logic into a utility function, accepting the actual "body" of our query as a parameter. Here's how that could look:

// utils/contentful
const space = process.env.NEXT_PUBLIC_CONTENTFUL_SPACE_ID;
const accessToken = process.env.NEXT_PUBLIC_CONTENTFUL_ACCESS_TOKEN;

export async function fetchContent(query) {
  // add a try / catch loop for nicer error handling
  try {
    const res = await fetch(
      `https://graphql.contentful.com/content/v1/spaces/${space}`,
      {
        method: 'POST',
        headers: {
          'content-type': 'application/json',
          authorization: `Bearer ${accessToken}`,
        },
        // throw our query (a string) into the body directly
        body: JSON.stringify({ query }),
      },
    );
    const { data } = await res.json();
    return data;
  } catch (error) {
    // add a descriptive error message first,
    // so we know which GraphQL query caused the issue
    console.error(`There was a problem retrieving entries with the query ${query}`);
    console.error(error);
  }
}

Aside from our little catch statement for errors, this is the same fetch call we were making before. Now, we can refactor our getStaticProps function to something like this:

import { fetchContent } from '@utils/contentful'

export async function getStaticProps() {
  const response = await fetchContent(`
        {
            executiveBoardMemberCollection {
                items {
                name
                email
            }
          }
      }
  `);
  return {
    props: {
      execBoardMembers: response.executiveBoardMemberCollection.items,
    }
  }
}

...and we're ready to make Contentful queries across the site ✨

Aside: use the "@" as a shortcut to directories

You may have noticed that import statement in the above example, accessing fetchContent from @utils/contentful. This is using a slick webpack shortcut under the hood, which you can set up too! Just create a next.config.json that looks like this:

{
  "compilerOptions": {
    "baseUrl": "./",
    "paths": {
      "@utils/*": ["utils/*"],
      "@components/*": ["components/*"]
    },
  }
}

Now, you can reference anything inside /utils using this decorator. For convenience, we added an entry for @components as well, since NextJS projects tend to pull from that directory a lot 👍

Using a special Contentful package to format rich text

Chances are, you'll probably set up some rich text fields in Contentful to handle hyperlinks, headers, and the like. By default, Contentful will return a big JSON blob representing your formatted content:

...which isn't super useful on its own. To convert this into some nice HTML, you'll need a special package from Contentful:

npm i --save-dev @contentful/rich-text-html-renderer

This will take in the JSON object and (safely) render HTML for your component:

import { documentToHtmlString } from '@contentful/rich-text-html-renderer';

function AboutPage(execBoardMember) {
  return (
    <div
    dangerouslySetInnerHTML={{
    __html: documentToHtmlString(execBoardMember.description.json),
    }}></div>
  )
}

Yes, using dangerouslySetInnerHTML is pretty tedious. We'd suggest making a RichText component to render your HTML.

Check out our project to see how we put it together 🚀

If you're interested, we deployed our entire project to a CodeSandbox for you to explore!

Head over here to see how we retrieve our executive board members on our about page. Also, check out the utils/contentful directory to see how we defined our schemas using TypeScript.

Our repo is 100% open as well, so give it a ⭐️ if this article helped you!

Learn a little something?

Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!

Subscribe away right here. I promise to always teach and never spam ❤️

Building a sexy, mobile-ready navbar in any web framework

Ben Holmes — Tue, 06 Oct 2020 22:44:09 +0000

I've been building a lot more static sites recently, and every one of them needs the same thing:

A nice and responsive navigation bar with logo on the left, links on the right 💪
For mobile screens, collapse those links on the right into a hamburger menu with a dropdown 🍔
Hit all the marks for accessibility: semantic HTML, keyboard navigation, and more ♿️
Add some polished animations for that sleek, modern feel ✨

Oh, and implement it using whatever framework the team is using. This may sound daunting... but after bouncing between React, Svelte, and plain-ole JS, and I think I've found a solid solution you can take with you wherever you go.

Onwards!

First, what's the end goal?

Here's a screen-grab from my most recent project: redesigning the Hack4Impact nonprofit site.

Ignore the cats. We needed some purrfect placeholders while we waited on content 😼

This has some fancy bells and whistles like that background blur effect, but it covers the general "formula" we're after!

Lay down some HTML

Let's define the general structure of our navbar first.

<nav>
    <a class="logo" href="/">
    <img src="dope-logo.svg" alt="Our professional logo (ideally an svg!)" />
  </a>
  <button class="mobile-dropdown-toggle" aria-hidden="true">
    <!-- Cool hamburger icon -->
  </button>
  <div class="dropdown-link-container">
    <a href="/about">About Us</a>
    <a href="/work">Our Work</a>
    ...
  </div>
</nav>

A few things to note here:

We're not using an unordered list (ul) for our links here. You might see this recommendations floating around the web, and it's certainly a valid one! However, this nuanced for / against piece from Chris Coyier really solidified things for me. In short: lists aren't required for a11y concerns (the problem is minimal at best), so we can ditch them if we have a fair reason to do so. In our case, we actually need to ditch the list so we can add our dropdown-link-container without writing invalid HTML. To understand what I mean, I clarified the issue to a kind commenter here!
You'll notice our dropdown-link-container element, which wraps around all our links except the logo. This div won't do anything fancy for desktop users. But once we hit our mobile breakpoint, we'll hide these elements in a big dropdown triggered by our mobile-dropdown-toggle button.
We're slapping an aria-hidden attribute on our dropdown toggle. For a simple nav like this, there's no reason for a screenreader to pick up on this button; it can always pick up on all our links even when they're "visually hidden", so there's no toggling going on 🤷‍♀️ Still, if you really want to mimic the "toggle" effect for these users (which you should for super busy navbars), you can look into adding aria-expanded to your markup. This is getting a bit in the weeds for this article though, so you can use my easy-out for now.

For those following along at home, you should have something like this:

Now, some CSS

Before worrying about all that mobile functionality, let's spiff up the widescreen experience.

Our base styles

To start, we'll set up the alignment and width for our navbar.

nav {
  max-width: 1200px; /* should match the width of your website content */
  display: flex;
  align-items: center; /* center each of our links vertically */
  margin: auto; /* center all our content horizontally when we exceed that max-width */
}

.logo {
  margin-right: auto; /* push all our links to the right side, leaving the logo on the left */
}

.dropdown-link-container > a {
  margin-left: 20px; /* space out all our links */
}

.mobile-dropdown-toggle {
  display: none; /* hide our hamburger button until we're on mobile */
}

The max-width property is an important piece here. Without it, our nav links will get pushed wayyyy to the right (and our logo wayyyy to the left) for larger screens. Here's a little before-and-after to show you what I mean.

*Before: * Our nav elements stick to the edges of the screen. This doesn't match up with our page content very well, and makes navigation awkward on larger devices.

*After: * Everything is beautifully aligned, making our website a lot more "scan-able."

Of course, you can add padding, margins, and background colors to-taste 👨‍🍳 But as long as you have a max-width and margin: auto for centering the nav on the page, you're 90% done already! Here's another pen to see it in action:

Adding the dropdown

Alright, now let's tackle our dropdown experience. First, we'll just focus on re-styling our links into a vertical column that takes up the height of the page:

@media (max-width: 768px) { /* arbitrary breakpoint, around the size of a tablet */
  .dropdown-link-container {
    /* first, make our dropdown cover the screen */
    position: fixed;
    top: 0;
    left: 0;
    right: 0;
    height: 100vh;
    /* fix nav height on mobile safari, where 100vh is a little off */
    height: -webkit-fill-available;

    /* then, arrange our links top to bottom */
    display: flex;
    flex-direction: column;
    /* center links vertically, push to the right horizontally.
       this means our links will line up with the rightward hamburger button */
    justify-content: center;
    align-items: flex-end;

    /* add margins and padding to taste */
    margin: 0;
    padding-left: 7vw;
    padding-right: 7vw;

    background: lightblue;
  }
}

This is pretty standard for the most part. Just a few things of note here:

First, we use position: fixed to align our dropdown to the top of our viewport. This is distinct from position: absolute, which would shift the nav's position depending on our scroll position 😬

Then, we use the -webkit-fill-available property to fix our nav height in mobile Safari. I'm sure you're thinking "what, how is 100vh not 100% of the user's screen size? What did Apple do this time?" Well, the problem comes from the iOS' disappearing URL bar. When you scroll, a bunch of UI elements slide out of the way to give you more screen real estate. That's great and all, but it means anything that used to take up 100% of the screen now needs to be resized! We have this problem on our Bits of Good nonprofit homepage:

Notice the links aren't quite vertically centered until we swipe away all the Safari buttons. If you have a bunch of links, this could lead to cut-off text and images too!

In the end, all you need is the override height: -webkit-fill-available to specifically target this issue. Yes, feature flags like -webkit are usually frowned upon. But since this issue only pops up in mobile Safari (a webkit browser), there really isn't a problem with this approach in my opinion 🤷‍♀️ Worst case, the browser falls back to 100vh, which is still a totally usable experience.

Finally, let's make sure our logo and dropdown buttons actually appear on top of our dropdown. Because of position:fixed, the dropdown will naturally hide everything underneath it until we add some z-indexing:

@media (max-width: 768px) {
  .logo, .mobile-dropdown-toggle {
    z-index: 1;
  }

  .mobile-dropdown-toggle {
    display: initial; /* override that display: none attribute from before */
  }

  .dropdown-link-container {
    ...
    z-index: 0; /* we're gonna avoid using -1 here, since it could position our navbar below other content on the page as well! */
  }
}

Squoosh this CodePen to our breakpoint size to see these styles at work:

Let's animate that dropdown

Alright, we have most of our markup and styles finished up. Now, let's make that hamburger button do something!

We'll start with handling the menu button clicks. To show you how simple this setup is, I'll just use vanilla JS:

// get a ref to our navbar (assuming it has this id)
const navElement = document.getElementById("main-nav");

document.addEventListener("click", (event) => {
  if (event.target.classList.contains("mobile-dropdown-toggle")) {
    // when we click our button, toggle a CSS class!
    navElement.classList.toggle("dropdown-opened");
  }
});

Now, we'll animate our dropdown into view whenever that dropdown-opened class gets applied:

/* inside the same media query from before */
@media (max-width: 768px) {
  ...
  .dropdown-link-container {
    ...
    /* our initial state */
    opacity: 0; /* fade out */
    transform: translateY(-100%); /* move out of view */
    transition: transform 0.2s, opacity 0.2s; /* transition these smoothly */
  }

  nav.dropdown-opened > .dropdown-link-container {
    opacity: 1; /* fade in */
    transform: translateY(0); /* move into view */
  }
}

Nice! With just a few lines of CSS, we just defined a little fade + slide in effect whenever we click our dropdown. You can mess around with it here. Modify the transitions however you wish!

Adapting for big boy components

Alright, I know some of you want to slide this in your framework of choice at this point. Well, it shouldn't be too difficult! You can keep all the CSS the same, but here's a component snippet you can plop into React:

export const BigBoyNav = () => {
    const [mobileNavOpened, setMobileNavOpened] = useState(false);
    const toggleMobileNav = () => setMobileNavOpened(!mobileNavOpened);

  return (
    <nav className={mobileNavOpened ? 'dropdown-opened' : ''}>
      ...
      <button class="mobile-dropdown-toggle" onClick={toggleMobileNav} aria-hidden="true">
    </nav>
    )
}

And one for Svelte:

<!-- ...might've included this to show how simple Svelte is :) -->
<script>
    let mobileNavOpened = false
  const toggleMobileNav = () => mobileNavOpened = !mobileNavOpened;
</script>

<nav className:mobileNavOpened="dropdown-opened">
    ...
  <button class="mobile-dropdown-toggle" on:click={toggleMobileNav} aria-hidden="true">
</nav>

...You get the point. It's a toggle 😆

The little things

We have a pretty neat MVP at this point! I just left a couple accessiblity pieces for the end to get you to the finish line 🏁

Collapse that dropdown when you click a link

Note: You can skip this if you're using a vanilla solution like Jekyll, Hugo or some plain HTML. In those cases, the entire page will reload when you click a link, so there's no need to hide the dropdown!

If we're gonna cover the users entire screen, we should probably hide that dropdown again once they choose the link they want. We could just any click events in our dropdown like so:

document.addEventListener('click', event => {
  // if we clicked on something inside our dropdown...
  if (ourDropdownElement.contains(event.target)) {
    navElement.classList.remove('dropdown-opened')
  }
})

...but this wouldn't be super accessible 😓. Sure, it handles mouse clicks, but how will it fare against keyboard navigation with the "tab" key? In that case, the user will tab to the link they want, hit "enter," and stay stuck in dropdown-opened without any feedback!

Luckily, there's a more "declarative" way to get around this problem. Instead of listening for user clicks, we can just listen for whenever the route changes! This way, we don't need to consider how the user navigates through our dropdown links; Just listen for the result.

Of course, this solution varies depending on your router of choice. Let's see how NextJS handles this problem:

export const BigBoyNav = () => {
  const router = useRouter(); // grab the current route with a React hook
  const activeRoute = router.pathname;

  ...
  // whenever "activeRoute" changes, hide our dropdown
  useEffect(() => {
    setMobileNavOpened(false);
  }, [activeRoute]);
}

Vanilla React Router should handle this problem the same way. Regardless of your framework, just make sure you trigger your state change whenever the active route changes 👍

Handle the "escape" key

For even better keyboard accessiblity, we should also toggle the dropdown whenever the "escape" key is pressed. This is bound to a very specific user interaction, so we're free to add an event listener for this one:

// vanilla JS
const escapeKeyListener = (event: KeyboardEvent) =>
    event.key === 'Escape' && navElement.classList.remove('dropdown-opened')

document.addEventListener('keypress', escapeKeyListener);

...and for component frameworks, make sure you remove that event listener whenever the component is destroyed:

// React
useEffect(() => {
  const escapeKeyListener = (event: KeyboardEvent) =>
  event.key === 'Escape' && setMobileNavOpened(false);

  // add the listener "on mount"
  document.addEventListener('keypress', escapeKeyListener);
  // remove the listener "on destroy"
  return () => document.removeEventListener('keypress', escapeKeyListener);
}, []);

See a fully-functional React example 🚀

If you're curious how this could all fit together in a React app, our entire Hack4Impact website is accessible on CodeSandbox!

To check out the Nav component, head over here.

Learn a little something?

Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!

Subscribe away right here. I promise to always teach and never spam ❤️

DEV Community: Hack4Impact

Another way to understand JavaScript's array.reduce

🎥 Video walkthrough

📝 Step-by-step cheatsheet

Going from forEach to reduce

So wait, why do I even need reduce?

Learn a little something?

A shiny-on-hover effect that follows your mouse (CSS) ✨

Our end goal

🎈 Brief primer on CSS variables

CSS variables to the rescue

✨ Let's get rolling on our shiny button

🪤 Now, lets track some mouse cursors

💅 Pipe those coordinates into CSS

Fade into our effect on entry

🔨 Adapt to your framework of choice

React example

Svelte example

Check out our live example on Hack4Impact

Learn a little something?

How we built an app that uses worker location history to combat wage theft

Project User flow:

Google LocationHistory.json Structure & First Attempt At Loading:

Chunking & Oboe:

Displaying the Points:

Results:

NextJS, Contentful CMS, GraphQL, oh my!

Wait, why use these tools?

Setting up our Contentful environment

Whipping up a basic NextJS site

Fetching some GraphQL data

Getting our hands dirty

Writing your first query

Applying filters

Pulling our data into NextJS

Writing a reusable helper functions

Aside: use the "@" as a shortcut to directories

Using a special Contentful package to format rich text

Check out our project to see how we put it together 🚀

Learn a little something?

Building a sexy, mobile-ready navbar in any web framework

First, what's the end goal?

Lay down some HTML

Now, some CSS

Our base styles

Adding the dropdown

Let's animate that dropdown

Adapting for big boy components

The little things

Collapse that dropdown when you click a link

Handle the "escape" key

See a fully-functional React example 🚀

Learn a little something?

Going from `forEach` to `reduce`

So wait, why do I even need `reduce`?