DEV Community: Ash

8 Things I've Learned in 12 Months on the Job

Ash — Tue, 26 Jul 2022 18:26:40 +0000

When I originally began writing this post I was a happily employed developer in a role that I enjoyed on a team that valued communication and mentorship. I struggled to continue writing it when I lost this job unexpectedly a couple weeks shy of 12 months.

Surely, the imposter syndrome reasoned, if I was no longer at the job I had no business writing a whole post intended to help and relate to others in a first role. But this is unproductive, and if being transitioned out of a role involuntarily means someone can’t write about their industry experience then we probably wouldn’t have very many bloggers.

In the last year I’ve experienced every feeling I was warned about while learning and job hunting - the frustration with endless meetings, the brain lag, the burnout, and that feeling you only get from closing 150 browser tabs after finally completing a ticket. Not every day was a good day, but every day presented an opportunity to grow in some way.

Because there’s power in iteration - several of these points appear on my first post 5 Things I’ve learned in 6 Weeks on the Job

1. Embrace your community.

Get to the know the developers around you! This is harder on a remote team, but it isn’t impossible. Make commitments to the meetings and show up for the people around you, the first step is becoming a familiar face.

2. Document, Document, Document.

I could talk about the power of good documentation all day - but this goes beyond documenting the things you need to, or the things you intend to share - document everything you can stand to.

I use Notion religiously, which is a project management and note-taking app (if you haven’t heard of it 👀). I keep a space for work using different templates, like the Journal Template to track individual tasks and larger projects, and calendar views to keep meeting notes in a logical order.

When I start a ticket I pop open a blank journal entry and track my progress from investigation to blocker, resolution, and completion. Having these living documents at my disposal makes it easier for my peers to help me and for me to help myself when I inevitably run into the same problems and blockers further down the road.

Because human memory is such an unreliable thing these notes don’t have to be detailed to be useful later, and mine often include more screenshots than written words. The point is that they help me remember where I left off, where I was going, and what I’ve already tried. As an added bonus this practice has improved the quality of the documentation I write when it matters.

3. Don’t forget the company tooling.

If you’re working for a company of a mid-to-large size they probably have an entire suite of programs and services that they use to obtain metrics and track various data points like employee engagement and happiness. Make sure that you use these tools, even if you hate them, because the company spends (a probably not insignificant amount of) money on them.

I found it useful to bookmark and store these in one folder that I trudged through on Friday mornings.

4. Ask the ‘stupid’ questions.

"Chances are it isn’t a stupid question, and someone else is probably wondering the same thing."

These wise words came from my favorite no nonsense project manager.

5. If you make a mistake, be proactive.

Mistakes happen. Reach out to your community and let them know what happened. Ask questions and learn from it, double points when you can learn from the mistakes of others.

6. Effect the change you want to see.

A few months ago a new engineer joined the frontend team I was working on and she asked that we use the Zoom “raise hand” feature when we wanted to speak during meetings. A couple days of adjusting, and just like that we spent less time interrupting each other, and more time joking about the man who raised his hand for 45 years. Sometimes it really is that easy to effect real change for the people around you. If you have an idea, or know of something that could improve the day-to-day for your team, say something!

7. Find what motivates you to code and seek that out.

This is a piece of advice I got from my first manager, and I’ve kept it close. Your best work is going to be the work you care about doing, so figure out what that is.

For me it was accessibility. I sought that out by creating tickets for the problems I saw, looking out for tasks that touched it, and started a team channel to talk about it. Through this I eventually found myself invited to product design meetings, talking to more people outside of my core team, and learning more than I ever would have on my own. But most importantly - I enjoyed doing it.

8. Never stop learning.

The golden rule of a healthy career in programming. Stay interested and stay coding 👩‍💻

Accessibility: Title Achievement

Ash — Tue, 25 Jan 2022 06:28:13 +0000

Titles. Every book, royal figurehead, military official, podcast, and website has one - but how often do we really think about them?

If you rely on a screen reader the answer is often. If you're a web developer the answer is probably more than most, but perhaps not as much as you should.

Titles have the power to greatly impact SEO performance, in-application organization, and allow screen-reader users to quickly understand page content. In more ways than one they directly impact, influence, and inform our end users.

The Title Element

Like the <header> and <footer> elements, the <title> element is a semantic HTML element designed to support the global structure of the HTML document.

To be clear, the title is not the main heading - the main heading being the first, and ideally only top-level, <h1> element on the page. By convention this element is usually styled in large fonts and contains the same, or similar, text to the title.

Furthermore, the <title> element is not to be confused with the title attribute, which offers advisory information about the element for which it is set.

Syntax and Use

In most cases, a document without a title is considered invalid. A valid title must follow a few rules:

The only permitted parent of the <title> element is the <head> element
Both opening and closing tags (e.g. <title></title>) must be present
The document should have only one(1) set of <title> tags
The <title> tags must not be empty
The content between tags must be text-only. Nested elements will be ignored.

Accepted Attributes

The <title> element accepts only the global attributes, a set of standard attributes (like id, lang, and hidden) available to all elements in HTML5. There are no special attributes specific to the <title> element, like the checked attribute for <input type="checkbox" /> elements.

Implicit ARIA Roles

The <title> element has no corresponding implicit ARIA roles. This is another way to say that the meaning of the <title> element cannot be accurately represented, to assistive technology or otherwise, through the roles, states, and properties provided in the ARIA specification.

We cannot provide a title the same way that we can, if for some reason it's absolutely necessary, create a valid and compliant link with the role, data-href, and tabindex ARIA attributes:

<span role="link" tabindex="0" data-href="<https://example.com>">Example Text!</span>

The <title> element is not just a way to get content to show up on the screen. The tag denotes meaning to a machine and implies something about the content. Not using it, or using it incorrectly, is at best a disservice and at worst creates an exclusive experience for end-users.

Title Consumption

Sighted users consume the document title most frequently through the text that appears on open tabs in a browser window. The value this adds is quite literally visible, especially when best practices are followed.

For users without access to this visual structure, the <title> element takes on an added layer of importance, likewise the implications of poor title practices are more severe.

When a screen-reader user arrives at a page the title is the very first thing they will hear. If the title is too long the user could find it cumbersome. If the title is too short, or missing, the user will have to spend extra time navigating through page content to understand its purpose. Or they could leave the page completely in search of a more inclusive and less time-consuming experience.

Basic Best Practices

Armed with the knowledge of what a title is, how it should be used, and why it's important, we can take a more in-depth look at best practices and a couple of use cases.

In its most basic form a page title should be:

Accurate and informative
Concise
Unique within the website
Similar in content to the top level heading in the main content

Use Case: The Confetti Club

<head>
    <title>Environmentally-Friendly Confetti Alternatives</title>
</head>
<body>
    <h1>Environmentally-Friendly Confetti Alternatives</h1>
        <h2 id='botanical'>Petals & Botanicals</h2>
        <ul aria-labelledby='botanical'>
            <li>Fresh flower petals</li>
            <li>Dried flower petals</li>
            <li>Coconut flakes</li>
            <li>Sprouting seeds</li>
        </ul>
        <h2 id='alternative'>Alternative Options</h2>
        <ul aria-labelledyby='alternative'>
            <li>Biodegrabale glitter</li>
            <li>Blown cornstarch</li>
            <li>Bubbles</li>
            <li>Recycled paper flower petals</li>
        </ul>
        <h2 id='recycled'>Recycled Materials</h2>
        <ul aria-labelledby='recycled'>
            <li>Paper flower petals</li>
            <li>Tissue paper</li>
        </ul>
</body>

The title, "Environmentally-Friendly Confetti Alternatives", accurately conveys the purpose of the page quite well. At only 4 words in length it is concise, easily readable, and a quick listen with assistive technology.

In some cases you may see a title with several keywords jammed into the text. For our example that could look something like this:

<head>
    <title>Environmentally-Friendly Confetti Alternatives, Botanical, Alternative, Recycled, Eco-friendly celebrations </title>
</head>

This is usually done with the intention of improving the site’s SEO performance, but it is a bad practice. The resulting title is quite long and screen reader users could find it tedious to listen to and confusing to understand. While titles have no technical length, they should be as short as possible without losing accuracy or informativeness.

Finally, it’s an added bonus that the text content of the title matches the text of the first heading on the page. While these two(2) elements are different, they both essentially exist to give the page a title.

Dynamic Best Practices

In an increasingly dynamic digital world, more is done in web apps with less true page reloads. This is a positive for many reasons, but it creates a unique challenge for screen-reader users; how do we keep these users informed with what’s happening on the page and create equivalent digital experiences? The <title> element is a good place to start.

An accessible dynamic title will follow a couple of guidelines:

If a page’s content is the result of a user initiated action or a scripted change of context the <title> will describe the result or change to the user.
The unique title text should come before common title text, or text that is repeated throughout other pages in the app

Use Case: The Confetti Club Search Page

<head>
    <title>Product Search - Confetti Club</title>
</head>
<body>
    <form>
      <label class="search-label" for="search">
      Search
      </label>
      <input id="search" type="text" placeholder="Search our Confetti Products!">
      <input class="button" type="button" value="Search">
</form>
</body>

In the title above the unique information, ‘Product Search’, comes before the ‘Confetti Club’ text that we see throughout the site. This gives different pages titles that allow for easy and accurate identification for both sighted and screen-reader users.

We can take this a step further by imagining the user has typed in and submitted a search for “petals”. The app, which we can assume is written in a framework like Vue or React, won’t need perform a full-page reload when the user submits the form. Instead the page will dynamically update, returning a list of products after a background request has resolved. To let a screen-reader user know of this change we need to also dynamically update the title:

<head>
    <title>"Petals" - Product Search Results</title>
</head>
<body>
    <form>
      <label class="search-label" for="search">
      Search
      </label>
      <input id="search" type="text" placeholder="Search our Confetti Products!">
      <input class="button" type="button" value="Search">
    </form>
    <div id="search-results">
        <ul>
            <li>
                <a href='/product/rose-petal'>Rose petals</a>
            </li>
            <li>
                <a href='/product/tulip-petal'>Tulip petals</a>
            </li>
            <li>
                <a href='/product/daisy-petal'>Daisy petals</a>
            </li>
        </ul>
    </div>
</body>

The updated title accurately describes the result of the user action - that is, searching “petals” on the Product Search page. Additionally the unique information comes first. If someone were to share a direct link to this page, or bookmark it for future reference, the purpose and contents are easily discernible for all users.

The <title> element and its contents are critical to all users, but especially to screen-reader users without the option of quickly glancing at the content of the page to visualize and understand what it’s about. Adhering to best practices and providing page titles throughout the application that are succinct, informative, and consistent with content ensures these users will spend less time trying to figure out what’s happening on the page and more time using the service it provides.

Resources

🖇️ W3C/WAI: HTML Page Title is Descriptive

🖇️W3C/WCAG: Technique H25: Providing a title using the title element

🖇️ Descriptive HTML page titles help users quickly understand a web page’s content, Indiana University

🖇️ IAAP WAS (Web Accessibility Specialist) Exam Preparation Course, Deque University

As always, thank you for reading, and I hope you were able to learn something new today! 🕶️ Any feedback, corrections, or general discourse are always welcome 🦄

5 Things I've Learned in 6 Weeks on the Job

Ash — Sun, 19 Sep 2021 19:46:01 +0000

It's been 6 weeks since my first day as a real-deal, steadily employed frontend engineer. In those 6 weeks, I've made mistakes, felt stupid, learned a lot about living, production-level code, and myself. I've also seen that becoming a developer, no matter the path you take to get there, can only teach you so much about actually entering the industry and stepping into large projects built by multiple teams of knowledgeable individuals over several years.

If I could go back and give me from 6 weeks ago any advice, as a new engineer embarking on her first journey with an official title, I'd have a few things to tell her, aside from the reminder to pick up extra coffee.

1. Try not to call attention to, or apologize for, your lack of experience.

On my second day, after completing the nails-on-a-chalkboard process of setting up a laptop, the associated SSO/SAML accounts, and configuring my IDE and VPN, I happily cloned down the first repo I was to work in. Opening it I was immediately intimidated by the number of directories and files, and a tech stack comprised of many packages and libraries that were new to me.

For a time I let that intimidation get the best of me, apologizing about a half dozen times to one teammate or another for my lack of prior knowledge, and I hesitated to pick up tickets and jump into working. Then I remembered I'm human - I can't possibly know everything there is to know about every library that hits npm, and navigating living code you had no hand in writing is difficult.

It's like reading a multi-volume series, with all the fan-fic, the canon side-stories, the limited release collaborations - and then trying to figure out how you can not only add to that but make it better. There's a lot, and there's definitely a learning curve. Give yourself understanding, and if you need to reach out for guidance, try to remove the extra noise from your messages. Leave out the explanations and just ask your question as directly as possible, chances are your coworkers already know you're a junior without you reminding them.

2. Your coworkers are a resource - but a limited one.

This point stands no matter what level of developer you are - coworkers are there to give pointers, discuss sticking points, troubleshoot, and share the load, but there are only so many hours, and so much energy, in a day. Thankfully, Google doesn't rely on a squishy, gray, biological CPU - we can ask it questions, and endless variations of those questions, until the cows come home.

In boot camp, I learned that it's almost always better to do your homework and brute force a solution that needs refinement than to implement nothing at all and ask someone else how to do it. Go forth and Google. Try things out, break stuff, figure out why it broke, and fix it - pull the problem apart.

If you're still at an impasse, get in the habit of giving others context - a screenshot is only a prt sc and ctrl + v press away - and draft your questions. You'll be surprised how often this practice will lead you to an answer without ever pressing send. While you shouldn't be afraid to ask your coworkers questions and to learn from them, you should be respectful of their time and mindful of their mental energy.

3. Document, document, document

Developers know the value of good documentation, which is why it's ironic that so many of us struggle with it on a personal level. Being in the habit of documenting your process and your day, especially as a junior developer, will do loads for recall and concentration, and make it look like you have your stuff together.

There are numerous ways to go about documenting the day, but keep in mind that the best documentation is shareable and ctrl + f-able - unlike the barrage of sticky notes collecting on your desk, or abbreviated, barely legible scribbles in the margins of a notebook. Using a planning app like Trello you can create cards and easily drop in screenshots, attach notes and checklists, and if needed, share all of it with a peer.

This approach helps me keep track of what was discussed and decided in meetings throughout the week, and creates a running log of the tasks I've completed. Once done with a card, it can be archived, creating a very handy backlog in the case that another developer has questions on code you implemented, removed, or changed.

4. Don't take anything personally.

Rarely in life is anything really about us as individuals, and this is doubly true come code review time. Your code will be scrutinized, and you shouldn't be surprised or upset when parts of it don't hold up to the magnifying glass. Chances are your coworkers didn't open your PR with the intent to destroy your self-esteem, so take these moments as a learning experience. Make suggested changes and try to understand why they were suggested in the first place. Keep your ego out of it.

5. Don't stop learning.

I identify as a completionist. There's something about checking things off a list that gives me a sense of accomplishment. But this personality trait is a double-edged sword that comes with a competitive streak, and a predisposition to tunnel vision. I wasn't on the job long before I caught myself logging several more hours than the expected 8 am to 5 pm in an attempt to get more done, but the effort wasn't yielding the expected result.

For starters, I couldn't reach out for hints and pointers because my coworkers were logged off, attending to their mental well-being and personal lives. Furthermore, I was neglecting my own and wasting time spinning my tires trying to understand a tech stack from inside a legacy project, instead of building my own.

Our coworkers simply don't have the time to teach us everything we have to know about the projects we're stepping into - no matter how intimately they might know themselves. If you're struggling to reason about your company's tech stack, try to find a Udemy or YouTube course that utilizes a similar one. When the working day is over, and your coworkers have called it a night, consider spending that hour or two of extra work there.

Don't forget that part of being a developer is a commitment to being a lifelong student, and understand that nothing you learn is useless or single scope. So keep reading articles, stay up to date on what's making waves, support and utilize the community of remote educators this industry has built, and keep hacking on your passion projects.

Breaking into a new industry is hard work. Once you succeed in landing a job it's easy to get swept up in the tide of new information, self-doubt, and confusion that comes with it. Keep in mind that all the things you did while job hunting, like building hobby projects, learning new frameworks and fundamentals, and updating your resume, all still apply - they've just shifted from the main burner.

While you're at it, don't forget to enjoy the here-and-now. When you first started on this journey, perhaps struggling to write a for-loop or understand recursion, you probably imagined how great it would be once you got to where you are right now, getting paid to code. So while you stress about the holes in your knowledge and how long it will take to get to the next benchmark, know that it's all a part of the process - and all you have to do is keep going.

Exploring the Browser Environment through Routing

Ash — Wed, 04 Aug 2021 17:59:16 +0000

For better or worse, the npm library has changed the day-to-day life of devs the world over. While NPM can be host to poorly maintained, un-documented, and even malicious packages - there are just as many helpful, well-intentioned libraries and frameworks designed to get the job done better and faster.

Some libraries are so well supported, and so good at doing their job, they become a standard. React Router, with over 4 million weekly downloads at the time of this writing, is a great example of just such a library.

Unfortunately, even well-supported libraries experience deprecations and breaking changes. The only difference is that when a library like React Router breaks, many pages across the world-wide-web break with it.

By peering under the hood to see how React Router works, we can mend future breaks faster and gain a deeper understanding of how it interacts with the browser environment - a rich resource available to us at all times.

Prerequisites: The Browser Environment, the DOM, and the BOM

React is written in JavaScript, a language initially constructed to exist inside the browser environment, and in many ways the browser was built around JS, as well.

Though terms like environment can sometimes sound elusive, we only need to understand that an environment is nothing more than a collection of bindings and their values. These values are often objects or functions that store information and help us do a job. Their bindings are their names - the ways in which we must call them so that we can use the value they contain.

To get a better understanding of the structure of the browser environment, let's take a very broad look from the top level.

The top-level, or root, object of the browser environment is known as the window object. This massive object houses all the properties and methods of the browser environment. With the data, logic, and behavior that lives here, JS is able to execute on the screen. Beyond that, the JS can borrow from this object to accomplish tasks.

This is exemplified by the first child seen in the diagram above, called the document object or DOM. The DOM provides us with a virtual, tree-like representation of the elements on the page, along with ways to isolate and manipulate them. You might be familiar with some of these functions, like document.body.getElementByID() or document.body.getElementByClassName().

The DOM is a subject covered early, and often so exhaustively when first learning to work with JS that it is often taken for granted. The document property of the window object did not always exist as it does now, in a standardized form. In the early days of the Web, every browser followed a different set of ideas and implementations, and cross-browser support simply wasn't a thing.

In those days the DOM was more similar to our next subject - the browser object model, or BOM. To make things more confusing, the BOM is also commonly known as Web APIs, or the hybridized BOM APIs.

Whatever you call it, the BOM serves as the core of JS in the browser. It's host to a collection of objects and interfaces that are always there, waiting to be used. We could get information about the user's display with screen, their browser OS with navigator, and, what we'll be most concerned with today, their destination with the location object.

As evidenced by its many names, the BOM is not well defined or standardized - meaning every browser provides a different set of BOM objects. Which explains why we won't find this functionality on a handy parent object, like document, but rather stuck directly onto the root window object.

Thankfully, though while not officially standardized, most browsers today are more alike than different. We work around differences in varying BOM implementations with supplemental pieces of code, like WebKit, language wrappers like jQuery, and utilizing cross-browser supports built into each.

Project Introduction

The example repo for this post can be found here

This project explores routing by keeping things simple. There are 4 main, pre-built components - App, About, Home, and Contact. App will serve as the parent component, initially rendering all 3 children simultaneously.

We're going to handle building our own routing from the ground up, discussing Reactive patterns and exploring the browser environment along the way. We'll build 2 more components, Link and Route, to do that. We'll also construct a Nav component and briefly discuss navigation.

Brute Force Routing

If you're following along on the repo, the starter code for this section can be found on branch section-one/setup. The final code can be found on branchsection-two/brute-force-routing.

The basic premise of routing is simple: When the user is at a certain location, show a certain component or page. To do that we need to know the user's url at any given moment. Lucky for us, that information is always available to us in the browser environment on the window.location object.

To take a look at the location object in the App component, we'll log it at the top of the App component:

src/App.js

import About from './components/About';
import Contact from './components/Contact';
import Home from './components/Home';

function App() {
  // ⭐
  console.log(window.location);

  return (
    <div className="App">
      <h1 className="headline">Routing in React</h1>
      <Home />
      <About />
      <Contact />
    </div>
  );
}

export default App;

The console should return an object with a lot of properties and a few methods.

This is the entire location object. Most of the properties found here hold information directly concerned with the current url, a standardized string that specifies a virtual resource's location and content. The location object includes a separate key-value pair for each of its constituent parts.

To accomplish routing for pages within the same app we're only really concerned with the pathname property. By watching the pathname we can decide when we should or should not render a component.

We'll start by removing the component instances from the return, and defining a function named showHome at the top of the App component:

src/App.js

import About from './components/About';
import Contact from './components/Contact';
import Home from './components/Home';

function App() {
    // ⭐
  const showHome = () => {
    if (window.location.pathname === '/') {
      return <Home />;
    }
  };

  return (
    <div className="App">
      <h1 className="headline">Routing in React</h1>
            {showHome()}
    </div>
  );
}

export default App;

The showHome function's job is simple: If the window.location.pathname contains the the string "/" (that is, when it is empty) return the Home component.

To use the function, we've simply called it in the JSX. Opening the project you should see the Home component rendering. If we update the url to something like http://localhost:3000/about, the Home component will be removed.

We'll create and call 2 more functions, showAbout and showContact, for the remaining components:

src/App.js

import About from './components/About';
import Contact from './components/Contact';
import Home from './components/Home';

function App() {
  // routing functions
  const showAbout = () => {
    if (window.location.pathname === '/about') {
      return <About />;
    }
  };

  const showContact = () => {
    if (window.location.pathname === '/contact') {
      return <Contact />;
    }
  };

  const showHome = () => {
    if (window.location.pathname === '/') {
      return <Home />;
    }
  };

  return (
    <div className="App">
      <h1 className="headline">Routing in React</h1>
      {showAbout()}
      {showContact()}
      {showHome()}
    </div>
  );
}

export default App;

A quick save and a visit to the browser, and we can see that when the url is updated, and we spell everything correctly, the About and Contact components render at their corresponding pathname.

Just like that - we've created brute force routing, and all we had to do was look to the surrounding environment and read the information found there. However, there are some holes in this approach.

For starters, the url has to be manually updated when the user wants to see a different component. Furthermore, each of the show functions is very similar. We could easily refactor, combining all of the show functions into one function capable of receiving multiple arguments... but this entire approach is decidedly un-Reactive.

Instead, we'll build a reusable component with the logic to decide when it should and shouldn't show its children. We'll call it the same thing it's known as in React Router: The Route component.

The Route Component

If you're following along on the repo, the code for this section can be found on branch section-three/Route-component.

To begin building the Route component, create another directory inside the src folder named routing. Inside of routing create a file named Route.js with the following code:

src/routing/Route.js

const Route = ({ children, path }) => {
  return window.location.pathname === path ? children : null;
};

export default Route;

The Route component is a simple function component. So simple that because it's not returning any JSX, there's no need to explicitly have React in scope. Meaning we don't need to import React from 'react'.

The component requires 2 props - children and path. The path is checked against the window.location.pathname value, while children represents a React-specific compositional principle.

When creating components we intend to use as "generic boxes", like the Route component, they likely will not know their children ahead of time. Will it be a component? A dataset? A link? An image?

Passing the children prop and consuming it in the return allows us to work around that unknown. Using it ensures the component can effortlessly consume any child we provide - be that another component, a string, or any other piece of data. To see how the children prop is used, import and use the Route component in App.js.

After importing, remove the show functions and their instances from the JSX, and add an opening and closing <Route> tag in their place. The Route component requires a path attribute and value, which we'll set to "/". Finally, provide a basic string between tags:

src/App.js

import About from './components/About';
import Contact from './components/Contact';
import Home from './components/Home';

import Route from './routing/Route';

function App() {
  return (
    <div className="App">
      <h1 className="headline">Routing in React</h1>
         <Route path="/">
         "I'm being passed on the `children` prop!"
         </Route>
    </div>
  );
}

export default App;

Back in Route.js add a log statement at the top of the component, save, and run the project.

src/routing/Route.js

const Route = ({ children, path }) => {
  console.log(children);
  return window.location.pathname === path ? children : null;
};

export default Route;

In the browser we should see the passed string both on the webpage, and in the console.

This shows us that using the children prop is pretty simple and straightforward: The content passed between opening and closing JSX tags, like <Route> and </Route>, will be available to the parent component on the special children prop.

The children prop can be used to pass one, or more, components, strings, elements, and more. Which we can see by adding all 3 components between <Route> tags:

src/App.js 

import About from './components/About';
import Contact from './components/Contact';
import Home from './components/Home';

import Route from './routing/Route';

function App() {
  return (
    <div className="App">
      <h1 className="headline">Routing in React</h1>
      <Route path="/">
        <Home />
        <About />
        <Contact />
      </Route>
    </div>
  );
}

export default App;

Save and refresh the project, and the console should return an array of 3 objects, each with the type of react.element.

Because we want each Route to conditionally render one child at a time, we'll finish by giving each component its own path and <Route>:

src/App.js 

import About from './components/About';
import Contact from './components/Contact';
import Home from './components/Home';

import Route from './routing/Route';

function App() {
  return (
    <div className="App">
      <h1 className="headline">Routing in React</h1>
      <Route path="/">
        <Home />
      </Route>
      <Route path="/about">
        <About />
      </Route>
      <Route path="/contact">
        <Contact />
      </Route>
    </div>
  );
}

export default App;

On the webpage we'll have essentially the same functionality we had in the brute force routing approach, but we're no longer repeating ourselves. Additionally, this new approach takes better advantage of key principles and patterns in React.

By updating the url we can see each of the components at their respective path, but we're still missing an important and expected feature - navigation.

The Nav Component

If you're following along on the repo, the code for this section can be found on branch section-four/navigation.

When users arrive at a webpage, especially one with subsequent inner pages and resources, they expect the app to have some type of navigation in place. That could be a dropdown menu, a navigation bar, or any one of the many patterns for organizing a collection of links. At the end of the day, navigation, be it good or bad, can be the "make it or break it" feature of an app.

Because our app is basic, we'll use the nav bar approach to implement and discuss navigation. Inside the components directory make a new file named Nav.js. Nav will return some basic JSX:

src/components/Nav.js

import React from 'react';

const Nav = () => {
  return (
    <div className="nav">
      <a href="/">Home</a>
      <a href="/about">About</a>
      <a href="/contact">Contact</a>
    </div>
  );
};

export default Nav;

This component resembles any basic, run-of-the-mill nav bar you might come across in the wild. It works just like one too - meaning the anchor element, <a>, has pre-defined, default behavior coming from the browser environment.

To explore why this presents problems in React, we'll import and use the Nav component in App.js:

src/App.js 

import About from './components/About';
import Contact from './components/Contact';
import Home from './components/Home';
import Nav from './components/Nav';

import Route from './routing/Route';

function App() {
  return (
    <div className="App">
      <Nav />
      <h1 className="headline">Routing in React</h1>
      <Route path="/">
        <Home />
      </Route>
      <Route path="/about">
        <About />
      </Route>
      <Route path="/contact">
        <Contact />
      </Route>
    </div>
  );
}

export default App;

Though the problems surrounding a full-page reload are less obvious in small projects like ours, in more robust programs this behavior can cause a cascade of costly network requests, unexpected state changes, and other less-than-desirable consequences.

Furthermore, when the user first arrives at the page their machine and browser have already taken care of loading the CSS, the JS, the html and more. There's simply no reason to do this over and over again as they navigate through the app.

To solve for this, we'll need to stop the anchor's default behavior from ever being triggered and provide custom logic in its place. In React we can do that by wrapping the anchor element in a component, where we will have full control. We'll call this component the Link component.

The Link Component

The code for this section can be found on branch section-four/navigation.

In the routing directory, make a new a file named Link.js. To start, declare a function component that returns a pair of <a> tags, with a href value of "/", and text "Link" between:

/src/routing/Link.js

import React from 'react';

const Link = () => {
    return <a href="/">Link</a>;
};

export default Link;

👆 Because the component only returns a single element we can omit the smooth parentheses with a single line return!

In Nav.js import the Link component and provide it in place of the anchor tags:

src/components/Nav.js

import React from 'react';

import Link from '../routing/Link';

const Nav = () => {
  return (
    <div className="nav">
      <Link>Home</Link>
      <Link>About</Link>
      <Link>Contact</Link>
    </div>
  );
};

export default Nav;

After saving, the project should reveal a set of three identical Link elements on the page.

All the links navigate to the same location, that is http://localhost:3000/. Therefore they will all lead to the Home component view.

To make the Link component reusable we can pass props as placeholders for values that can be changed with each instantiation. The Link component requires a few props: a href attribute, the children, and a className.

Back in Link.js we'll start by passing href:

src/routing/Link.js

import React from 'react';

const Link = ({ href }) => {
    return <a href={href}>Link</a>;
};

export default Link;

The href address is no longer hardcoded, so the Link must explicitly receive a passed href value at the time of instantiation. Saving this update will break the app, but we can quickly fix this by providing the href prop to each Link back in Nav.js:

src/components/Nav.js

import React from 'react';

import Link from '../routing/Link';

const Nav = () => {
  return (
    <div className="nav">
      <Link href="/">Home</Link>
      <Link href="/about">About</Link>
      <Link href="/contact">Contact</Link>
    </div>
  );
};

export default Nav;

In the browser we'll see that the app is back up, and the Links are working again - mostly. They all still say "Link", rather than "Home", "About", or "Contact". This doesn't help the user much. They can probably already tell that the Link is, in fact, a link simply because it's a blue, underlined piece of text.

To pass a destination description, we'll use the React children prop as we did in the Route component:

src/routing/Link.js

import React from 'react';

const Link = ({ href, children }) => {
  return <a href={href}>{children}</a>;
};

export default Link;

Using the children prop, any text we pass between Link tags will be passed and consumed by the Link component. No updates are required in Nav.js, saving now will show all of the Links restored with no question as to where they lead.

Finally, we'll pass an optional className prop. This step isn't strictly necessary, but it's a good idea to "future-proof" code with this kind of foresight.

src/routing/Link.js

import React from 'react';

const Link = ({ href, children, className = 'link' }) => {
  return <a href={href} className={className}>{children}</a>;
};

export default Link;

We used ES6 destructuring assignment syntax to provide a default value. That way, if a Link is used without a given className nothing will break. By default it will receive the class name "link", or it can be provided by us in the instance that we need a special link in the future.

Now, you may be thinking "Great, we're back to where we started." To some degree you're correct, but we've installed ourselves in a much greater seat of power. On the component-level we can now begin wrapping the Link in custom logic and behavior.

Preventing Default Behavior

The code for this section can be found on branch section-four/navigation.

We discussed why the browser's default behavior for anchor elements presents a problem in React. By wrapping the anchor element in a React component we started providing it dynamic data. Now we can begin re-wiring its behavior, cherry-picking functionality from the browser environment that fits our needs.

To handle user interactions anchor elements wait for an event (e.g. clicking) to occur. Once this happens, an event object containing all sorts of information about what the event was, where it occurred, and what's to happen next is emitted. In React we have access to all of this within the anchor's onClick property, where we can attach a handler function.

At the top of Link.js, we'll declare our own click handler, called onClick to keep things simple, and connect it in the JSX:

src/routing/Link.js

import React from 'react';

const Link = ({ href, children, className = 'link' }) => {
    // ⭐
    const onClick = (e) => {
        // ...
    };

  return (
        <a 
            onClick={onClick} 
            href={href} 
            className={className}
        >
                {children}
        </a>;
    );
};

export default Link;

The onClick function takes in the event object, e. To stop default behavior the first thing we'll do is use the browser-provided preventDefault() method on the event:

src/routing/Link.js

import React from 'react';

const Link = ({ href, children, className = 'link' }) => {

    const onClick = (e) => {
        // ⭐
        e.preventDefault();
    };

  return (
        <a 
            onClick={onClick} 
            href={href} 
            className={className}
        >
                {children}
        </a>;
    );
};

export default Link;

In the browser if we click a Link we'll see there is no full-page reload, the url is not updated, and well... nothing happens. One line of code has effectively "shut off" the anchor element's behavior, and presented the opportunity to step in a redefine it ourselves.

Implementing Custom Behavior

If you're following along on the repo, the code for this and the next section can be found on branch section-five/custom-PopStateEvent.

We know that our Route component relies on the url pathname property. So our first concern is finding a way to update this piece of information. Luckily, we don't have to look too far or hard to find it.

Nestled not-so-deeply in the BOM, alongside the location object, is the history object. As its name suggests, the history object contains information regarding session history. This includes an array of visited urls, known as the history stack, a forward(), back(), and go() function, and several other methods, including pushState().

The pushState() method can be used to add to the history stack, but not trigger a full-page reload. The method comes with a couple of caveats - first, pushState() can only be used to add a new url to the history stack if that url shares the same origin as the current url.

The pages we are routing between belong to the same document, and originate from the same host, or origin. They're simply small pieces of a larger whole, making pushState a perfect option for our use case.

In Link.js, we'll update the onClick handler right below the call to preventDefault():

src/routing/Link.js

import React from 'react';

const Link = ({ href, children, className = 'link' }) => {

    const onClick = (e) => {
        e.preventDefault();
            // ⭐
        window.history.pushState({}, '', href);
    };

  return (
        <a 
            onClick={onClick} 
            href={href} 
            className={className}
        >
                {children}
        </a>;
    );
};

export default Link;

There are three values passed to the pushState() method - a state object, a title, and the url destination, which we have access to through the href prop.

In the project you'll now notice that while clicking a Link does not update the render, it does update the url, and that means we're halfway there.

Using the environment, we found a way to update the url, but avoid costly reloads and network requests - but we've run up against the other caveat of using pushState(). This one surrounds a special type of event that occurs in the browser known as a popstate event.

Creating a Custom PopStateEvent

By definition a popstate event is a special type of event dispatched on the window whenever the active history entry changes, but only when that change is a consequence of a browser action. Browser actions include clicking the back and forward buttons, and changing the url manually. Our call to pushState() is not a browser action, so a popstate event is not emitted.

Because the popstate event, which inherits from the parent Event object, is built perfectly for our needs we still want to use it, and we can.

Below the call to pushState(), we can explicitly create our own popstate event using the new keyword and the PopStateEvent constructor:

src/routing/Link.js

import React from 'react';

const Link = ({ href, children, className = 'link' }) => {

    const onClick = (e) => {
        e.preventDefault();
        window.history.pushState({}, '', href);
        // ⭐
        const navEvent = new PopStateEvent('popstate');
    };

  return (
        <a 
            onClick={onClick} 
            href={href} 
            className={className}
        >
                {children}
        </a>;
    );
};

export default Link;

We've constructed a synthetic event, named navEvent with a type of popstate. Once created, the navEvent must be manually "turned on", or emitted. This is done using the browser-provided dispatchEvent() method:

src/routing/Link.js

import React from 'react';

const Link = ({ href, children, className = 'link' }) => {

    const onClick = (e) => {
        e.preventDefault();
        window.history.pushState({}, '', href);
        const navEvent = new PopStateEvent('popstate');
        // ⭐
        window.dispatchEvent(navEvent);
    };

  return (
        <a 
            onClick={onClick} 
            href={href} 
            className={className}
        >
                {children}
        </a>;
    );
};

export default Link;

Unfortunately, in the browser we won't find our app magically working. The links still update the url, but fail to change the render. Because we dispatched the navEvent to the window object, all of its children should be aware of it. So what gives?

In this instance components are a lot like us as humans. Simply being aware of an occurrence doesn't guarantee that we know what to do about it, or in response to it. We could freeze and do nothing, act uncharacteristically, or need to be told how to respond.

So, while the Link component successfully sends of an event object when clicked, the problem lies with the Route component. While aware of the event, it needs help to understand what to do next.

Updating the Route Component

In the first iteration of the Nav component all of the links were working - that is to say clicking one brought us to a new page. But this was because the anchor elements triggered a full-page reload, re-initializing everything in the app all over again at the correct destination. We've disabled this costly process, but lost some expected functionality along the way. To reinstate some of that behavior we created our own navigation event by borrowing the popstate event type from the browser environment.

The last step requires clueing in the Route component, coaching it to handle the popstate event using an event listener. The browser provides 2 self-explanatory methods you're probably familiar with, addEventListener() and removeEventListener(), to accomplish this.

Performing tasks with event listeners in the confines of React is typically a good indication that we'll require the useEffect hook. This special hook gives us the power to reach into the lifecycle of a component - opening windows wherein we can turn listeners on and off.

To start, import the useEffect hook directly from React. At the top of the component set up the useEffect function with an empty callback and dependency array:

src/routing/Route.js

import { useEffect } from 'react';

const Route = ({ children, path }) => {
    // ⭐
    useEffect(() => {},[]);

  return window.location.pathname === path ? children : null;
};

export default Route;

React hooks come with their own pre-defined behavior and purpose, and the choice to employ useEffect here is no accident. The code placed in the hook's first argument, the callback function, will run after first render - the perfect moment in time to turn on the event listener.

Inside the callback function we'll declare an arrow function, called onPathChange(), which will serve as the event handler. Then we'll bind an event listener to the window object:

src/routing/Route.js

import { useEffect } from 'react';

const Route = ({ children, path }) => {
    // ⭐
    useEffect(() => {
        // 1️⃣ handler function
        const onPathChange = () => {
            console.log("URL path changed!");
        };
        // 2️⃣ event listener
        window.addEventListener('popstate', onPathChange);
    },[]);

  return window.location.pathname === path ? children : null;
};

export default Route;

The onPathChange function is passed as the second argument to addEventListener(), the first argument is a string indicating the event type.

Back in the browser, with the console open, clicking a link should return 3 log statements of "URL path changed!" We get 3 statements because there are 3 instances of the Route component currently rendering and now listening for a popstate event.

Now that Route has started listening for a popstate event, it's aware when the url pathname changes, but it is not privy to what the pathname change to. To isolate this information we'll use another React hook, called useState.

The useState hook returns a slice of state, which we'll call currentPath, and its setter function, named setCurrentPath by convention. Finally useState requires one argument, the initial state value - which we'll set to the browser-maintained window.location.pathname property. To finish, we'll consume currentPath in the return:

src/routing/Route.js

import { useEffect, useState } from 'react';

const Route = ({ children, path }) => {
    // ⭐
    const [currentPath, setCurrentPath] = useState(window.location.pathname);

    useEffect(() => {
        const onPathChange = () => {
            console.log("URL path changed!");
        };
        window.addEventListener('popstate', onPathChange);
    },[]);
  // ⭐
  return currentPath === path ? children : null;
};

export default Route;

While window.location.pathname is kept constantly up-to-date by the browser, it's important to note that our currentPath piece of state is a separate variable. Upon render it is given the value of whatever window.location.pathname is at that moment, but to change the currentPath any time after render we must use its setter function, setCurrentPath. Only then can the Route component know when and what the url pathname has changed to.

To update currentPath in response to a popstate event, call the setCurrentPath function in the event handler - setting it to now updated window.location.pathname:

src/routing/Route.js

import { useEffect, useState } from 'react';

const Route = ({ children, path }) => {

    const [currentPath, setCurrentPath] = useState(window.location.pathname);

    useEffect(() => {
        const onPathChange = () => {
      // ⭐
            setCurrentPath(window.location.pathname);
        };
        window.addEventListener('popstate', onPathChange);
    },[]);

  return currentPath === path ? children : null;
};

export default Route;

In short, the popstate event lets the Route component know that a change has been made to window.location.pathname, its event listener then goes about retrieving those changes. After that, it can figure out which of its children, i.e. Home, About, or Contact, should be rendered.

In the browser the links should be working again. The Route and Link components are working together with the browser environment to track a user's location in the app and update as needed. Crucially, they do all of this without triggering a full-page reload... But we're not quite done yet.

In the case that any of the Route or Link components is removed from render at any time in the future, we must turn the event listener off. Failing to do so will result in a breaking error.

Thankfully the useEffect hook has a special feature known as a cleanup function. The cleanup function can be optionally returned from the hook, and will execute before the component is removed from the render.

To use this feature in Route.js, we'll update the useEffect hook found there to return an anonymous function:

src/routing/Route.js

import { useEffect, useState } from 'react';

const Route = ({ children, path }) => {

    const [currentPath, setCurrentPath] = useState(window.location.pathname);

    useEffect(() => {
        const onPathChange = () => {
            setCurrentPath(window.location.pathname);
        };
        window.addEventListener('popstate', onPathChange);
      // ⭐
      // 🧼 anonymous cleanup function
        return () => {
            window.removeEventListener('popstate', onPathChange);
        };
    },[]);

  return currentPath === path ? children : null;
};

export default Route;

The cleanup function turns off the listener with the removeEventListener() method, completing the circle. Basic routing, from beginning to end, is now in place.

Though it seems nebulous, the browser environment wraps everything we do in React, Vue, Angular, and JS at large. In fact, beneath the interfaces of many npm libaries, we'll find the foundations for the framework often belong to the browser, proving that understanding it is essential to truly understanding and working with JavaScript.

I hope this post has helped dispel some of the magic around not just React Router, but the browser environment, and the workings of npm libraries at large.

Resources:

Link Behavior - NC State University
Browser Environment - javascript.info
JavaScript BOM - javascripttutorial.net
Browser and Web APIs - Antoine Leclercq, Medium.com
Using the HTML5 History API - Robin Rendle, CSS-tricks.com
Moden React with Redux - Stephen Grider, Udemy 🏛

🦄 As always - thank you for reading! 🕶

A Quick Guide to Understanding React Hooks

Ash — Tue, 08 Jun 2021 21:21:00 +0000

This post will focus on React hooks - specifically useState, useEffect, and useRef. The examples are contrived for the sake of clarity, and don't observe all the typical best practices (like wrapping those emojis in span elements 😉).

React Hooks 🎣

React hooks allow us to use function components to accomplish things that were once only possible in Class components - creating, persisting, and sharing stateful and behavioral logic. Additionally, hooks let us take advantage of certain moments in the component lifecycle.

☝ Strictly speaking, some hooks offer a way to mimic lifecycle methods, and are not a 1:1 exchange.

🤔 What is a hook?

Beneath the terminology, and even React itself, a hook is a JavaScript function that follows a pre-defined schema in the form of syntax and expected arguments.

There are several hooks, each with their own intended purpose and pitfalls - but all hooks follow a couple of rules:

Hooks can only be called from function components or custom hooks (a wide topic for another post!)
For React to correctly manage state created with hooks, the order in which they are called must be identical with each re-render. Because of this all hooks must be called in the top level of the component.

☝ A function component is just that - a function! The top level is the first step, where we might declare a variable or do set up - before conditional tests, looping, or performing actions that could cause mutations, and prior to the return in the bottom level.

In this post we'll be covering the 3 hooks you're most likely to encounter in the wild: useState, useEffect, and useRef.

1️⃣ The useState Hook

In JavaScript, Class objects are built in such a way that the sharing of behaviors and values among many instances of themselves is accomplished quite easily, in part because of this - a confusing and deep topic of its own.

On the other hand, functions are scoped. Dumping and re-creating their local variables with each invocation. There is no prev or this, and persisting values isn't possible without an outside variable.

Function and Class components follow this same idea, which is why function components were commonly known as stateless components before the introduction of hooks. Without this, or that outside storage, these components were confined to displaying data they had no way to update... Enter the aptly named useState hook.

Predictably, useState taps into the React's state system - creating a place for function components to add independent slices of state, along with providing a way to update and share them.

Syntax & Use

To use any hook, we import it by name directly from React:

// import 
import React, { useState } from 'react'; 

const App = () => {

    return (
        <div>
            <p>Give 🐒 some 🍌!</p>
            <button> + 🍌</button>
        </div>
    );
}; 

export default App;

To create a new state variable we'll call the useState function and pass the desired initial value, useState's only argument.

In Class components state is maintained as an object, and new state values are restricted to that format. The state variables created by useState are completely independent of one another, meaning our intial value could be an object - or a number, a string, an array, and so on.

We'll create a count with a number:

import React, { useState } from 'react'; 

const App = () => {
    // invoke 
    useState(0);    

    return (
        <div>
            <p>Give 🐒 some 🍌!</p>
            <button> + 🍌</button>
        </div>
    );
}; 

export default App;

The useState function returns two things to us - the current state variable with assigned initial value, and a function to update that value. To get them we'll use array destructuring.

☝ We can name these values anything we want, but it's convention to use the varName/setVarName style:

import React, { useState } from 'react'; 

const App = () => {
    // destructure return
const [bananaCount, setBananaCount] = useState(0);  

    return (
        <div>
            <p>Give 🐒 some 🍌!</p>
            <button> + 🍌</button>
        </div>
    );
}; 

export default App;

And just like that - we've created a piece of state that will be persisted between renders. If another slice of state was needed, we could easily create one. There's no hard limit on the amount of times useState can be invoked in a function component. This feature makes it easy to separate concerns and reduce naming conflicts.

Inside the component we can call and use them directly, no "this.state" required:

import React, { useState } from 'react'; 

const App = () => {
    const [bananaCount, setBananaCount] =   useState(0);
    const [appleCount, setAppleCount] = useState(0);

    return (
        <div>
            <p>Give 🐒 some 🍌!</p>
            <p>🍌 : {bananaCount} </p>
            <p>🍎 : {appleCount} </p>
            <button 
                onClick={() => setBananaCount(bananaCount + 1)}> + 🍌</button>
            <button 
                onClick={() => setAppleCount(appleCount + 1)}> + 🍎</button>
        </div>
    );
}; 

export default App;

Beyond providing a way to create a new state variable, the useState hook also taps into the lifecycle of a component by triggering a re-render when the setter function is invoked and data is changed.

2️⃣ The useEffect Hook

There are a handful of key moments in a component's life that we care about, usually because we'd like to perform some action once they've occurred. These actions might include a network request, turning event listeners on or off, and so on.

In Class components we do that with the lifecycle methods componentWillMount, componentDidMount, and componentWillUnmount. In function components we can now encapsulate all of this behavior in the useEffect hook and accomplish something like lifecycle methods.

☝ I remember this hook as "use side effects," because it allows us to use certain moments and cause side effects when they occur.

Syntax & Use

To use, import from React:

// import 
import React, { useEffect, useState } from 'react'; 
// hardcoded data
const data = ["Doug", "Marshall", "Peter"];

const App = () => {
    const [coolDudes, setCoolDudes] = useState(data); 

    return (
        <div>Top 🆒 dudes: 
            {coolDudes.map((dude) => (
        <p>😎{dude}</p>
      ))}
        </div>
    );
};

export default App;

Right now this component is rendering a list of coolDudes, but these are hardcoded values - what if the coolDudes ranking was maintained in real-time on a database? Using that, our component could always have the most recent data, and we wouldn't have to update it ourselves.

Before hooks we would need to convert this component to a Class or move the required logic higher up in the chain. With the useEffect hook we can accomplish this task inside a function component.

To use it, we need to provide two arguments. First a callback function - the "side effect" we want to invoke, and secondly a dependency array - telling that callback function when to run.

import React, { useEffect, useState } from 'react'; 
// axios fetching library added 
import axios from 'axios';

const App = () => {
    const [coolDudes, setCoolDudes] = useState(data); 
    // invoke hook
    useEffect(() => {
        axios.get('http://superCoolApi/coolDudes')
                .then((response) => {
                    setCoolDudes(response.data)
            });
    }, []); 

    return (
        <div>Top 🆒 dudes are: 
            {coolDudes.map((dude) => (
        <p>😎{dude}</p>
      ))}
        </div>
    );
};

export default App;

👆 You'll often see actions like making API calls in a useEffect hook. When reading a component, it can be mentally handy to think of useEffect as an "after render" action. The code inside should not be significant to component structure.

It's important to note that the first argument to useEffect may not be asynchronous. This ties back to the rule that all hooks must be called in identical order with each re-render in React. Though the callback function itself may not be asynchronous, we can perform async activity inside of it.

The example above used a Promise to resolve the API call, but JavaScript async and await can be used as well:

import React, { useEffect, useState } from 'react'; 
import axios from 'axios';

const App = () => {
    const [coolDudes, setCoolDudes] = useState(data); 
    // async fetch 
    useEffect(() => {
        const response = async () => {
            const { coolDudes } = await axios.get('http://superCoolApi/coolDudes')  
        }
        setCoolDudes(coolDudes.data);
            });
    }, []); 

    return (
        <div>Top 🆒 dudes are: 
            {coolDudes.map((dude) => (
        <p>😎{dude}</p>
      ))}
        </div>
    );
};

export default App;

The Dependency Array

In both of the examples above we passed an empty array as the second argument to the useEffect function. This second argument, known as the dependency array, is the key to telling React when the callback function should run.

By using an empty array, an array with one or more values (usually state or props), or omitting the argument completely, we can configure a useEffect hook to run automatically at particular times.

The Cleanup Function

Broadly speaking, there are two types of actions performed in a useEffect function - those that require cleanup, and those that don't. So far we've only made a network request, an action that is invoked, returned, stored and forgotten about. It requires no cleanup.

But let's imagine a Search component with a useEffect hook that utilized the JavaScript setTimeout() method to wait for a user to stop typing before performing an action. This is a clever and somewhat common pattern to throttle API requests.

Let's take a look at a quick and contrived example:

import React, { useEffect, useState } from 'react'; 
import axios from 'axios'; 

const App = () => {
    // init state 
    const [search, setSearch] = useState("first search term");
    // search state shared with debouncedSearch state 👇
    const [debouncedSearch, setDebouncedSearch] = useState(search); 
    const [results, setResults] = useState([]); 

    useEffect(() => {
        const search = async () => {
            const { data } = await axios.get('http://searchApi.org', {
                // options object to attach URL params 
                // API call is completed with the DEBOUNCED SEARCH 
                // These change depending on the API schema 
                params: {
                    action: 'query', 
                    search: debouncedSearch
                },
        });
            setResults(data.query.search); 
        }; 
    if (debouncedSearch) search();
    }, [debouncedSearch]); 

    return (
        <React.Fragment>    
            <form>
                <label htmlFor="search">Search</label>
                <input 
                    type="search" 
                    value={search} 
                    onChange={(e) => setSearch(e.target.value}
                    placeholder="Search..." />
            </form> 
            <div>
                {results.map(result) => (
                    return <div key={result.id}>
                        <p>{result.title}</p>
            </div>
        </React.Fragment>
    );
};

export default App;

Right now this component renders a search bar and a list of search result titles. On first render the useEffect will be invoked, performing an API call with the initial value we passed to the search slice of state and then connected to the debouncedSearch state.

But if a user were to type a new search term nothing would happen. This is because the dependency array is watching the debouncedSearch state, and won't fire again until this state is updated. Meanwhile the input element is bound to the search state via its value prop.

We'll call another instance of the useEffect hook to connect these two separate states and set a timer while we're at it:

import React, { useEffect, useState } from 'react'; 
import axios from 'axios'; 

const App = () => {
    const [search, setSearch] = useState("first search term");
    const [debouncedSearch, setDebouncedSearch] = useState(search); 
    const [results, setResults] = useState([]); 

    useEffect(() => {
        const search = async () => {
            const { data } = await axios.get('http://searchApi.org', {
                params: {
                    action: 'query', 
                    search: debouncedSearch
                }
        });
            setResults(data.query.search); 
        }
    if (debouncedSearch) search(); 
    }, [debouncedSearch]); 

    useEffect(() => {
    // create a timer that must end before calling setDebouncedSearch
        const timerId = setTimeout(() => {
            setDebouncedSearch(search);
        }, 1000);   
    // useEffect can return a cleanup function! 🧼
    return () => {
        // this anonymous function will cleanup the timer in the case that the user keeps typing
        clearTimeout(timerId);
    };
    }, [search]);   

    return (
        <React.Fragment>    
            <form>
                <label htmlFor="search">Search</label>
                <input 
                    type="search" 
                    value={search} 
                    onChange={(e) => setSearch(e.target.value}
                    placeholder="Search..." />
            </form> 
            <div>
                {results.map(result) => (
                    return <div key={result.id}>
                        <p>{result.title}</p>
            </div>
        </React.Fragment>
    );
};

export default App;

The second useEffect hook is connected to the search input by its dependency array, watching for changes to the search state. When updated, the hook will be invoked and its callback function will then instantiate a timer with the JavaScript setTimeout() method.

If we did not cleanup behind this side effect, and the user kept typing, we would run into a problem. Multiple timers would be added to the stack, all waiting 1,000 milliseconds before triggering an API call. This would be a horrible user experience, that's easily avoided by returning the optional cleanup function.

This function will run right before the hook can be executed again, making it a safe place to cancel the last timer before a new one is created with the clearTimeout() method.

☝ The cleanup function doesn't have to be an anonymous arrow function, though that's generally how you'll see it.

3️⃣ The useRef Hook

The useRef hook is used to attach a reference directly to a DOM node, or to stash a piece of data that we expect to change but whose change we do not want to trigger a costly re-render. The useRef function returns a mutable ref object with a single property called current. This property will point to whatever we assign the ref to.

To get an understanding for how the useRef hook can perform interesting and useful tasks, let's jump right in to a use case.

Syntax & Use

Because it was designed to do a pretty specific job, the useRef hook is seen less frequently than the previous two. But it can be used to facilitate the fluid UI interactions users have come to expect in modern apps.

For example, when we open a dropdown menu, or toggle the open status of some UI element we usually expect it to close again when: 🅰 We select one of the contained options, or click the element itself. 🅱 We click anywhere else in the document.

Prior to the days of React, when JQuery was more prevalent, this was done by adding an event listener. In React we still add event listeners - either with the onClick and onChange handlers that come out-of-the-box with React, or by using JavaScript's addEventListener() method in a side effect (i.e. a useEffect hook).

In the following, the example component is rendering a list of articles. When a title is clicked onArticleSelect is invoked and the activeIndex is reassigned, triggering the open status (created in the renderedArticles map statement) to change and the details of the article to expand.

import React, { useState, useEffect } from "react";

// mock data
const data = [
  {
    id: 1,
    title: "...",
    details:
      "..."
  },
  {
    id: 2,
    title: "...",
    details: "..."
  }
];

export default function App() {
  const [articles] = useState(data);
  const [activeIndex, setActiveIndex] = useState(null);

    // change handler passed to the article element 
  const onArticleSelect = (id) => {
    if (id === activeIndex) setActiveIndex(null);
    else setActiveIndex(id);
  };

  // maps return from articles state
  const renderedArticles = articles.map((article) => {
        // isolate open status by performing a check
    const open = article.id === activeIndex;
    return (
      <article
        key={article.id}
        style={{ border: "1px solid gray" }}
        onClick={() => onArticleSelect(article.id)}
        className="article"
      >
        <h2>{article.title}</h2>
        <div> {open ? <p>{article.details}</p> : null} </div>
      </article>
    );
  });

  return (
    <div className="App">
      <div className="header">
        <h1>🔥Hot Off the Presses🔥</h1>
      </div>
      <section className="articles">{renderedArticles}</section>
    </div>
  );
}

The component has some of the functionality we want. The articles expand once clicked, but an article will only close again if: 🅰 It is clicked a second time or 🅱 Another article id is assigned to activeIndex state.

We want to add another layer to this by creating a way for the article to also close if the user clicks on any other element in the document. It's not too practical in this small example, but if this component was imported and rendered with many others this could be a quality-of-life improvement in the UI.

We'll use a useEffect hook to set up an event listener on the body element the first time the component is rendered. The listener will detect a click and reset the activeIndex to null when triggered:

import React, { useState, useEffect } from "react";

const data = [
  {
    id: 1,
    title: "...",
    details:
      "..."
  },
  {
    id: 2,
    title: "...",
    details: "..."
  }
];

export default function App() {
  const [articles] = useState(data);
  const [activeIndex, setActiveIndex] = useState(null);

    // change handler passed to the article element 
  const onArticleSelect = (id) => {
    if (id === activeIndex) setActiveIndex(null);
    else setActiveIndex(id);
  };

  // turns on body event listener
  useEffect(() => {
    const onBodyClick = (e) => {
      // reset the active index
      setActiveIndex(null);
    };
    document.body.addEventListener("click", onBodyClick, { capture: true });
  }, []);

  const renderedArticles = articles.map((article) => {
    const open = article.id === activeIndex;
    return (
      <article
        key={article.id}
        style={{ border: "1px solid gray" }}
        onClick={() => onArticleSelect(article.id)}
        className="article"
      >
        <h2>{article.title}</h2>
        <div> {open ? <p>{article.details}</p> : null} </div>
      </article>
    );
  });

  return (
    <div className="App">
      <div className="header">
        <h1>🔥Hot Off the Presses🔥</h1>
      </div>
      <section className="articles">{renderedArticles}</section>
    </div>
  );
}

At first glance this seems like it will work - but there's a problem. When the title is clicked a second time it no longer toggles the display. This has to do with a programming principle known as event bubbling, and the way in which the React event system sits on top of that.

In short, the click events we assigned to the body and the article element go through a process of reconciliation. During that process events bubble up from the most parent element, and the events bound with addEventListener() will always be called before the event listeners we attach through React's onClick prop.

When the title is clicked a second time the event listener in the useEffect fires first, setting the activeIndex to null, before the onClick handler fires immediately after, setting the activeIndex back to the original index we were trying to dump.

To solve this we need a way to tell React when a user is clicking inside an article element and when they are clicking anywhere else. To do that, we'll employ the useRef function.

After importing the hook from React, we'll instantiate the ref as empty in the top level of the component.

☝ It's best practice to simply invoke the hook in the top level, saving the task of assigning it for the component return, or through a side effect, perhaps a useEffect hook. The rendering phase in a React function component should be 'pure' - meaning it should cause no side effects, and updating a ref is a side effect.

import React, { useState, useEffect, useRef } from "react";

const data = [
  {
    id: 1,
    title: "...",
    details:
      "..."
  },
  {
    id: 2,
    title: "...",
    details: "..."
  }
];

export default function App() {
  const [articles] = useState(data);
  const [activeIndex, setActiveIndex] = useState(null);
  const ref = useRef();

  const onArticleSelect = (id) => {
    if (id === activeIndex) setActiveIndex(null);
    else setActiveIndex(id);
  };

  useEffect(() => {
    const onBodyClick = (e) => {
      // adds a check: did the event occur in the ref node?
      if (ref.current.contains(e.target)) {
                // if yes, return early
        return;
      }
      setActiveIndex(null);
    };
    document.body.addEventListener("click", onBodyClick, { capture: true });

    // removes the event listener, should articles unmount 🧼
    return () => {
      document.body.removeEventListener("click", onBodyClick, {
        capture: true
      });
    };
  }, []);

  const renderedArticles = articles.map((article) => {
    const open = article.id === activeIndex;
    return (
      <article
        key={article.id}
        style={{ border: "1px solid gray" }}
        onClick={() => onArticleSelect(article.id)}
        className="article"
      >
        <h2>{article.title}</h2>
        <div> {open ? <p>{article.details}</p> : null} </div>
      </article>
    );
  });

  return (
    <div className="App">
      <div className="header">
        <h1>🔥Hot Off the Presses🔥</h1>
      </div>
      <section ref={ref} className="articles">
        {renderedArticles}
      </section>
    </div>
  );
}

We attached the ref to the most parent element of the article elements, in this case that's the section with class name "articles".

The useEffect hook was also updated to perform a check - depending on the results of that check the body event listener will either return early, performing no function and allowing the onClick handlers to do their work unhindered, or it will execute and reset the activeIndex once more.

☝ The contains() method is available to all DOM elements - which is exactly what ref.current points to in this instance.

The introduction of hooks created a shift in the React ecosystem, allowing the once stateless function component to take on huge levels of complexity and functionality. While hooks don't offer a 1:1 trade-off from the lifecycle methods found in Class components, they allow us to create highly reusable, testable, and maintainable components and pieces of state.

The hooks covered here are only part of the story, and a complete list can be found in the Official React Docs.

Resources:

Advanced Web Development with React - Mehul Mohan, pdf 📕
Modern React with Redux - Stephen Grider, udemy 🏛
React useRef Hook - Ceci García García, medium.com
Storing Data in State vs. Class Variable - seanmcp.com
A Thoughtful Way to Use React's useRef Hook - Aleem Isiaka, Smashing Magazine

🦄 As always - thank you for reading! 🕶

Introduction to Node

Ash — Mon, 15 Feb 2021 18:27:37 +0000

Over the last several years JavaScript has redefined the landscape of the internet, becoming a ubiquitous and essential language. Much of that proliferation was the result of runtime environments that aimed to take JavaScript (or JS) outside the confines of the browser. Many projects tried to accomplish this goal, but none caught on quite like NodeJS did when it arrived in 2009.

With NodeJS, JavaScript can run both in the browser and the computer processor, allowing developers to build fully-functional single page applications that once were only possible with languages like Java, Ruby, C++, Python, and more.

In this series we'll be taking a look at the NodeJS environment, discussing important paradigms and patterns crucial to understanding it. Later we'll use Express and Knex on top of Node to build a RESTful API with CRUD capabilities.

👉 NodeJS is written in C, C++ and JavaScript, on top of the V8 JavaScript engine that powers JS in browsers like Google Chrome.

Intro to NodeJS

NodeJS, or Node for simplicity, is a runtime environment. This concept is hard to put into words, but I think of a runtime environment as a program like any other. When executed the program enters a "runtime state." In this active state it can execute other programs, all while having access to the computer's processor, RAM, and other resources.

What Node is to JavaScript, our physical world is to us - the place we exist, where we can perform functions, and have access to various resources.

Node is, logically, more intuitive if your background includes JS. By nature JS is an asynchronous language, and Node is built on a callback based system to accommodate that.

The choice to use any one environment, framework or library comes with the responsibility to weigh both the advantages and disadvantages. What makes a program a solid solution on one team, can be the same things that make it an obstacle on another.

Let's look at some of the features of Node that make it a solution, and why those very same features can also be roadblocks.

✅ Pros:

Same Language: Using JS on both the server and the client means we don't have to adapt to paradigm and syntax shifts, reducing complexity and confusion for developers.
Asynchronous: Takes full advantage of JavaScript's processor - supporting asynchronous operations to read/write, connect to database servers, handle user requests, etc.
Single-Threaded: This isn't strictly true - the Node program, and its imported modules, will run on a single thread, while the engine and IO run on another. Either way, it reduces the complexity behind multiple threads in languages like Java.
NPM: Access to the npm registry - a huge library of npm modules, that often make developer-life easier.

📛 Cons:

Same Language: In programming we have various languages because each of them do one thing really well. Like the tools in a toolbox, they're all useful given the right job. Limiting ourselves to JS means using a tool that might not be right for the job.
Asynchronous: If you, or your team, are unfamiliar with handling the wonky async activity of JS, there can be a steep learning curve. Especially those coming from languages that are built on a synchronous approach to operations.
Single-Threaded: This comes back to the concept of the "right tool for the job." We lose the advantages of servers with multiple threads.
NPM: The npm registry is big, perhaps too big. Using it has the potential to open a project up to vulnerabilities or future deprecations from poorly maintained libraries.

We're going to build a simple server to discuss the fundamentals of Node further, but for now it's important to understand that Node is an environment that allows JS to run outside of the browser.

Installing Node

To continue, make sure that Node is installed on your machine and it's up-to-date. To check, open a terminal window and provide the following command:

node -v

If Node is installed this command will return the current version available. If you don't have Node, or its current version, head to the official NodeJS site and download it from there.

❓ Confused about what version to download? You'll find two versions of Node available on the official site, an "LTS" and a "Current" version. LTS stands for "long-term support", meaning it's being actively maintained and upgraded - but experimental features that don't see full support are not included. For our purposes, we're going to want the LTS version of Node.

Creating a Server

In the context of Node, a server is a place in a computer that listens for traffic. That traffic comes in the form of a user visiting a URL.

When a user visits a website, they're making a request for a resource. It's up to the server to take that request, and decide what resource should be sent back. We as developers will be responsible for writing the code that gives a server the ability to make that decision.

In a directory of your choosing create a new folder for this example project, I've named mine node_server_ex. Inside that folder create an index.js file.

Inside index.js we only need to add these few lines and we're ready to get off the ground.

// index.js

// 1️⃣
const http = require('http'); 
const host = `127.0.0.1`; 
const port = 3000; 

// 2️⃣
const server = http.createServer((req, res) => {
    res.statusCode = 200; 
    res.setHeader("Content-TYPE", "text/plain"); 
    res.end("Hello World, from Node!"); 
}); 

// 3️⃣
server.listen(port, host, () => {
    console.log(`server listening on http://${host}:${port}`);
});

Let's step through the code line-by-line and learn how JS and Node work together.

1️⃣ Variables `http`, `host` and `port`

A server helps computers communicate - Node accomplishes communication using a built-in module called the HTTP Module. The http module is expansive, offering a suite of available properties, classes and their bound methods.

👉 If you're new to programming and are unclear about what a module is - a module is an object that contains a whole bunch of pre-built functions and classes we can choose to use. Pre-made functionality for the low-low price of free.

To include the http module we need to use the require syntax.

const http = require('http');

You may be used to importing modules in JS using the import MODULE from PACKAGE syntax - this is the same thing, though more antiquated. Import syntax happens to be an ES6 feature and because Node runs on the V8 JavaScript engine, which supports new features like ES6, the import syntax will work for newer modules but will not for the older, core ones.

Providing the host and port variables allows us to set up constants that tell Node where to run, and where to listen. For the time being host directs Node to run on your local machine, and port is a number indicating the communication endpoint between the server and user.

2️⃣ `createServer` Function

After requiring the http module, we first put it to use by creating an instance of a Server class. We know that a class in programming is an object built for a specific purpose - equipped with data and behavior presets designed to fulfill that purpose.

If we had to build our own server class we would find it a monumental task - there's a lot to consider, and huge room for error. Thankfully for us, the talented and knowledgeable developers at Node did that for us and made it available to use on the http module.

To create an instance of a Node server class, we simply call http, and the .createServer() method, storing it in local variable server:

const server = http.createServer((req, res) => {
        res.statusCode = 200; 
    res.setHeader("Content-TYPE", "tex/plain"); 
    res.end("Hello World, from Node!"); 
});

The .createServer() method takes a callback function that passes two parameters - the request object and the response object, req and res.

As their names imply, these objects contain information about a user request, and the server's response to that request. They can contain hundreds of properties and complex data structures, or they can be nearly empty, sending simple pieces of information.

📝 req and res are just implicit names we picked, they can be called anything, but they always map to the http.IncomingMessage and http.ServerResponse classes respectively. These classes were created as a result of instantiating a Server class with http.createServer().

In this example we're using the response object, and some its Node-provided methods, to send something to the user. The .statusCode() method sets the http status code to the "all clear!" code of 200, indicating a successful connection.

There are five classes of status codes, each intended to relay a different message. Using them correctly should be given special attention.

1XX: Informational - The "We're all fine here now, thank you. How are you?" of status codes.
2XX: Success - The "happy path." These are the status codes indicate that the server and client are communicating as expected.
3XX: Redirection - If a server needs to pass off a request for further action before it can be completed, then a 3XX status code is used.
4XX: Client Error - These errors point to a problem with the client - it could be an incorrect URL, unauthorized request, and so on.
5XX: Server Error - 5XX errors tell us that the client is successfully sending a request, but the server is unable to handle it for some reason.

👉 We won't see much of the 1XX or 3XX codes, but using the correct 2XX, 4XX and 5XX codes will be important later!

In a perfect world the user won't be aware of these status codes, they're quietly hidden away in component of the request and response object known as the headers object. For developers, the headers are like a reference - a place we can know to look for more information about a request or response - like the date and time, authorization and server status, along with other useful operating parameters.

In the .setHeader() method we added an additional operating parameter to the response headers that will be tacked on with the status code we set above it. That parameter defines the "Content-TYPE" of the response to be "text/plain". This lets the browser know what type of data it will be receiving, so it can prepare itself to display that while the rest of the response loads asynchronously.

Maintaining well-informed headers only works to serve yourself and your fellow developers. Headers encourage meaningful communication between the front and backend, reduce errors and bugs, find and diagnose those bugs more quickly when they do arise, and improve performance.

Finally, the http transaction is terminated with the .end() method. This method ends the server function, passing in the resource that user originally asked for. That resource will be added to the response object along with the headers we constructed, where it will usually be consumed by the frontend in some way.

3️⃣ `listen` Method

Event handlers are a core feature of most programming languages, adding interactive features to a program through binding actions (what are commonly called "listeners") to elements. Or, as is the case in our example, to a port - a place in a computer.

In JS, we're familiar with binding an action to an element, like a button, using .addEventListener(). When that button is later clicked (acted upon), something will happen. In Node, using the .listen() method is the loose equivalent. Loose because despite both using JS, the event model in the browser environment and the event model in the Node environment are not identical.

This step is akin to turning the server on - we'll pass 3 of 4 optional arguments so that the server first knows where it will receive traffic, and second, will give us a message when the event listener is successfully bound - that is, it's listening!

server.listen(port, host, () => {
    console.log(`server listening on http://${host}:${port}`);
}

The .listen() method comes to us on the Server class of the http module. It takes up to four arguments - a port, a host, a backlog and a callback function. This callback function is kind of like a "listener for the listener." It only fires when the listener is successfully bound, meaning that the server was able to start watching for traffic at the port we gave it.

📝 About Developer Style

In our example the .listen() method is called on its own line but you'll see this done differently, with other arguments passed, by other developers. Code is pliable, and methods are usually chainable. For example, we could have omitted the third argument and attached the event listener to the tail of the createServer function.

const server = http.createServer((req, res) => {
    res.statusCode = 200; 
    res.setHeader("Content-TYPE", "tex/plain"); 
    res.end("Hello World, from Node!"); 
}).listen(port, host);

Both examples achieve the same result - letting the server know that we want it to start listening at port 3000 on our machine. The subtle differences in approach come down to developer style. Personally, I find the file easier to read from top to bottom when major actions, like turning the server on, get their own space in the document flow. Pay attention to these differences, reasoning about them and trying them out in your own projects can help you get better at reading code and develop your coding style.

Interacting the Server

With our simple server built, we'll see if it works by executing it inside of the Node environment. To do that make sure the index.js file is saved and open a terminal window.

From there we need to navigate to the directory the server can be found in. The cd command stands for "change directory", use it to move through the directories and files of your machine. You can chain further directions by using a forward-slash, /.

I've stored this project in a folder named node_server_ex, located on my desktop. I can navigate to it like so:

cd desktop/node_server_ex

Once in the correct directory, use the "list files" command, ls, to make sure index.js is there.

ls

→ index.js

Now we call Node and tell it to run the server by giving its file name.

node index.js

Assuming everything goes as planned and there are no errors, the Node environment will execute the file, going through the code inside, turning on the server's event listener, and finally returning the message found in the listen method's callback function: server listening on http://127.0.0.1:3000

The terminal window is now devoted to propping the Node environment so the server can continue running, waiting for user traffic. We can't use this particular window for anything else right now - if you try to navigate to a different directory, or use the ls command, nothing will happen. But we need to keep it open or the Node environment will close, taking the server with it.

With the server running, we now just need to visit its port so we can see what it's sending! Open a browser window and navigate to http://localhost:3000 - where you should see your server's welcome message - "Hello World, from Node!".

With that, you've built a Node server! It can't do much right now, but this example helps conceptualize some of the fundamentals of Node. We learned that inside the Node environment we can use JS outside of the browser - on the backend - to process user requests, send responses and provide the functionality of a full-featured computer application.

Much of the work done in Node relies on its communication-obsessed http module, which gives us a robust Server class and a myriad of methods to receive and handle and manipulate requests, send detailed headers and more.

In later installments of this series on Node and Express we'll discuss more about the asynchronous nature of Node and JS, cover some database fundamentals, and see how Node, Express and JS can be used to perform CRUD operations and build RESTful APIs.

Resources:

What is Node? - codecademy
Hypertext Transfer Protocol - w3schools
Node.js server.listen() Method - w3schools
A Look at Server-Sent Events - Simon Prickett
JavaScript Events - MDN
Node Official Site - highly recommend the docs on the official site - they're well put together and exhaustive

I hope you enjoyed the first part of this series - if I got anything wrong, didn't explain it enough, or missed something important - please reach out and let me know! All feedback is welcome, and thank you for reading 🦄

Errors and Updates:

Update 3/10/21: I updated the section on http headers. I was erroneously referring to the "header" object, when I should have been referring to the plural "headers." This was a misstep I became aware of as I prepare to share the next part in the series.

APB: A Real Look at Pseudo-Selectors

Ash — Fri, 05 Feb 2021 00:18:11 +0000

When I began seriously learning CSS - mostly by pouring through the repositories of my betters and experimenting with what I found there - I was mystified by pseudo-selectors, and especially pseudo-elements. Intimidated, I quickly jotted down a new question for the All Points Bulletin Board and moved along:

What are pseudo-elements? What do ::before and ::after refer to?

When I returned and set out to answer these questions, I found I couldn't learn about pseudo-elements separate from pseudo-classes. The two are inherently linked, working on an odd plane of specific un-specificity, and the real magic becomes apparent when the two are combined.

We'll first take a look at pseudo-classes. Though pseudo-classes are broader, and there are many more of them, I find them easier to reason about.

Pseudo-Classes

A pseudo-class is a CSS simple selector that targets elements that exist in a specific state. That state can be whether or not they're the first child of their parent, if they're actively selected or hovered and so on.

Pseudo-classes act like any another class in CSS - allowing us to write specific rules for parts of the document, with the added benefit of keeping our html markup free and clear of excess class names.

The basic syntax looks like a keyword glued to the end of a selector with a single colon:

element:pseudo-class {
    property: value;
}

👉 Note: It's valid to use a pseudo-class without the element selector preceding it - but be wary. Part of the magic of pseudo-classes is how their specificity works. By nature, their specificity weight is low, stripping the element selector makes them even less specific - compiling to *:pseudo-class.

There are several pseudo-classes you're probably already familiar with that often come in handy:

:first-child
:invalid
:last-child
:active

And you're sure to have seen this common use case a time or two:

button:hover {
    color: red;
}

This example references the button elements, then uses the pseudo-class :hover to apply a rule. In this case, when a button on the page is in a hovered state then the pseudo-class (and any rule it contains) applies, making the font color red.

It should be noted that :hover is in a group of special pseudo-classes, known as user-action or dynamic pseudo-classes. These perform a little differently, giving or taking away a pseudo-class depending on user interaction, like hovering. Other examples of dynamic pseudo-classes include :focus and :active.

Using pseudo-classes is something like getting class names for free, available if and when we need them. Meaning, we can specifically style pieces of text, colors, font-sizes, box-shadows and more without cluttering the html markup with extraneous classes attached to elements.

🙋‍♂️ To conceptualize what all that means, let's imagine we have a client that has hired us to build a basic website to share their favorite pieces of writing. We built the following page, using html and CSS:

The client, while happy with the overall design, has requested that the first paragraph (the first <p> element) of every post be in a bolder typeface.

Your first instinct might be to add a class to the html. Perhaps one conveniently named - like "first".

<article class="post-body">
  <h2>Lorem Title</h2>
  <small>by Alexander Wagner 2020</small>
  <p class="first">Lorem ipsum dolor sit amet...</p>
  <p>Aenean pharetra convallis pellentesque...</p>
  <div>
    <button>Comment</button>
    <button>Save</button>
  </div>
</article>

This will work, but there's a few problems with the approach. First, we have to go through and add the class to every first paragraph. And what if the first paragraph were to change at some point? Adding another class to achieve this result is prone to typos, is hard to maintain and update, and isn't very DRY.

Instead we'll use the :first-of-type pseudo-class - a class we get for free, that maintains itself. And to use it we won't have to change a thing in the html.

article p:first-of-type {
    font-size: 120%;
    font-weight: bold;
}

In plain English article p:first-of-type translates loosely to "First, look for every article element in the document. Then search their children for the first occurrence of a paragraph element. Finally, apply these rules to it." The :first-of-type pseudo-class is in yet another sub-classification of pseudo-classes, known as structural-tree pseudo-classes.

Pseudo-classes are broad - there's a lot of them, each one doing something a little different than the last. But in general, pseudo-classes allow us to dynamically style a page - reacting to screen interactions and providing visual reassurance to users - all without changing and cluttering the html.

Pseudo-Elements

A pseudo-element can be used to style specific parts of an element - like the first line or first letter. They can also be used to add a whole new element to the document, allowing us to insert content before, or after, the contents of an element. With this approach, for every one element we build in html - we get two for free!

Like pseudo-classes, their syntax is comprised of a keyword (the reserved pseudo-element name) added to a CSS selector - but this time with a double colon:

selector::pseudo-element {
    property: value;
}

👉 Note: The extra colon isn't strictly required (for CSS2 and CSS1) for some pseudo-elements, but is added by convention to easily distinguish between pseudo-elements and pseudo-classes. Because some early pseudo-elements used only a single colon, modern browsers support backwards compatibility for this usage.

There are seven pseudo-elements that are considered non-experimental. Five of them work to target different parts of an existing element:

::first-letter
::first-line
::marker
::placeholder
::selection

The remaining two work differently than the rest, creating entirely new elements when they're used:

::after
::before

👉 Some pseudo-elements have varied support across browsers, like ::marker and ::selection. Stop over to Can I Use? to learn more.

🙋‍♂️ The client has returned, armed with ideas to refine their website. They've requested a stylish icon appear before the title of each article. As with many tasks in programming, there's more than one way for us to do this.

We could use a <span> element to wrap a special html character before each title, styling it independently as needed.

<div class="post-body">
  <h2><span>&#9815;</span>Lorem Title</h2> 
/* 👆 This special character "&#9815;" is a rook symbol */
  <small>by Alexander Wagner 2020</small>
  <p>Lorem ipsum dolor sit amet...</p>
  <p>Aenean pharetra convallis pellentesque...</p>
  <div>
    <button>Comment</button>
    <button>Save</button>
  </div>
</div>

You already know the problems with this - another element will have to be added to the html for every post, creating clutter, opening up possibilities for typos, and making the page harder to maintain. Furthermore, we're not adding this element to benefit the structure of the source code - it's only being used to provide a stylistic touch - making it a perfect use case for the ::before pseudo-element.

article h2::before {
  content: "♗";
}

The ::before and ::after pseudo-elements are special - rather than targeting a part of an element, they insert content into the document before or after the content that already exists there, using CSS. Both can only be used once per targeted element, and must be used with the content property.

Using the content property we can add:

A string - a plain sentence, special html symbols, etc.
An image - we can provide a url() or a gradient background (which is an image itself)
A counter - lesser used, but can be useful for a CSS developer. This counter generally represents a number produced by various computations.
Nothing at all - This still requires setting the content property to the value of an empty string. Usually used to insert images as background-images, or the clearfix hack.

The new elements created by using ::before or ::after are inline by default, but can be moved and positioned relative to their parent. In that case it's important to note their source-order. Thankfully, it's easy to remember - ::after content is also after in stacking order. Meaning that if it happens to overlap a ::before pseudo-element, it will cover that element.

♿ A Note on Accessibility

Content that is generated by CSS, like the things we inject with ::before and ::after, are not in the Document Object Model, commonly known as the DOM. Elements that are not in the DOM tree are also absent in the Accessibility tree. For that reason, we should only use pseudo-elements to change the look of a page, not to convey anything of importance about the page's purpose.

With Our Powers Combined!

Used independently, pseudo-classes and pseudo-elements are capable of doing some amazing things. But using them together, in unison with CSS selectors and classes we define ourselves, can open up a whole new worlds of possibility. We can chain pseudo-elements onto pseudo-classes, allowing us to be just specific enough to target parts of an element, in certain states, and apply refined rules.

🙋‍♂️ Our client sent us a late night email - they no longer want the whole first paragraph bold, instead they want to target just the first line of the post. Without pseudo-selectors this is harder to solve for.

Perhaps we could wrap the first sentence of each paragraph in a <span> element and style it. But what if that first sentence runs over the first line, or doesn't quite reach the end of it? On different screen sizes, at different font sizes, adjusting for this approach would be a complete nightmare - and arguably impossible.

But with pseudo-selectors we can achieve this by chaining the ::first-line pseudo-element on the :first-of-type pseudo-class we were already using - creating what is known as a compound selector.

article p:first-of-type::first-line {
  font-size: 120%;
  font-weight: bold;
}

Looking at the selector, we can follow it like a word map: "Start by looking for the all <article> elements in the document, and step into them. Once there (in all of them simultaneously) look for the element that is the first of <p> type, and grab the first line - however long or short that may be, regardless of font size or screen width - and make it a little bigger and bold."

👉 The ::first-line pseudo-element applies only to block-level elements.

Given the sheer number of available pseudo-classes, there's a nearly endless amount of ways to combine them with compound selectors - and the rules aren't terribly well defined.

Generally, the order of simple selectors (aka pseudo-classes) don't change the meaning of a compound selector, and we can use as many of them as we want. But each compound selector should have only one pseudo-element - and it should appear at the end.

When we want to provide a website with more style, or unique ways for the user to interact with it, we can look to pseudo-classes and pseudo-elements. They allow developers to style things that are hard to express structurally, change at different points in time or don't exist in the document tree at all.

Using them has the benefit of producing clean, easy to maintain code that doesn't require special sizing rules across various devices. And because we don't have to touch the html (and therefore the document structure) to use them, semantics are preserved.

But they're not without their catches and gotcha's. Because the specificity weights of pseudo-selectors works so uniquely, unexpected bugs can come up when we're too specific, or likewise, when we're not specific enough. Another major barrier is cross-browser support. When using pseudo-selectors, especially experimental ones, be sure to do your research before committing to any one approach.

Quick Reference

A pseudo-class targets an element's various states. Allowing us to select and style the element based on information that lies outside of the document tree that would otherwise be impossible (or at least very difficult) to express using other simple selectors.
A pseudo-element targets different parts of an element, representing additional information about an element (like what its first letter is) that isn't directly present in the document tree.
There are 7 non-experimental pseudo-elements, and many more pseudo-classes that are broken down even further into several sub-categories - including dynamic, structural-tree, time-dimensional and more.
::before and ::after pseudo-elements are used to insert content onto the page, but not into the document tree. They need the content property to work correctly.
When creating compound selectors in CSS we are free to use as many pseudo-classes as we want or need, but should use only one pseudo-element, adding it only at the very end of the selector.
CSS-generated content is not included in the DOM, and shouldn't be used for important information that would miss users requiring a screen reader or other adaptive technology.

🔍 Check out the resources below to learn more about pseudo-elements and (the many) pseudo-classes. While I've done my best to cover the topic as a whole, these posts illuminated the intricacies, bugs, and conceptual challenges that plagued me along the path to understand how these strange, "fake" CSS entities work.

Resources:

CSS Pseudo-Selectors: Classes & Elements - MDN
Selectors Level 4 - W3C Working Draft
:first-of-type - CSS Almanac - CSS Tricks, Sara Cope
A Guide to CSS Pseudo-Elements - LogRocket, Nwose Lotanna
Pseudo-Element Round Up - CSS Tricks, Chris Coyier
::Before / ::After - CSS Tricks, Sara Cope
CSS Pseudo-Elements - W3schools
Learn to Use CSS Pseudo Elements for Styling Parts of HTML Elements - BitDegree
An Ultimate Guide To CSS Pseudo Classes And Pseudo Elements - Smashing Magazine, Ricardo Zea

🦄 All feedback is welcome and as always - thank you for reading!

Position: Relatively Confused

Ash — Sat, 16 Jan 2021 20:16:18 +0000

The layout of a web page, and how responsive and scalable it is, separates an amateur site from a pro site. One of the first questions on my All Points Bulletin board was related to controlling layout with position:

What does the position property do? What do the values absolute and relative mean?

When first learning the ins and outs of CSS I was easily confused by the number of options to control the layout of a page. There's CSS Grid, Flexbox, floats and pure positioning. I often lost track of what properties belonged to which, trying to use the top property in a flexbox column, or using trial and error to plug in justify-content, align-items, and margin values to center content.

I've learned that a finished website usually has a little bit of everything, and being familiar with the basics is a powerful tool when trying to figure out why an element, or a group of elements, isn’t behaving how you expected.

The Position Property

The position prop specifies the positioning method applied to an element.

There are 5 possible methods:

Static
Relative
Absolute
Fixed
Sticky

Once an element's position property is set to anything but static (the default setting) it will have access to the top, left, right and bottom properties - what I'll refer to as the positional properties.

1️⃣ Position: Static

By default the elements on a web page are displayed in static position. They appear in the viewport according to the document flow and writing method of the browser. Some browsers display left-to-right, right-to-left, or vertically down the page depending on the selected country and language.

🙋‍♂️ In this example we have a client who has asked us to create a simple dating profile page. The finished page uses basic structure - the elements are laid out in a logical order, from top to bottom as we want them to appear. They follow a flow.

A page without CSS to explicitly change the ordering or positioning of elements (a page in default static) is said to be in Normal Flow.

When a page is in Normal Flow, elements are displayed one after another, in block dimension, as they appear in the code. When the page is scrolled the elements scroll with it.

The positional properties (top, bottom, right, and left) do not effect an element that is positioned statically.

2️⃣ Position: Relative

When an element is moved by changing its positioning method (using the position prop rather than display), it's always being moved in reference to something - like another element, or itself.

Applying position: relative sets that reference to where the element would be in Normal Flow. At first it won't look like it did much of anything, that's because the element won't move until a positional property tells it to.

🙋‍♂️ Using the same example from above, the client wants us to center his profile image on the page. We could do this by using relative positioning, and a little bit of hackiness.

The image element, with class name profile_pic, was given a relative position and moved 35% to the left of that reference. This isn't the best approach to centering an element, but it works for now.

☝ Keep in mind! The space the element takes in Normal Flow is reserved - surrounding elements will not shift to fit or fill the gap, or make room for the element elsewhere.

3️⃣ Position: Absolute

Applying position: absolute on an element removes it, and the space it would normally take, from the document flow entirely. The point of reference is set to the elements nearest positioned ancestor, and a new stacking context is created. This context gives us access to the z-index property.

If the element has no positioned ancestor (a parent element whose position is anything but static/default), the reference points to the document body (the viewport). This is the first behavior that can confuse a developer and cause bugs in a layout.

🙋‍♂️ The client got back to us - he likes where the page is going, but wants to restructure the top of the page. He's requested that the profile element be smaller, and centered at the top of the page.

The image div was set to position: relative, allowing us to center its direct child, the image element, using an absolute positioning trick.

The basic syntax for this trick looks like this:

.parent {
    position: relative;
}

.child {
    position: absolute;
    top: 50%;
    left: 50%;
    transform: translate(-50%, -50%);
}

☝ It's important to note that a stacking context is created when using a range of other CSS positioning and layout methods - usually with a default value of 0. This can result in elements falling behind others unexpectedly. We set the z-index of the image div to -1, putting it further from the user, or behind other elements (like the navigation bar) in the stacking order.

☝ If an absolutely positioned element isn't appearing where expected, first make sure the element has a positioned ancestor. Most of the the time we don’t want to use the viewport as the reference, and when we do it’s easier and better practice to use position: fixed as we’ll see in a moment. Then make sure the positioned ancestor is the element you expect - going up or down a layer if needed.

4️⃣ Position: Fixed

Fixed positioning allows an element to be positioned according to the viewport. Like absolute, the element will be completely removed from the document flow. A positional property, usually top, needs to be used to view the element.

🙋‍♂️ The client's back! They brought us some more content, and they also want a navigation bar that remains visible at all times. We'll use fixed positioning to achieve this.

First, we gave the nav element additional styling rules, and applied position: fixed, setting the top and left properties. These instruct the browser to display the element as if it were pinned to the top left corner.

☝ Are other elements appearing over a fixed element? Remember, when an element's position property is set to either absolute or relative, a new stacking context is created. Try setting the the z-index of the fixed element to 1 or higher.

☝ It is possible to set the reference of a fixed element to something other than the viewport, though it’s not considered best practice. To achieve this, a containing parent must have the perspective, transform, or filter property set to anything but the default of none.

5️⃣ Position: Sticky

The last positioning method remaining is a bit of a hybrid - acting as both a relatively and a fixed positioned element at different times. An element with position: sticky applied toggles, appearing in Normal Flow until a user scrolls to a certain point, when it then becomes fixed.

🙋‍♂️ The client is thrilled with our work so far, as a final touch he wants to add a contact number to the page. He's asked that it's noticeable and easily located by the user. We'll use sticky positioning to make sure the user can always get ahold of Jack.

The phone_number element was added at the top of the document, styled with some Windows 95-flavored subtlety, and given sticky positioning. When the user first comes to the page it will be nestled right below the nav bar, but as they scroll to read more it will sticky itself safely within view.

☝ The sticky value is newer, and because of that it has less cross-browser support. Don’t worry too much about that though, the element will revert to fixed position and scroll with the user in the case that the sticky method isn’t supported. Additionally the WebKit Sticky extension may help.

A Word on Normal Flow

Good document structure is an integral part of accessibility-minded design. A well structured document is crucial for users that will never see our carefully laid out CSS, but it's just as important to those who do.

Normal flow is based on how a reader naturally traverses and consumes content. If an element needs to be moved relatively far from where it appears in normal flow, we should first consider adjusting its position in the document itself instead.

The CSS position prop is a powerful tool to control the layout of elements on a page, but it's not without its hidden nuances than can result in hard to solve bugs and weird behavior. I encourage you to play with the code in the examples, remove position from parent elements, or try new ones to see how they stack.

🔍 If you're still curious - check out the resources section below! I always come across great articles in the search to answer my own questions.

Resources:

Getting Started with CSS Layout, Smashing Magazine
CSS Layout: The Position Property, w3schools
Position, MDN
CSS: Position Property, Tech on the Net
The Stacking Context, MDN
What No One Told You About Z-Index, Philip Walton
Detailed Positioning, Shay Howe

As always - Thank you for reading 🦄

APB: Demystified Destructuring

Ash — Mon, 21 Dec 2020 00:22:07 +0000

I love digital media - blogs, e-books, the more the better. But as a self-identifying bibliophile, I never go long without picking up an old-school, paper and ink book. When I want to deeply learn something I always come back to the printed word.
There's something about highlighting passages, and scribbling in the margins that cements information in my mind. I'm not alone in this, and there have been several studies that suggest students of all ages learn more, and retain more of what they learn, from physical books.

I'm currently working my way through the third edition of Eloquent JavaScript by Marijn Haverbeke. Though I consider JavaScript my primary language and felt comfortable with it before starting, I've learned something new, or gained a deeper understanding of something I already knew with every chapter.

During my study time the other night I came to a section about the ES6 features we all know and love, specifically destructuring. The section was short, more of a summary than a deep dive, but it made me realize I needed to know more about this ES6 feature - so I added it to the All Points Bulletin Board.

Question: What is Destructuring Assignment?

Short Answer: Destructuring is a succinct way to pull values out of an object and attach them to local variables in a single statement. It can be used on arrays or objects, allowing us to provide aliases, default values, and even complex expressions to obtain or replace data.

The Long Answer

The first time I saw destructuring was when learning React, and you'll see it in a lot of similar frameworks and libraries. It allows us to easily unpack multiple values from an array or object and assign them to variables in a single line.

Despite its name, destructuring isn't destructive - nothing is being destroyed. The original array is not mutated. Destructuring assignment allows us to literally deconstruct the object into its constituent parts, make copies and assign them to new local variables.

The feature came about because we had ways to construct multiple properties at the same time through object and array literals, but no comparable mechanism of extracting data - other than piecemeal assignments.

const numbersArray = [1, 2]; 
const x = numbersArray[0]; 
const y = numbersArray[1];
console.log(x, y);
//---> 1, 2

Destructuring assignment works on the 2 most used data structures in JavaScript - arrays and objects. Array destructuring and object destructuring are very similar, with a few notable differences. We'll talk about array destructuring first.

Array Destructuring

At first glance destructuring looks a lot like an array or object literal - but flipped. Instead of a variable declaration on the left with the assignment on the right - the extracted values appear to the left, and the sourced variable on the right.

const numbersArray = [1, 2]; // array literal
const [ x, y ] = numbersArray; // destructuring assignment
console.log(x, y);
//---> [1, 2]

Note: I've used a subtle naming convention in the code above. When I use destructuring I pad the variables in the destructuring array between brackets or braces with a leading and trailing space. This helps me read my code later, scanning files I can easily identify when I'm using destructuring assignment.

Arrays are obsessed with position, just take a look at their built-in methods, and how those methods traverse elements. Array destructuring is no different, as we saw in the example above. The variables we created were assigned their values after being mapped to the value at the same index in the sourced array.

Using that syntax we know how to grab values from an array, but what else can we do?

We can assign values after declaration

let [a, b]; 
[ a, b ] = ["dog", "cat"];

We can skip values

If the source variable contains values of no interest, they can be skipped with a comma and an empty space.

const dogs = ["Sparkles", "Rover", "Mosby", "Rufus"]; 
const [ a, , b, c ] = dogs;
const [ , , ,favorite ] = dogs;
console.log(a, b, c); 
//---> "Sparkles", "Mosby", "Rufus"
console.log(favorite);
//---> "Rufus"

We can manipulate values with array methods

We can chain other methods that also return an array - like .split.

const name = "Mark Johnson"; 
const [ firstName, lastName ] = name.split(' '); 
console.log(firstName);
//---> "Mark"

We can provide default values

What if we try to unpack more values than the sourced array contains? In that case those empty variables will return undefined, and no error will be thrown.

To avoid ambiguity, we can provide a default value using the assignment operator.

const employeeHours = [34, 40]; 
const [ employeeOne = 30, employeeTwo = 30, employeeThree = 30 ] = employeeHours; 
console.log(employeeThree);
//---> 30
console.log(employeeOne);
//---> 34

These default values can take on much more depth, becoming complex expressions or function calls. They will only be evaluated if a value cannot be found.
Below I've used the .reduce method in a helper function to find the average of employeeHours and assigned it as a back-up for employeeThree.

const employeeHours = [34, 40]; 
const findAvg = (hours) => hours.reduce((a, b) => a + b, 0) / hours.length;
const [ employeeOne, employeeTwo, employeeThree = findAvg(employeeHours) ] = employeeHours; 
console.log(employeeThree);
//---> 37

We can assign the Rest

If we extract only one value from the sourced iterable, then we only get that single value. What if we wanted to directly grab one or two values, but make sure the rest are still captured?
We can use 2 other ES6 features - the rest parameter and spread syntax. Using spread syntax (...) before a variable name creates the rest parameter. Sometimes you'll hear this referred to as the "rest pattern".

Using the rest pattern is like selectively placing a couple of values in special boxes that can contain only one thing, and throwing the rest into a larger, catch-all box in case we need them later on.

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; 
const [ first, second, ...rest ] = numbers; 
console.log(rest);
//---> [3, 4, 5, 6, 7, 8, 9, 10]

const colors = ["red", "blue", "green", "yellow", "purple", "orangered", "goldenrod"];
const [ primary, secondary, accent, ...others ] = colors; 
console.log(others); 
//---> ["green", "yellow", "purple", "orangered", "goldenrod"]

Any name can be given to the rest parameter, but it must be proceeded by the spread syntax (...) and it must be the last variable in the destructuring array. If the rest parameter has a trailing comma it will throw an error.

We can extract values from nested arrays

So far we've been working with single layer arrays, but destructuring works on nested arrays too. As always, position is important and the corresponding item must be an array.

const styles = [["desktop", [800, 100, "relative"]], ["mobile", [500, 80, "absolute"]]]; 
const [ [ className, [ height, width, position ] ] ] = styles;

console.log(className);
//---> "desktop"
console.log(height);
//---> 800

Now that we've seen the basics, let's look a couple of use cases for array destructuring.

Use Case 1: Working with returned arrays

Functions commonly return an array. Using array destructuring can make working with returned arrays DRY-er and easier to read.
In the function below, we return an array and assign their values using destructuring. You can see that we can skip values, assign the rest and more, just as before.

function dummy() {
    return [10, 50, 30, 50, 60];
}

const [ first, second, , ...rest ] = dummy();
console.log(first);
//---> 10
console.log(rest);
//---> [50, 60]

Use Case 2: Swapping values

One very handy use case of destructuring is swapping the contents of two variables. Before ES6 this required creating a temporary variable.

let first = "one"
let second = "two"
// temporary variable
let originalFirst = first;
// swap the values
first = second; 
second = originalFirst;
console.log(first, second)
//---> "two" "one"

First a new variable, originalFirst, is created to capture the value of first, ("one"). Then first is directly reassigned to point to the value of second, ("two"). Finally second will be pointed to the value we captured in the temporary variable. If we didn't do this the original value of first would be lost upon reassignment.

Using destructuring removes the need for a temporary local variable, and several lines of code altogether. In the destructuring array we'll declare the variables, and then swap them in the assignment, effectively trading values.

let first = "one"
let second = "two" 
[ first, second ] = [second, first]; 
console.log(first, second); 
//---> "two" "one"

Use Case 3: Regex patterns!

Regular expressions, regex for short, provide us a way to search a string against a pattern. Using the exec function returns an array where the first element is the entire match, and the following elements are the smaller captured matches.

To illustrate what I mean, we'll look at a common regex pattern - the date matcher.

// this is a regex pattern - and a handy one to know!
const datePattern = /^([a-z]+)\s+(\d+)\s*,\s+(\d{4})$/i; 

let [ fullDate, month, day, year ] = datePattern.exec("December 20, 2020") || []; 

console.log(fullDate, month, day, year); 
//---> "December 20, 2020" "December" "20" "2020"

The exec function takes in the pattern to be searched for, and the string to be searched. It returns an array, containing first the full match with all of its spaces and characters ("December 20, 2020"), and then the individual matches that were captured ("December" "20" "2020").

Note that after calling the exec function and passing in a string, we provided the logical || (or) operator and defaulted the return to be an empty array if no match could be found.

Though this post isn't really about regular expressions, they're an incredibly valuable tool to have in your belt. They can be used to search for word, date, and other patterns in text - capable of being as broad or specific as needed. Read more about regular expressions here.

Object Destructuring

Object destructuring is very similar to array destructuring, so we'll touch on it quickly, concentrating on the differences. We can extract properties much the same way we do with arrays, but instead of brackets, we use curly braces.

const dogs = {good: "Rover", gooder: "Sparkles", goodest: "Ace"}; 
const { good, gooder, goodest } = dogs;
console.log(good, gooder, goodest); 
//---> "Rover" "Sparkles" "Ace"

If arrays are obsessed with position, objects are obsessed with name. That being the case, the property name must be spelled correctly with casing in mind, or it will return undefined.

const dogs = {good: "Rover", gooder: "Sparkles", goodest: "Ace"}; 
const { good, Gooder, goodest } = dogs;
console.log(good, Gooder, goodest); 
//---> "Rover" undefined "Ace"

If we're not interested in a value we don't need to intentionally skip it. Instead, we can simply omit the property name. Position doesn't matter, we need only to be aware of the property names we're interested in, and their location relative to depth.

const dogs = {good: "Rover", gooder: "Sparkles", goodest: "Ace"}; 
const { good, goodest } = dogs;
console.log(good, goodest); 
//---> "Rover" "Ace"

We can assign values after declaration - with one gotcha

If we assign a value to a variable without a declaration, we must wrap the assignment statement in parentheses.

let first, second; 
({ first, second } = {first: 1, second: 2}); // assignment statement
console.log(first, second);
//---> 1 2

If these parentheses are left out the statement will be read as a block, instead of an object literal destructuring assignment. They are not required when the declaration is present.

We can provide default values and assign the Rest

We can capture the rest, and assign a default value, the same way we do in array destructuring - the only difference is the curly brackets.

const topDogs = {
  first: "Rover", 
  second: "Marshmallow", 
  third: "Kurt", 
  honorableMentions: {
    costume: "Sparkles", 
    personality: "Buccaneer"
  }
}; 

const { first, third, fourth = "Cocoa", ...rest } = topDogs;

console.log(first, third, fourth); 
//---> "Rover" "Kurt" "Cocoa"
console.log(rest);
//---> Object {honorableMentions: Object {costume: "Sparkles", personality: "Buccaneer"}, second: "Kurt"}

We can provide an alias

If we want our identifier to have a different name than the property, we can provide an alias. Call the property name as usual, followed by a colon and the desired name.

const topDogs = {
  first: "Rover", 
  second: "Marshmallow", 
  third: "Kurt", 
}; 

const { first: gold, second: silver, third: bronze } = topDogs;
console.log(gold, silver, bronze);
//---> "Rover" "Marshmallow" "Kurt"

We can extract values from nested objects

The properties on the objects we've seen so far have contained primitive data types, but they can also contain complex structures, like another object. We can use destructuring to access values in these nested structures.

const topDogs = {
  first: "Rover", 
  second: "Marshmellow", 
  third: "Kurt", 
  honorableMentions: {
    costume: "Sparkles", 
    personality: "Buccaneer"
  }
}; 

const { honorableMentions: { costume: bestDressed } } = topDogs;
console.log(bestDressed); 
//---> "Sparkles"

I like to think of these statements as a map with legend. honorableMentions is not an identifier, or a variable. If we try to log it and peak at its guts, we won't find anything.
It just lets the compiler know to look for a nested object with name honorableMentions on the first level of the sourced object, reach into it and grab the value of the property with name costume and copy the value found there into our identifier bestDressed.

We can extract values an unlimited amount of levels down. We just need to keep track of how many levels deep we are (with the presence of brackets) and how many stops there are on the way (with property names).

Without destructuring we could accomplish the same result with dot or bracket notation.

const topDogs = {
  first: "Rover", 
  second: "Marshmellow", 
  third: "Kurt", 
  honorableMentions: {
    costume: "Sparkles", 
    personality: "Buccaneer"
  }
}; 

console.log(topDogs.honorableMentions.costume); 
//---> "Sparkles"

Use Case: Destructuring props

Working with the props system in React often involves working with large, complex objects. Here destructuring can really shine - making components not only easier to read, but easier to write.

In this contrived example, we're passing a card object to a card viewing component through props.

import React from "react";
import "./styles.css";
import CardViewer from './CardViewer'; 

const cardData = {
  front: "What does padding refer to in CSS?", 
  back: "Padding refers to the space between the border of the element and the content of the element", 
  user_id: 1, 
  public: true, 
  active: true, 
  notes: ["if border-box sizing is used padding will not effect the size of an element", "padding 'pads the content'"]
}; 

export default function App() {
  const card = cardData; 


  return (
    <div className="App">
      <CardViewer card={card} />
    </div>
  );
}

Without destructuring we have to repeatedly use the props prefix, and any further prefix needed, to get to the correct data in the CardViewer component.

import React, { useState } from "react";


const CardViewer = (props) => {
   const [ flipped, setFlipped ] = useState(false); 

   const flipCard = (e) => {
     e.preventDefault(); 
     setFlipped(!flipped);
   }


  return(
    <div onClick={flipCard}>
      <h3> {flipped ?
             `${props.card.back}` : 
             `${props.card.front}`}
      </h3>

      <div>
        <p>Notes:</p>
        <ul>{props.card.notes.map((note)=>{
          return <li>{note}</li>
        })} </ul>
      </div>

    </div>
  )
}

export default CardViewer;

Using destructuring we can easily grab the values we need in the component parameters, then in the return need only include the card prefix.

import React, { useState } from "react";


const CardViewer = ({ card }) => {
   const [ flipped, setFlipped ] = useState(false); 

   const flipCard = (e) => {
     e.preventDefault(); 
     setFlipped(!flipped);
   }


  return(
    <div onClick={flipCard}>
      <h3> {flipped ?
             `${card.back}` : 
             `${card.front}`}
      </h3>

      <div>
        <p>Notes:</p>
        <ul>{card.notes.map((note)=>{
          return <li>{note}</li>
        })} </ul>
      </div>

    </div>
  )
}

export default CardViewer;

We can take it even further with nested destructuring - grabbing only the things we're truly interested in. The resulting return reads almost like a sentence.

import React, { useState } from "react";


const CardViewer = ({ card: { front, back, notes: [ ...notes ] } }) => {
   const [ flipped, setFlipped ] = useState(false); 

   const flipCard = (e) => {
     e.preventDefault(); 
     setFlipped(!flipped);
   }


  return(
    <div onClick={flipCard}>
      <h3> {flipped ?
             `${back}` : 
             `${front}`}
      </h3>

      <div>
        <p>Notes:</p>
        <ul>{notes.map((note)=>{
          return <li>{note}</li>
        })} </ul>
      </div>

    </div>
  )
}

export default CardViewer;

Destructuring is another invaluable ES6 feature, allowing us to extract properties and values the same way we can construct them with object literals. Destructuring saves time, reduces confusion and can result in elegant, readable code.

The next time you're working with complex data structures, keep this feature in your back pocket and you might just save yourself some time and headaches.

Resources

Eloquent JavaScript - Marijn Haverbeke

The Babel Replit - Always a good place to toss some code in and learn what it does under the hood

Array Destructuring in ES6 - FreeCodeCamp

Destructuring Assignment - MDN Web Docs

ES6 Destructuring: The Complete Guide - Glad China, CodeBurst

Destructuring Assignment - Javascipt.info

Destructuring - exloringjs.com

Destructuring Regular Expression Matching - Marius Schulz

JavaScript Object Destructuring - Dmitri Pavlutin

Destructuring & Function Arguments - David Walsh

Destructuring Props in React - Lindsay Criswell, Medium

🦄 Thanks for reading!

APB: What are Arrow Functions?

Ash — Wed, 16 Dec 2020 22:20:14 +0000

Since beginning my journey to become a web developer I've kept a list. This list exists on a small cork bulletin board above my desk, connected with jewel-toned pushpins. The list is a collection of every question that has come to me in a moment when I couldn't stop and research. I call it my "All Points Bulletin Board," and the questions look like this:

What is the visual formatting model?
What do the properties absolute and relative mean? How do they work together?
What is lexical scope?
What is 7–1 CSS structure?
What are arrow functions? How do they work?

There are many, many questions on that list now. Some have answered themselves as I learned more and worked on more projects. Others I took the time to answer through reading documentation, google-fu and books, and many more are still unanswered.
The Notion docs have piled up, and I have decided to start sharing these questions and my answers, especially if the search to answer them is particularly illuminating.
I'll be starting with the question that was the hardest for me to wrap my head around when I first started learning JavaScript:

What are arrow functions?

Question: What are Arrow Functions?

Short Answer: Basically, shortened function expressions.

Arrow functions were introduced before I became acquainted with JavaScript. I wasn't sure when I was seeing them, where to use them, and why I would even want to. In the beginning I didn't even recognize them as functions - they don't have the trademark keywords we usually see, and some don't even require parenthesis or brackets.

const multiply = (a, b) => a * b;

Arrow functions don't include the keyword function and if the code block is only one statement long, like the example above, the return keyword can be omitted. Furthermore, if only one parameter is passed in, the parentheses wrapping it can be left out.

const double = n => n * 2;

But that's not the whole story. Function expressions and arrow functions (also known as "fat arrows") can behave very differently, looking under the hood will explain why.

The Long Answer

To really break down what an arrow function is, I started by exploring the other ways functions are declared in JavaScript. Namely, function declaration and function expression.

A function created using function declaration is also known as a named function. These functions are hoisted to the top of their scope, and are called by their name. Named Functions effectively store functions until we need them.

// Function Declaration / Function Statement / Named Function function multiplyOrDivide(a, b){ if (a % 2 === 0){ return a * b } else { return a / b } };

On the other hand, a function created using function expression is known as an anonymous function. Anonymous functions are often stored in a variable, which is how we'll eventually call them.
You'll see functions created this way used as IIFEs - Immediately Invoked Function Expressions. That's a separate blog post though.

// Function Expression / Anonymous Function const multiply = function(a, b){return a * b}; console.log(multiply(5, 10)); // -> 50

The main difference between these two is the function name and *hoisting. *Function declarations are hoisted, function expressions are not.

**Note: In short, hoisting refers to the JavaScript compilers way of reading code - variable declarations are 'lifted' to the top of their scope and they can be called before they appear in the code. The compiler does this to preemptively create space in memory, but it can create bugs if you don't know what's going on. (Read more about hoisting Here)

Arrow Functions: Use Cases and Gotchas

Arrow functions were introduced in ES6, in large part to reduce confusion surround the this keyword. When writing code using Promises and Callbacks, for example, the resulting code can be a maze of return and function keywords, and this can be hard to keep track of.

Use Case: Using an arrow function provides lexical this

In ES5 the complexities related to this were worked around by creating closures, or using the (performatively slow) .bind() method. Arrow functions are a salve for this- they retain the scope of the caller inside the function. Let's look at an example:

// Function Expression / Anonymous Function API.prototype.get = function(resource) { var self = this; // closure created to bind this return new Promise(function(resolve, reject) { http.get(self.uri + resource, function(data) { resolve(data); }); }); };

This example was pulled from an article by Jack Pennell, where he cites Jack Franklin as the provider. You can read the whole article here.

It's a good example to visualize what we're talking about. Going into the function we immediately have to bind this and then site it in the get method. Using an arrow function we don't have to do this extra step.

// Arrow Function / Fat Arrow Function API.prototype.get = function(resource) { return new Promise((resolve, reject) => { http.get(this.uri + resource, function(data) { resolve(data); }); }); };

In the arrow function (that retains the scope of its caller) this is already bound. In fact we cannot change its value. Methods like call, apply, and bind will not work.

Unlike other function types, arrow functions have no prototype property - they're more akin to a method (or an internal function) in this way. If we needed the uri in this example to be dynamic, we would not be able to use an arrow function.

Use Case: Easier to read array manipulations

ES6 came with more than just array functions (although arrow functions have been one of the most used additions), array methods like the very popular map function, were also introduced. Using arrow functions in methods to manipulate and read arrays can arguably make them easier to read.

// Function Expression / Anonymous Function const groceryList = [ {name: 'bananas', type: 'fruit'}, {name: 'broccoli', type: 'vegetable'}, {name: 'chicken', type: 'poultry'}, {name: 'apples', type: 'fruit'} ]; const types = groceryList.map(function(item) { return item.type; });

Now let's use an arrow function:

// Arrow Function const groceryList = [ {name: 'bananas', type: 'fruit'}, {name: 'broccoli', type: 'vegetable'}, {name: 'chicken', type: 'poultry'}, {name: 'apples', type: 'fruit'} ]; const types = groceryList.map(item => { return item.type; });

We can simplify the function even further:

Arrow functions have been widely adopted by the developer community, and for good reason. They can help us write easier to read and maintain code - but they aren't without pitfalls, and they are not a 1:1 substitution for the function declarations and expressions we're used to.

Arrow functions don't have access to the arguments object, they have no prototype property, or other internal methods. Their scope is always bound to its caller, and cannot be changed.

You can use arrow functions when writing code that relies heavily on promises and callbacks, like in a NodeJs environment. Or when manipulating large arrays, a common task in React.

To get a better idea of when and where to use arrow functions, I recommend reading this StackOverflow thread. There many developers give insight into how their teams use (and don't use) arrow functions.

Resources:
ES6 Arrow Functions: Fat and Concise Syntax in JavaScript
When (and why) you should use ES6 arrow functions - and when you shouldn't
An Introduction to JavaScript Arrow Functions

DEV Community: Ash

8 Things I've Learned in 12 Months on the Job

1. Embrace your community.

2. Document, Document, Document.

3. Don’t forget the company tooling.

4. Ask the ‘stupid’ questions.

5. If you make a mistake, be proactive.

6. Effect the change you want to see.

7. Find what motivates you to code and seek that out.

8. Never stop learning.

Accessibility: Title Achievement

The Title Element

Syntax and Use

Accepted Attributes

Implicit ARIA Roles

Title Consumption

Basic Best Practices

Use Case: The Confetti Club

Dynamic Best Practices

Use Case: The Confetti Club Search Page

Resources

5 Things I've Learned in 6 Weeks on the Job

1. Try not to call attention to, or apologize for, your lack of experience.

2. Your coworkers are a resource - but a limited one.

3. Document, document, document

4. Don't take anything personally.

5. Don't stop learning.

Exploring the Browser Environment through Routing

Prerequisites: The Browser Environment, the DOM, and the BOM

Project Introduction

Brute Force Routing

The Route Component

The Nav Component

The Link Component

Preventing Default Behavior

Implementing Custom Behavior

Creating a Custom PopStateEvent

Updating the Route Component

Resources:

🦄 As always - thank you for reading! 🕶

A Quick Guide to Understanding React Hooks

React Hooks 🎣

🤔 What is a hook?

1️⃣ The useState Hook

Syntax & Use

2️⃣ The useEffect Hook

Syntax & Use

The Dependency Array

The Cleanup Function

3️⃣ The useRef Hook

Syntax & Use

Resources:

🦄 As always - thank you for reading! 🕶

Introduction to Node

Intro to NodeJS

✅ Pros:

📛 Cons:

Installing Node

Creating a Server

1️⃣ Variables http, host and port

2️⃣ createServer Function

3️⃣ listen Method

📝 About Developer Style

Interacting the Server

Resources:

Errors and Updates:

Update 3/10/21: I updated the section on http headers. I was erroneously referring to the "header" object, when I should have been referring to the plural "headers." This was a misstep I became aware of as I prepare to share the next part in the series.

APB: A Real Look at Pseudo-Selectors

Pseudo-Classes

Pseudo-Elements

♿ A Note on Accessibility

With Our Powers Combined!

Position: Relatively Confused

The Position Property

1️⃣ Position: Static

2️⃣ Position: Relative

3️⃣ Position: Absolute

4️⃣ Position: Fixed

5️⃣ Position: Sticky

A Word on Normal Flow

1️⃣ Variables `http`, `host` and `port`

2️⃣ `createServer` Function

3️⃣ `listen` Method