DEV Community: Kim Hart

How to Implement "dark mode" with Gatsby & React Hooks

Kim Hart — Thu, 01 Aug 2019 22:40:47 +0000

I recently launched my new portfolio site and I have to say, I'm super proud! My old site was built on Wix years before I learned how to code and was in need of a major design update.

I landed on Gatsby for my setup and Netlify for my deployment platform and guys, I cannot recommend each of them enough. But this post isn't about that!

Why dark mode?

Turns out, a lot of people like dark-themed internet things (just ask Twitter). I chose to implement toggleable sunrise and sunset themes on my portfolio because it adds a level of interactivity to my otherwise static site, allowed me to play with more complex CSS, and it lets users customize their experience. It even persists through sessions via localStorage!

What'd I use?

I considered building this myself until I found this tool called use-dark-mode. In short, it's a custom React Hook that handles the storage part for you. Their docs are pretty great, but I'll walk you through my use case as well.

Implementation

You must use react@16.8.0 or greater which includes Hooks
This only works in functional components, so if you're using older React class components with non-hook lifecycle methods, you may have a hard time.

1. Install

You'll install both use-dark-mode and its Gatsby-specific plugin that helps with overall rendering of your themes:

yarn add use-dark-mode gatsby-plugin-use-dark-mode

2. Add to Gatsby config

To prevent a flash of default-styled content on page load, add this block to your gatsby-config.js file. (More in the docs)

{
  resolve: "gatsby-plugin-use-dark-mode",
  options: {
     classNameDark: "dark-mode",
     classNameLight: "light-mode",
     storageKey: "darkMode",
     minify: true,
  },
}

Note: you can name these classes whatever you like! I stuck with the defaults.

3. Add to React

Here's a ultra-simplified version of my hero component. It contains two icon components (sunrise and sunset) that fire handleTheme on click, which launch either darkMode.enable() or darkMode.disable() depending on their props.

The goal here is to change to dark mode when you click sunset, and light mode when you click sunrise.


import React from "react"
import useDarkMode from "use-dark-mode"
import Sunrise from "../components/icons/sunrise"
import Sunset from "../components/icons/sunset"

const Hero = () => {
  // Instantiate with the default behavior, in this case, it defaults to light-mode
 // This places "light-mode" class on document.body, as outlined in my gatsby-config.js
  const darkMode = useDarkMode(false);

  // Custom function that handles the toggling
  // When called, it replaces the class on document.body and holds it in localStorage
  const handleTheme = theme => theme === "dark" ? darkMode.enable() : darkMode.disable();

  return (
    <div className="hero">
      <Sunrise onClick={handleTheme} />
      <Sunset onClick={handleTheme} />
    </div>
  )
}

export default Hero;

The sunset and sunrise icon components are super similar, they just pass different values ("light" and "dark"). Here's a slimmed-down version of Sunset:

import React from "react"

const Sunset = (props) => {
  // If the `onClick` prop exists, call it with 'dark'
  const handleClick = () => props.onClick && props.onClick('dark');

  return (
    <div className="theme-toggle" onClick={handleClick}>...</div>
  )
}

Note: you could also accomplish this with passing boolean values (i.e. "true" for dark, but I chose to keep it more readable and used strings)

CSS

Now that we have the class on document.body toggling between light-mode and dark-mode when we click the sunrise or sunset icons, we can adjust our CSS to reflect the changes.

I used Less, which makes it super easy to apply rules based on parent values. Again, this is simplified, but hopefully you get the idea.

The .dark-mode & selector will look for anytime the dark-mode class exists on a higher component (in this case, the body tag). You can then apply whatever rules you need — in this case it's a variable for the background colors.

   .hero {
      background: @sunrise-gradient;
      .dark-mode & {
        background: @sunset-gradient;
      }
    }

... and that's it!

Conclusion

You don't have to completely recreate the wheel to implement dark mode in a Gatsby app. Hopefully this was helpful and I'm happy to answer any questions in the comments!

What Do You Look For in a Mentor?

Kim Hart — Fri, 13 Jul 2018 01:35:14 +0000

Front end engineer here, looking to make a positive impact on the growth of new devs 💪

When you first started your programming journey — what are some of the concepts/workflows/teaching techniques that your first mentors really knocked out of the park, and why?

If your experiences haven't been super positive, what would make the learning process easier and more enjoyable for you? What would you change about the industry to make it less intimidating and more empathetic?

Let's hear it in the comments!

5 Lessons My Bootcamp Didn't Teach Me

Kim Hart — Sat, 01 Apr 2017 23:42:14 +0000

As a career-changer, I can wholeheartedly say that I wouldn't have learned to code without going to General Assembly. They planned the curriculum, taught us the lingo, held us accountable, and gave us a support system of classmates, teachers, and TAs. They also sold us a shiny promise that we'd easily land a $80k+ job with just four projects, a rewritten resume, and a can-do attitude. In hindsight, the last part seems ridiculous.

I loved every second of my program, but it failed to prepare me for the reality of the job hunt post-grad. I can chalk a lot of the deficiency up to my own blind optimism and naivetÃ©, but this lack of direction is a major flaw in the bootcamp model. While my experience doesn't apply to every bootcamp grad, it rings true for many of us and it needs to be addressed.

Here are 5 practicalities I've learned in my first year in the trenches (that my bootcamp didn't teach me):

1. Your first job as a developer should not be a solo gig.

When I graduated, I had a new job lined up within 24 hours. I was one of the first in my cohort to do so, and I was pumped. Holy shit, someone actually wants to pay me to do this! I got caught up in the excitement and failed to be selective in my search.

This company hired me as their first front-end developer. ðŸš¨ DANGER ðŸš¨ One thing became abundantly clear, and fast: "First developer" is often code for, "We have no idea what to do with you."

After joining, my manager regularly called me by the wrong title (UX person?) and questioned my legitimacy because I said being a designer, a front-end dev and a backend dev were three very different jobs, and I couldn't do them all. Their clients set impossible deadlines for my projects. They wouldn't grant me IT permissions to use the terminal, and eventually asked me to use my personal laptop instead. I left after 2 months.

Jobs like this won't give you equipment, structure, or professional guidance. Being marooned on a non-technical island is not the best way to grow as a brand new developer. That being said...

2. Don't take a job that doesn't require you to prove your skills up front.

I left the previous company to pursue a full-stack role at a different organization where I was again, the solo dev, but with even less oversight. This time, I was hired by a non-technical team to work on internal projects without any clearcut deadlines, and they trusted my skills implicitly. Cool! I have complete creative freedom, I thought.

A few weeks in, I realized they didn't care about my skills because they had no way to measure them. Because no one monitored my work, my performance was never subjected to praise or constructive criticism. I can't stress this enough: it is so easy to become complacent (and stagnant) in your skills if no one is around to challenge you.

This type of environment can also make your job vulnerable, or even dispensable. If software isn't a priority for anyone else at the company, it's likely that your position could be one budget meeting away from being cut. This happened to me, and it seems ridiculous (why did you even hire me?), but it's common in disorganized companies. Jobs like this are easy to land, and often hard to keep.

3. Technical interviews are no joke.

Since parting ways with the last company, I launched into a 6-month stretch of code challenges and technical interviews. It turns out, proving yourself worthy of a "real" dev job is really hard – it requires practice, confidence, and adaptability. My career coach at GA insisted, rather, that a sparkling LinkedIn profile would be our best asset in this race, and he disregarded the rest of the process.

Pro-tip: a well-worded LinkedIn does not make up for poor performance in a technical interview.

Here's a snapshot of some interview scenarios I encountered for junior/mid-level front end roles (some between 3-6 hours long):

Solving riddles and writing game-like algorithms with my screen shared on a projector in a room full of engineers (Palindromes, Fibonacci, Tic-Tac-Toe, etc.)
Pair programming to create a custom Sass animation with @keyframes
Working with a designer to build a page using their chosen preprocessor (Slim) and the company's custom Sass style guide
Racing through a timed, super-granular multiple choice syntax test
Answering theoretical questions like, "What's the difference between cookies and local storage?", "How does JS event propagation work?", "How can you improve loading time?", and "List the pros & cons of each browser."
Taking a handwritten test on fundamentals like, "What is a closure?", "How do you determine if a variable is an object?", "What does 45 + '17' evaluate to?", and, you guessed it, FizzBuzz.

While I found common themes in each challenge, the method changed each time, and GA failed to drill us on any of them. Take the preparation into your own hands. Read up on ways to stand out and pose thoughtful questions to your interviewers. Practice answering common questions with a friend. Try handwriting those riddle algorithms. Explain theoretical concepts out loud – it's harder than you think.

4. Rejection is going to become a familiar feeling

And it's not always your fault. Maybe your interviewer is having a bad day. Maybe they brought you in even though your skills don't completely align with the role. Maybe you're an "awesome culture fit", but they "went with a more experienced candidate". Maybe they said they want to hire you, but the budget for the role got yanked the next day. Maybe your recruiter just doesn't know wtf they're doing. I've been victim to all of this.

But what about when the failure is your fault? Technical interviews are highly intimidating – even very skilled developers often fail them. Maybe you studied browser quirks and sorting algorithms all night just to get quizzed on CSS instead. Maybe you completely freeze under pressure. Maybe you rely too heavily on Google. Maybe you need to brush up on the CS fundamentals. I'm also guilty of all of this.

If your experience is anything like mine, this trial-and-error process will cause a heaping sense of imposter syndrome. Every time I failed or a more experienced engineer outperformed me, I got a sinking feeling that I'd never be good enough. Even though I wrote code every day, listened to dev podcasts, went to networking events/meetups/conferences, read programming books, learned a few new libraries & frameworks, and built a handful of side projects, I still couldn't hack these interviews (pun intended). If you're doing all of these things and experiencing similar luck, keep at it. Stay immersed.

Professional rejection is an awful feeling, but it is completely normal. Know that you're getting wiser with each interview, and these failures rarely reflect on your overall potential or skill. Failing doesn't mean you're a bad developer –it means you need more practice, and the right fit has yet to come along.

This industry is also competitive as hell. I often came across job postings that already had 400+ applicants by the time I found them. By the end of 6 months, I applied to 211 jobs. These numbers are intimidating, but keep in mind that if you're getting in the door at all, you're doing something right. Keep practicing.

5. Landing a great job is a marathon, not a sprint

Bootcamps sell a short term solution for a long term goal. Students are told that they can abandon their careers, code for a few months, and come out the other end with an ROI comparable to that of a 4-year degree. The reality of that sentiment is still hotly debated.

The pure short-term hustle and instant-gratification vibe of a bootcamp evokes a sense that an amazing job will just appear when you graduate. In most cases, this couldn't be farther from the truth.

I wish someone had told me that this goal would take a healthy dose of failure, serious self-awareness, a whole lot of tenacity, and most of all... time. The transformation doesn't happen overnight.

Bootcampers: we're known in this industry for being scrappy self-starters and fast learners – don't let that end when your job hunt begins. Keep grinding, be selective, and land a job where your professional growth is a priority.

Bootcamps: let's get more practical in the career coaching arena, yes?

*** 8 Month Edit ***
I'm happy to report that by the time this post went live in April, I had just landed what's proven to be a highly creative, inclusive, technical role where I learn & grow every day. Just know that these jobs are out there – and a really tough interview process is not always a reflection of your skills or potential as an engineer. Keep going! ðŸ™ŒðŸ¼

Nevertheless, Kim Hart Coded

Kim Hart — Mon, 06 Mar 2017 21:26:07 +0000

I began coding because...

My marketing job had me feeling exhaustingly bored every day — it was tedious and my work didn't add much value to anyone's day. I hated answering the question, "So, what do you do?" I was craving something more challenging, more creative, more purposeful.

Learning to code seemed like a borderline unattainable goal for a girl who majored in journalism and was traditionally unskilled at math. More than a handful of people told me it was going to be too hard for me as a "right-brained" artist-type. Despite the apparent mountain in front of me, I couldn't shake the gut feeling that I should try to climb it anyway.

I started looking for inspiration in other female engineers who came from backgrounds other than computer science, and their stories were badass! I didn't want to waste any more of my career watching from the sidelines, so I quit my job, put myself in debt, and joined a boot camp. It was the best decision I've ever made.

I'm currently hacking on...

I'm co-founding a political web app that helps you keep track of your Senators and Congresspeople (how they vote, how often they show up to work, what bills they introduce, etc.) Eventually, we'll be able to tell you how well your ideologies match your reps' voting patterns. I'm building the front end with React, Relay, GraphQL and Node.js. Our API is built with Python and SQL, so it's been a huge learning experience all around.

I'm excited about...

Diving into different types of study material! I recently started checking out development books to get a better grasp on programming fundamentals. I'm currently reading Eloquent JavaScript by Marijn Haverbeke (highly recommend).

I've also become an advocate for tech podcasts recently. For my fellow front end devs, I recommend Front End Happy Hour — it's hosted by a really cool group of (male & female!) engineers from LinkedIn, Netflix and other power companies.

My advice for other women who code is...

For those just starting to learn:

Try not to let imposter syndrome get you down. Even if you're brand new and haven't touched GitHub or a text editor yet, don't let intimidation get the best of you. The learning curve is steep and everyone feels overwhelmed at some point. The fact that you've chosen to pursue this field means that you're tough, both intellectually and emotionally. Seek out mentorships and events through WomenWhoCode or GirlsWhoCode. Don't let anyone talk down to you, men or otherwise. You have good ideas, so speak with conviction. Don't be afraid to ask for help. Last but not least, build things that make you happy.

For the established engineers:

Y'all are awesome! Keep kicking ass, breaking glass ceilings, and practicing empathy with devs who are less experienced than you are. Your guidance (even via Twitter/Stack Overflow/forums) is more appreciated than you realize.