Forem: wlytle

Passing variables and objects in Javascript: Reference compared to Values

wlytle — Sun, 07 Mar 2021 03:34:25 +0000

Motivation

I'm applying and interviewing for jobs right now and consequently brushing up on algorithms and data structures. This has led me to a lot of tinkering with recursion and backtracking. I'm a kinesthetic learner and keeping track of what's going on deep in a recursion stack makes my brain tired - so practice! This is NOT a blog about recursion and backtracking, although one of those may be here soon (In the meantime here is a pretty good article on the subject.

All this practice has brought my attention to a Javascript feature (quirk) that I often forget about in these situations - Javascript's passing of values or references depending on the data type.

Reference Vs. Value

When passing a variable that points to an object a reference to that object gets passed. When passing a variable that points to a number, boolean, string, or undefined the value of the variable is passed. Practically this means assigning multiple variables to an object will allow all of those variables to access the same object. This is not true with values. Quick example:

let x = "Cheddar";
let y = x;
y = "Manchego"
console.log(x) //"Cheddar" 
console.log(y) //"Manchego"

let x = ["Cheddar"];
ley y = x;
y.push("Manchego");
console.log(x); //["Cheddar", "Manchego"]
console.log(y); //["Cheddar", "Manchego"]

We can get around this by using the spread operator:

let x = ["Cheddar"];
ley y = [...x];
y.push("Manchego");
console.log(x); //["Cheddar"]
console.log(y); //["Cheddar", "Manchego"]

Importance for Recursion

Okay, that's all well and good but what does this have to do with recursion? Well, to be perfectly honest, not much, but for me, it keeps coming up when refactoring iteration to recursion or visa-versa.

Let's take a look at the quintessential recursion example: Fibonacci (More info on the Fibonacci sequence available on the always helpful Wikipedia).

Here's a quick function to return the nth term in the Fibonacci sequence:

function fibonacci(n) {
  const dict = {};
  return calcFib(n, dict);
}

function calcFib(n, dict) {
  if (n === 1 || n === 2) {
    return 1;
  }
  if (dict[n]) return dict[n];
  result = calcFib(n - 1, dict) + calcFib(n - 2, dict);
  dict[n] = result;
  return result;
}

Notice that at every return we have to return the result. If we had chosen to make result an argument of calcFib, we would still need to return the result of the calculation. This is because when we pass down result to another instance of calcFib it is just the value result points to not the result we will eventually return. Another way to look at this is through the lens of our memoization dictionary, dict. We never return this value yet it remains updated through all instances of calcFib. This happens because dict is an object and so we are updating a reference to the location of dict in memory, not just the values contained in dict.

Let's look at a non-recursive version to see if we can clear this up. Here is an iterative function to return an array of the first n terms of the Fibonacci sequence.

function calcFib(current, previous, result) {
  result.push(current + previous);
}

function fibonacci(n) {
  let result = [];
  //base cases
  if (n === 1) return result.push(1);
  if (n >= 2) {
    result.push(1);
    result.push(1);
  }

  for (let i = 1; i < n - 1; i++) {
    calcFib(result[i], result[i - 1], result);
  }
  return result;
}

Notice that in calcFib we don't return anything! We can get away with this because we are updating an array (which in Javascript is a type of object) and that means we are passing calcFib a reference to the result array. When we add another value of the sequence to result we are always updating the same object in memory.

Final thoughts

The 5-cent takeaway here: in Javascript objects are passed by reference, meaning they always point to the same object in memory even if being passed to another function with a different scope. Everything else is passed by value, so if you are entering another scope and you want an updated value back make sure to return it!

Thanks for reading and hope this saves someone a bit of debug time.

Implementing a Searchable, Async Dropdown in React

wlytle — Mon, 25 Jan 2021 18:44:24 +0000

Motivation

I've been working on an app with a React frontend and a Rails backend where a user can create a trip via an interactive map. I wanted to allow a user to invite collaborators to help build out their trip. On first thought, I figured I would load all of my users into state and then query that to get quick responsive feedback. However, I realized I want to search my users and this can, and hopefully, will become a large dataset. This makes me hesitant to load too much data into state as it is all stored on RAM. The solution, an elegant and simple Library called react-select.

This walkthrough assumes some comfort with React, hooks, and controlled forms.

TLDR

react-select provides a convenient select component that works nicely with AJAX requests.
Good documentation available Here.
Code example at the end of the blog.

Installation

Assuming you have a react app already spun up installation is nice and simple.
run npm install react-select

It's important to note that react-select has a robust library of different options. I'll cover some of them but will mostly be focused on the async features of the library. Again see the full docs Here.

With that said, make sure to include import AsyncSelect from "react-select/async" at the top of your component.

Usage

They make it so simple!



return <AsyncSelect />

This will give us a nicely styled search bar with a dropdown... But it's not wired up to any logic.

A Short Digression About Data

Before we get too far into the weeds, we need a quick primer on the data structure react-select is built to expect. react-select expects data to be an array of objects with each object having keys label and value. The label value is the information that is displayed and the value value indicates which information is selected (clear as mud right?). Let's look at an example.



const data = [
  {
    label: "Cheddar",
    value: 1,
  },
  {
    label: "Manchego",
    value: 2,
   },
 ]

In this example, the dropdown menu will show Cheddar and Manchego when those values meet the search criteria. If a user selects Manchego react-select will grab the data associated with the object whose value corresponds to 2

Props

The AsyncSelect component takes in a myriad of props that add functionality and styling. The component is set up to work with callbacks or promises; we will focus on promises.

onInputChange

This prop is similar to a simple onChange in an input field and will record inputs. This prop can be used to make the select menu a controlled component.



import React, { useState } from "react";
import AsyncSelect from "react-select/async";

const [query, setQuery] = useState("");

return <AsyncSelec 
         onInputChange={onInputChange={(value) => setQuery(value)}
       />
...

loadOptions

This is the most important prop. loadOptions accepts a function that must return a promise (or callback) and this promise should resolve to be your search data. For my purposes, this promise comes from a fetch request to my rails API with a search parameter set to my sate query variable.



const loadOptions = () => {
// You must return this otherwise react-select won't know when the promise resolves! 
    return fetch(`http://localhost:3000/collabs?q=${query}`)
      .then((res) => res.json());
 };
...
loadOptions={loadOptions}
...

It's worth noting that the above fetch request returns the results of a search function using the query parameter. If you wanted to do all the filtering on the front end you could implement something like this.



const loadOptions = () => {
    return fetch(`http://localhost:3000/collabs`)
      .then((res) => res.json())
      .then((data) = > {
          data.filter((ele) => ele.user_name.includes(query))
       }
 };

onChange

The onChange prop tells the component what to do with the selected record. I found it very helpful to simply store this in state as well for later use. This way the value can also be set in a callback prop so a parent component can know what was selected.



// In parent component
const [collabs, setCollabs] = useState("");
<AsyncSearchBar setCollabs={setCollabs} />

// in async searchbar component
const AsyncSearchBar = ({ setCollabs }) => { 
...
<AsyncSelect
        loadOptions={loadOptions}
        onInputChange={(value) => setQuery(value)}
        onChange={(value) => setCollabs(value)}
      />

That's all you really need to get things going! You can see you get a nice loading message while react-select is waiting for the promise to resolve.

Bonus props

There's a lot more to be said about the optional props of react-select I'll leave most of that to you, but I do want to go over a few that I found most helpful.

`getOptionLabel` and `getOptionValue`

Odds are that your data is not already configured to have value and label keys. These props help account for that. Both props take a callback that indicates the key in the data that should be used in place of label and value.



...
        getOptionLabel={(e) => e.user_name}
        getOptionValue={(e) => e.id}
...

Here we are telling react-select to use the user_name key instead of label and the id key instead of value. No Need to reformat data!

`isMulti`

This is a great prop that only needs to be set to true. It allows you to select multiple options from the dropdown.

`cacheOptions`

This prop also only needs to be set to true to be included. It will cache the returns from loadOptions. If you retype something in short order or say hit backspace, the component will have access to previous search results and will not fire off more fetch requests.

Animations!

react-select allows you to wrap most parts of the search bar in custom components which is really nice; we can use this to implement some slick built-in animation styles. First we need to add
import makeAnimated from "react-select/animated";
to our imports. Then we can use this import to easily create animated wrapper components.
const animatedComponents = makeAnimated();
Then we use the components prop like so
components={animatedComponents}

Putting It All Together

Here is the full code for reference:



// In parent component
const [collabs, setCollabs] = useState("");
...
<AsyncSearchBar setCollabs={setCollabs} />

// ./AsyncSearchBar
import React, { useState } from "react";
import AsyncSelect from "react-select/async";
import makeAnimated from "react-select/animated";
import { makeHeader } from "../actions/TripActions";

const AsyncSearchBar = ({ setCollabs }) => {
  //set default query terms
  const [query, setQuery] = useState("");

  //get animated components wrapper
  const animatedComponents = makeAnimated();

 // fetch filteres search results for dropdown
  const loadOptions = () => {
    return fetch(`http://localhost:3000/collabs?q=${query}`)
    .then((res) => res.json());
  };

  return (
    <>
      <AsyncSelect
        cacheOptions
        isMulti
        components={animatedComponents}
        getOptionLabel={(e) => e.user_name}
        getOptionValue={(e) => e.id}
        loadOptions={loadOptions}
        onInputChange={(value) => setQuery(value)}
        onChange={(value) => setCollabs(value)}
      />
    </>
  );
};

export default AsyncSearchBar;

I hope you found this helpful in implementing this beautiful library into your projects!

Animating Content Between Components in React

wlytle — Mon, 04 Jan 2021 14:53:37 +0000

I've been working on a game app in React with some fellow students in Flatiron's Software Engineering Bootcamp and found myself in my least favorite place; staring down the barrel of a complex CSS challenge. I wanted to animate pieces around the game board after a player made a move. After a fair bit of googling React animation libraries (This is a great source for animation options), I decided that my use case combined with my desire to make peace with CSS meant I was going the full CSS route. This was no simple task for me so I thought I'd share what I learned.

TL;DR

The high-level view of my approach is to have resources animate into new components when the user clicks on them. To achieve this I have the resources render in the new component with a state change and force them back into their original position with CSS, then animate them into their new position. If you just want to get down to the code and see the results, you can check out the code pen or see the full code at the end of the article.

Set Up

I pared down the problem as best I could to make it bite-sized. Here is the basic boilerplate code of the pre-animated situation.



//App.js
const FarmFig = ({ image, handleClick=null, setRef }) => {
  return (
      <img className="image" src={image} ref={setRef} onClick={handleClick} />
  );
};

class App extends React.Component {
  constructor(){
    super()
           this.center = React.createRef();
  this.state = {
    this.state = {
      images: {
        tl:
          "https://lh3.googleusercontent.com/proxy/YSIR4H4fU2Tf5vmbmeixy6m6ZcTXvS9wEo8q4gxOiqEg8XXPod1ZaGJbc8-wngYJwkR6QHEfjvO3w4QogZJqVH5nJjhJaMk",
        c:
          "https://lh3.googleusercontent.com/proxy/29-YDS42UPIZNuPicKnpkmh2sw_th3Sa41d6iiGT8XH1vXfjfpNgUCK1-CxlMlT40eaJP25ylJ8IRUiCEBwTfIyuBB8izJ8",
        br:
          "https://pngarchive.com/public/uploads/small/11559054782q4dsokodad1svijk1zzlyrjdwtmlygkkaxxvooeqevdyrbomu3b5vwcwst0ndcidr89gdf0nyleyffoncphgazeqmnpmdubfypow.png",
      },
  }
} 
handleClick = ({target}) => {
  this.setState(prevState => {
      //switch clicked image with the center image
         if (prevState.images.tl === target.src) {
           prevState.images.tl = prevState.images.c;
           prevState.images.c = target.src
         } else {
           prevState.images.br = prevState.images.c;
           prevState.images.c = target.src
         }
         return {images: prevState.images}
       })
     }

          render() {
            const{tl, c, br} = this.state.images
            return (
              <div className="container">
                <div className="top-left">
                  <FarmFig image={tl} handleClick={this.handleClick}/>
                </div>
                <div className="container">
                  <FarmFig image={c} setRef={this.center} />
                </div>
                <div className="bot-right">
                  <FarmFig image={br} handleClick={this.handleClick} />
                </div>
              </div>
            )
          }
        }



/* css */
.container {
  display: flex;
  flex-direction: row;
  justify-content: space-between;
  align-items: center;
  justify-content: center;
  height: 90vh;
  width: 100%;
}
.top-left {
  align-self: flex-start;
  transform: rotate(180deg)
}
.bot-right {
  align-self: flex-end;
}
.image {
  width: 175px;
}

So far, pretty basic set up. We have three images: top-left, center, and bottom-right. When we click on either the top-left or bottom-right images we trigger a state change that swaps the clicked and center images. We also included a ref to the center image, we'll use that soon. Now to animate this transition.

Adding animation

In order to animate the images, we first need to add a few items to state.



this.state = {
      images: {
        tl:
          "https://lh3.googleusercontent.com/proxy/YSIR4H4fU2Tf5vmbmeixy6m6ZcTXvS9wEo8q4gxOiqEg8XXPod1ZaGJbc8-wngYJwkR6QHEfjvO3w4QogZJqVH5nJjhJaMk",
        c:
          "https://lh3.googleusercontent.com/proxy/29-YDS42UPIZNuPicKnpkmh2sw_th3Sa41d6iiGT8XH1vXfjfpNgUCK1-CxlMlT40eaJP25ylJ8IRUiCEBwTfIyuBB8izJ8",
        br:
          "https://pngarchive.com/public/uploads/small/11559054782q4dsokodad1svijk1zzlyrjdwtmlygkkaxxvooeqevdyrbomu3b5vwcwst0ndcidr89gdf0nyleyffoncphgazeqmnpmdubfypow.png",
      },
      animate: true,
      transition: {
        center: {
          startTop: 0,
          startRight: 0,
        },
        corner: {
          farmItem: null,
          startTop: 0,
          startRight: 0,
        },
      },
    };

We've added a transition object to keep track of the adjusted starting position of the images after they re-render. Remember, we are going to render the swapped images in their new components and move them to look like they are still in their original positions then animate them to their new location.

Next, we need to calculate these adjusted starting positions after we click on an image. This will be done in our handlClick function.



 handleClick = ({ target }) => {
    // find location of clicked image
    const imageStartTop =
      target.getBoundingClientRect().top + document.documentElement.scrollTop;

    const imageStartRight =
      target.getBoundingClientRect().right +
      document.documentElement.scrollLeft;

    //find ending location of clicked image
    let endLoc = this.getCenterLoc();
    let selectedImage;
    this.setState((prevState) => {
      if (prevState.images.tl === target.src) {
        // Swap the selected and center images
        selectedImage = "tl";
        prevState.images.tl = prevState.images.c;
        prevState.images.c = target.src;
      } else {
        selectedImage = "br";
        prevState.images.br = prevState.images.c;
        prevState.images.c = target.src;
      }
      return {
        images: prevState.images,
        // We set animate to false to temporarily to allow images to relocate
        animate: false,
        transition: {
          center: {
            // y distance in px the center image needs to move
            startTop: imageStartTop - endLoc[0],
            // x distance in px the center image needs to move
            startRight: imageStartRight - endLoc[1],
          },
          corner: {
            farmItem: selectedImage,
            // y distance in px the clicked image needs to move
            startTop: endLoc[0] - imageStartTop,
            // y distance in px the clicked image needs to move
            startRight: endLoc[1] - imageStartRight,
          },
        },
      };
    });
     // Wait briefly then change the animation flag to trigger a re-render and the animation. 
    setTimeout(() => this.setState({ animate: true }), 200);
  };

where:



getCenterLoc = () => {
    const imageEndTop =
      this.center.current.getBoundingClientRect().top +
      document.documentElement.scrollTop;

    const imageEndRight =
      this.center.current.getBoundingClientRect().right +
      document.documentElement.scrollLeft;
    return [imageEndTop, imageEndRight];
  };

There's a lot going on here, but at the end of the day, it's just a cumbersome subtraction problem. We use the ref on the center image and the event target of the click to get the position of clicked and center image relative to the viewport. element.getBoundingClientRect() gives the coordinates of element relative to the document and adding document.documentElement.scrollTop accounts for any offset in the document if the page is scrolled. Then we set our state with the difference between the center image and the selected image.

After this, we use a setTimeout call to wait briefly before changing the animate flag in state and triggering the animation.

Now when we need to apply these new locations to the appropriate images when they are clicked. In our render method, we will add a ternary checking our this.state.animate property



const animClass = this.state.animate ? "force-move" : "";

Then we can pass this new class, along with our adjusted locations down into the appropriate FarmFig components, and make the following updates to FarmFig and to our CSS file.



const FarmFig = ({ image, handleClick = null, setRef, locs, animClass }) => {
  return (
        <img
          className={`image ${animClass}`}
          src={image}
          ref={setRef}
          onClick={handleClick}
          style={{
          transform: `translate(${locs[1]}px, ${locs[0]}px)`,
        }}
        />
  );
};



.force-move {
    transition: transform 1s;
    transition-delay: 1s;
    transform: translate(0, 0) !important;
  }

Whew... We finally have some moving animations!!!!

This is great, except... I originally needed animations to move pieces around a space, not through it. Unfortunately, CSS doesn't support putting delays between multiple types of transforms on the same object. My solution to this is to add some bonus divs around the FarmFig img and transform each of those with timed delays (This definitely feels a bit hacky, anyone have a better idea?)

Finally updating our FarmFig and CSS files accordingly:



<div
      className={`${animClass}X`}
      style={{
        transform: `translate(${locs[1]}px`,
      }}
    >
      <div
        className={`${animClass}Y`}
        style={{
          transform: `translateY(${locs[0]}px)`,
        }}
      >
        <img
          className={`image`}
          src={image}
          ref={setRef}
          onClick={handleClick}
        />
...



.force-moveX {
    transition: transform 1s;
    transform: translate(0) !important;
  }
  .force-moveY {
    transition: transform 1s;
    transition-delay: 1s;
    transform: translateY(0) !important;
  }

and voila!

Wrap-up

Building out custom animations in React using just CSS is undeniably cumbersome and requires a fair bit of code. It is certainly not for every situation. However, if you want to limit how many libraries your project relies on, have a unique use case, or have decided it's finally your time to face CSS it can certainly be done. Hope this is helpful, let me know if I totally screwed something up!

Full Code

CodePen

Code



// App.js
const FarmFig = ({ image, handleClick = null, setRef, locs, animClass }) => {
  return (
    <div
      className={`${animClass}X`}
      style={{
        transform: `translate(${locs[1]}px`,
      }}
    >
      <div
        className={`${animClass}Y`}
        style={{
          transform: `translateY(${locs[0]}px)`,
        }}
      >
        <img
          className={`image`}
          src={image}
          ref={setRef}
          onClick={handleClick}
        />
      </div>
    </div>
  );
};

class App extends React.Component {
  constructor() {
    super();
    this.center = React.createRef();
    this.state = {
      images: {
        tl:
          "https://lh3.googleusercontent.com/proxy/YSIR4H4fU2Tf5vmbmeixy6m6ZcTXvS9wEo8q4gxOiqEg8XXPod1ZaGJbc8-wngYJwkR6QHEfjvO3w4QogZJqVH5nJjhJaMk",
        c:
          "https://lh3.googleusercontent.com/proxy/29-YDS42UPIZNuPicKnpkmh2sw_th3Sa41d6iiGT8XH1vXfjfpNgUCK1-CxlMlT40eaJP25ylJ8IRUiCEBwTfIyuBB8izJ8",
        br:
          "https://pngarchive.com/public/uploads/small/11559054782q4dsokodad1svijk1zzlyrjdwtmlygkkaxxvooeqevdyrbomu3b5vwcwst0ndcidr89gdf0nyleyffoncphgazeqmnpmdubfypow.png",
      },
      animate: true,
      transition: {
        center: {
          startTop: 0,
          startRight: 0,
        },
        corner: {
          farmItem: null,
          startTop: 0,
          startRight: 0,
        },
      },
    };
  }
  getCenterLoc = () => {
    const imageEndTop =
      this.center.current.getBoundingClientRect().top +
      document.documentElement.scrollTop;

    const imageEndRight =
      this.center.current.getBoundingClientRect().right +
      document.documentElement.scrollLeft;
    return [imageEndTop, imageEndRight];
  };

  handleClick = ({ target }) => {
    // find location of clicked image
    const imageStartTop =
      target.getBoundingClientRect().top + document.documentElement.scrollTop;

    const imageStartRight =
      target.getBoundingClientRect().right +
      document.documentElement.scrollLeft;

    //find location of ending location
    let endLoc = this.getCenterLoc();
    let selectedImage;
    this.setState((prevState) => {
      if (prevState.images.tl === target.src) {
        selectedImage = "tl";
        prevState.images.tl = prevState.images.c;
        prevState.images.c = target.src;
      } else {
        selectedImage = "br";
        prevState.images.br = prevState.images.c;
        prevState.images.c = target.src;
      }
      return {
        images: prevState.images,
        animate: false,
        transition: {
          center: {
            startTop: imageStartTop - endLoc[0],
            startRight: imageStartRight - endLoc[1],
          },
          corner: {
            farmItem: selectedImage,
            startTop: endLoc[0] - imageStartTop,
            startRight: endLoc[1] - imageStartRight,
          },
        },
      };
    });
    setTimeout(() => this.triggerAnim(), 200);
  };

  triggerAnim = () => {
    this.setState({ animate: true });
  };

  getOldLoc = (loc) => {
    const { corner } = this.state.transition;
    let top, right;
    if (corner.farmItem === loc) {
      top = corner.startTop;
      right = corner.startRight;
    } else {
      top = 0;
      right = 0;
    }
    return [top, right];
  };

  render() {
    const { tl, c, br } = this.state.images;
    const { center } = this.state.transition;
    const animClass = this.state.animate ? "force-move" : "";
    return (
      <div className="container">
        <div className="top-left">
          <FarmFig
            image={tl}
            handleClick={this.handleClick}
            locs={this.getOldLoc("tl")}
            animClass={animClass}
          />
        </div>
        <div className="center">
          <FarmFig
            image={c}
            setRef={this.center}
            locs={[center.startTop, center.startRight]}
            animClass={animClass}
          />
        </div>
        <div className="bot-right">
          <FarmFig
            image={br}
            handleClick={this.handleClick}
            locs={this.getOldLoc("br")}
            animClass={animClass}
          />
        </div>
      </div>
    );
  }
}



\* css *\
.container {
    display: flex;
    flex-direction: row;
    justify-content: space-between;
    height: 90vh;
    width: 100%;
  }
  .center {
    align-self: center;
  }
  .top-left {
    align-self: flex-start;
  }
  .bot-right {
    align-self: flex-end;
  }
  .image {
    width: 150px;
    height: 130px;
  }

  .force-moveX {
    transition: transform 1s;
    transform: translate(0) !important;
  }
  .force-moveY {
    transition: transform 1s;
    transition-delay: 1.5s;
    transform: translateY(0) !important;
  }

Performance tradeoffs of querySelector and querySelectorAll

wlytle — Sun, 29 Nov 2020 23:41:20 +0000

I recently became curious about the subtle differences in use and performance between the various methods of accessing the DOM in Javascript. Here I'm going to take a look at getElementById, querySelector, getElementsByClassName, getElementsByTagName, and querySelectorAll and try to sort out the differences. Perhaps the most obvious difference is that querySelector and querySelectorAll accept a wide range of search terms and can be far more precise than the other functions. While each of the other functions is a specialist (they only search by one selector) querySelector and querySelectorAll can make use of all of the fancy CSS selecting magic; check out this article for a more complete list.

Single Element Search

Let's begin with the functions that only return a single element from the DOM: getElementById, querySelector. Both of these functions return the HTML element matching the given search term or null if no there is no matching element in the DOM. getElementById will return the one element with the provided ID and querySelector will return the first node it finds that matches the search criteria. Let's take them for a spin and see which is faster!



<div id="div1"></div>



// use querySelector 5 million times and time it
 function querySelectorLoop() {
  let t0 = console.time("querySelector");
  for (let i = 0; i < 5000000; i++) {
     document.querySelector("#div1");
  }
  let t1 = console.timeEnd("querySelector");
}

// use getElementById 5 million times and time it
function getByIdLoop() {
  let t0 = console.time("getElementById");
  for (let i = 0; i < num; i++) {
    const query = document.getElementById("div1");
  }
  let t1 = console.timeEnd("getElementById");
}

querySelectorLoop();
// => querySelector: 653.566162109375 ms

getByIdLoop();
// => getElementById: 567.281005859375 ms

(Note: All tests were done on Chrome version 87.0.4280.67 non-reported tests were also done on safari with similar results.)

Well, that settles it, querySelector is slower than getElementById.... sort of. It took querySelector about 86ms longer to access the DOM 5 million times. That is not a lot of time. The reason for the discrepancy is likely because many browsers cache all of the ids when the DOM is first accessed and getElementById has access to this information while querySelector performs a depth-first search of all nodes until it finds what it's looking for. This suggestss that searching for a more complexly nested HTML element might increase the performance discrepancy.

Multiple Element Search

Before we investigate getElementsByClassName, getElementsByTagName, and querySelectorAll we need to talk about what each of these functions returns. getElementsByClassName, getElementsByTagName, each return an HTML Collection and querySelectorAll returns a Node List. These are both array-like, ordered, collections of values. They both have a length method and can be accessed via numbered indices. The major difference between an HTML Collection and a Node List is that an HTML Collection is a Live collection while a Node List is not. A live collection accurently reflects the current state of the DOM, while a not-live collection serves a snapshot. For example:



<ul>
  <li id= "first-li" class=list> Cheddar </li>
  <li class=list> Manchego </li>
  <li class=list> gruyere </li>
</ul>



let htmlCollection = document.getElementsByClassName("list");
let nodeList = document.querySelectorAll(".list");
htmlCollection.length // => 3
nodeList.length // => 3

// Remove the first li
document.getElementById("first-li").remove();
// Re-check lengths
htmlCollection.length // => 2
nodeList.length // => 3

As we can see the HTML Collection made with getElementsByClassName was updated simply by updating the DOM while our Node List remained static.

Now let's see how our functions measure up on speed.



<div id="div1"></div>



// Make a div to hold newly created elements
const div = document.createElement("div");
let p;
// Create 5,000 new <p></p> elements with class="p" and append them to a div.
  for (let i = 0; i < 50000; i++) {
    p = document.createElement("p");
    p.className = "p";
    div.appendChild(p);
  }

// Append our 5,000 new p elements in a div to our existing div on the DOM
const oldDiv = document.getElementById("div1");
oldDiv.appendChild(div);

// Time getElementsByClassName creating an HTML Collection w/ 5,000 elements
function getByClass() {
  let t0 = console.time("Class");
  for (let i = 0; i < 5000; i++) {
    document.getElementsByClassName("p");
  }
  let t1 = console.timeEnd("Class");
}

// Time getElementsByTagName creating an HTML Collection w/ 5,000 elements
function getByTagName() {
  let t0 = console.time("Tag");
  for (let i = 0; i < 5000; i++) {
    document.getElementsByTagName("p");
  }
  let t1 = console.timeEnd("Tag");
}

// Time querySelectorAll creating an Node List w/ 5,000 elements
function getByQuery() {
  let t0 = console.time("Query");
  for (let i = 0; i < 5000; i++) {
    document.querySelectorAll("p");
  }
  let t1 = console.timeEnd("Query");
}

// Now run each function
getByQuery(); // => Query: 458.64697265625 ms
getByTagName(); // => Tag: 1.398193359375 ms
getByClass();// => Class: 2.048095703125 ms

Now there's a performance difference!

So what's going on here? It all has to do with the difference between Node Lists and HTML Collections. When a Node List is made each element is collected and stored, in order, in the Node List; this involves creating the Node List then filling it up within a loop. Whereas the live HTML Collections are made by simply registering the collection in a cache. In short, it's a trade-off; getElementsByTagName and getElementsByClassName have very low overhead to generate but have to do all of the heavy lifting of querying the DOM for changes every time an element is accessed (More detailed info about how this actually done here). Let's run a quick experiment to see this. This is pretty simple to do if we modify our code above to have return values.



//modifying the above functions to return collections like so...
...
return document.getElementsByClassName("p");
...
return document.getElementsByTagName("p");
...
return document.querySelectorAll("p");
...
// Assigning the returns to variables 
const queryP = getByQuery();
const tagP = getByTagName();
const classP = getByClass();

// See how long it takes to access the 3206th element of each collection
console.time("query");
queryP[3206];
console.timeEnd("query");// => query: 0.005126953125 ms

console.time("tag");
tagP[3206];
console.timeEnd("tag");// => tag: 0.12109375 ms

console.time("class");
classP[3206];
console.timeEnd("class");// => class: 0.18994140625 ms

As expected accessing an element fromquerySelectorAll is much faster - accessing an element fromgetElementsByTagName and getElementsByClassName is nearly 100 times slower! However, being 100 times slower than something really fast isn't necessarily slow, a tenth of a millisecond is hardly something to complain about.

Wrapping It Up

querySelector and querySelectorAll are both slower than other functions for accessing the DOM when they are first called; although querySelector is still not slow. querySelectorAll is much faster than getElementsByTagName and getElementsByClassName when accessing a member of the collection because of the differences in how live and non-live collections are stored. But again, getElementsByTagName and getElementsByClassName are not slow.

So which selectors to use? That will depend on your particular use case. The querySelector functions are much more versatile and have the ability to be far more precise but it may come with a performance cost and some situations are more suited for live collections than others.

Ruby's gsub method: What, Why, & How

wlytle — Sat, 07 Nov 2020 15:05:17 +0000

If you are like me and possess an incomplete understanding of regular expressions (regex), then trying to read the documentation on string manipulation might have left you pulling your hair out. It often feels like these resources are written entirely in regex, and if you left you Rosetta Stone in your other wallet, you may find yourself befuddled. This post will dive mainly into Ruby's gsub method. However, because gsub gets a lot of power from regex, this post will use regex and I will explain it when used. For more detailed regex information, check out these great resources:

gsub... What?

Okay, what is gsub? It's a string manipulation method in Ruby; the g stands for global and the sub stands for substitution. Put simply, gsub looks through a string for a pattern and replaces it with another pattern, and then returns the modified string. It should be noted that Ruby has a sub method that performs the same task on only the first pattern that matches the search pattern. Both gsub and sub are non-destructive; to modify the original, string ruby offers gsub! and sub!. gsub operates as a method with 2 arguments or as an enumerable:

string.gsub(search_pattern, replacement)
# or
string.gsub(search_pattern) do |sp| 
  #do something fancy with each found search_pattern
end

For both arguments gsub accepts strings (stuff in-between ' ' or " ") or regex (for Ruby purposes regex need always be contained between / /).

gsub... Why?

Why bother with gsub? Well, because the world is messy and, by extension, so is data. Let's say you're collecting phone numbers from a database that didn't properly validate their data format and every so often you get 123.456.7899 or (123)456-7899 instead of 1234567899. Wouldn't it be nice to let ruby find and fix this for you rather than waiting for your program to crash and then manually re-formatting? I for one, say yes!

gsub... How?

Alright, now we're down to the good stuff. How do I make Ruby do all of my string related bidding? First the case of a simple string substitution.

"cheese".gsub('e', '3')
# => "ch33s3"
"cheese".gsub(/[^e]/, '3')
# => "33ee3e"

The regex [^e] simply means "all the things that aren't e". With this first use case, we already have the ability to fix our phone number format.

phone_number = '(123)456-7899' 
phone_number.gsub(/[()-.]/,'')
# => "1234567899"

This bit: [()-.] is looking for any of the symbols within the brackets, which gsub then replaces with nothing!

Let's say you have some string data that contains prices, but you are expanding your market to Japan. Whatever will you do? gsub to the rescue!

data = 'Plane tickets are $200'
conversion = 104.72 # yen/dollar according to google at time of writing
data.gsub(/\d+/) { |char| char.to_f * conversion }
# => "Plane tickets are $20944.0"

You're probably thinking, "okay the number is correct but it still says dollars so... not super helpful". That's fair, if only there was some way to swap one character for another, hmm... gsub to the rescue again! We can take advantage of method chaining.

data.gsub(/\d+/) { |char| (char.to_f * conversion) }.gsub('$','¥')
# => "Plane tickets are ¥20944.0"

Ruby is looking for all collections of one or more digits (\d+) and converting each of those to a float, then multiplying them by our conversion faction. After it has done this with all digits, the resulting string gets passed to another gsub and has all $ replaced with ¥.

This is all well and good, but by now you must be wondering, "will gsub help me pretend to be a spy?" Yes... Yes, it can!

As a second argument gsub can also take a hash. If any of the matched patterns from the first argument exist as keys of the hash they will be swapped out for the corresponding value. It's like a super-secret decoder ring!

substitutions = {
  'a' => '@',
  'e' => '3',
  'i' => '!',
}
phrase = 'I am hiding and I have come for your cheese'
phrase.gsub(/[aei]/, substitutions)
# => "I @m h!d!ng @nd I h@v3 com3 for your ch33s3"

The regex here, [aei] is just matching each of those characters individually. Notice that the capital I's were unchanged, both because we were only searching for lower case letters but also because our substitutions hash doesn't have an I key even if it were included in our search.

One more gsub use case to explore before we part ways. By putting search terms in parenthesis we can group them, then reference those groups to perform specific manipulations. The grouped patterns must be found adjacent to each other, otherwise gsub will just return the original string.

phrase = "cheese"
phrase.gsub(/(h)([e]+)/, '{\1}<\2>')
# => "c{h}<ee>se"

In our search pattern, we look first for h then more than one e [e]+ we can then reference these groups by the order '\d' where d is the number of the group from the left. Group numbers can be a bit tricky to figure out so here's one more example:

phrase.gsub(/(h)([e]+)(k)([0-9])([^aeiou])/...

Here h is the first group and would be referenced '\1', [e]+ is the second, '\2' and so on until [^aeiou] which would be group 5 referenced as '\5'. It should also be noted that when referencing groups it's better to use single quotes because double quotes will escape the backslash.

We can also give the groups names to reference like so:

phrase = "cheese"
phrase.gsub(/(?<h>h)(?<es>[e]+)/, '{\k<h>}<\k<es>>')
# => "c{h}<ee>se"

Group names are assigned by (?<group_name>search_term) and are referenced by \k<group_name>. We can do some other fun manipulations this way. For instance, we can rearrange terms, just in case we need to generate some Pig Latin.

phrase = "cheese"
puts phrase.gsub(/([^aeiou]+)(\w+)/, '\2\1ay')
# => "eesechay"

This looks for one or more consonants [^aeiou]+. This becomes group \1. Then it looks for one or more word characters \w+, which becomes group \2. It then switches the order of the groups and adds ay! Note: This will only Pig Latin-ify individual words that don't start with a vowel.

Wrap Up

Hopefully, this has demystified one of Ruby's more powerful string manipulation methods. A lot of fancy stuff can be done with gsub even without regex although learning some regex will kick it up a notch.

What's up with the & in Ruby and some background on procs

wlytle — Thu, 22 Oct 2020 02:29:59 +0000

Scrolling through API docs and Stack Overflow threads on Ruby inevitably reveals a number of unexplained &s floating around. Being new to Ruby and engineering in general, I thought I'd dig into what the ampersand, known as the safe operator, is and does.

The safe operator calls .to_proc on whatever it proceeds. But what, praytell, is a proc and what does it mean to become one? Before we get into &, we have to briefly fall down the rabbit hole of the Proc class.

Procs

On the surface, this isn't too terribly complicated. An instance of the Proc class is simply an executable block of code that can be stored in a variable to be called later or even passed as an argument to a method. A block of code is a grouping of statements called by a method. It is surrounded by { } or the do end keywords; think about what comes after .each.

cube = Proc.new { |i| i**3 }
cube.call(2)
# => 8

Note the .call method needed to call the proc instance which can also be accomplished with the shorthand cube.(2) or cube[2].

As mentioned, procs can also be used to pass a block as an argument of a method.

def i_take_a_proc(proc_arg)
  proc_arg.call
end
proc_arg = Proc.new { puts "I'm a block being passed as an argument!" }
i_take_a_proc(proc_arg)
# => I'm a block being passed as an argument!

Now we can take this new (micro)superpower and apply the safe operator. Remember the safe operator simply calls .to_proc on its operand.

def make_proc(&block)
  block
end
hello = make_proc { |i| puts "#{i} says hello!" }
hello.call("The Moon")
# => The Moon says hello!

When Ruby sees the &, it expects a proc to follow. Since we provide a block, Ruby will try to coerce it into a proc by calling .to_proc on the block.

Special Behaviors of Procs

Now that we have a handle on what procs are, let's talk about some of the properties that make them such beautiful and unique snowflakes. First off, procs (and blocks) are a type of closure, meaning that they remember the environment in which they are created. They essentially form a snapshot of the variables in their scope and will use that snapshot when they are called even if those variables have been reassigned.

def run_proc(say_hi)
  hi = "Hello"
  say_hi.call
end
hi = "Hola"
say_hi = Proc.new { puts hi }
run_proc(say_hi)
# => Hola

This will puts Hola to the screen NOT Hello because that was the value of the hi variable that our new proc had access to when it was created and - because procs are closures - it holds onto that assignment of the variable.

Another interesting feature of procs is how they handle an explicit return. Rather than simply returning from their own block they will return from the surrounding context as well.

proc_that_returns = Proc.new { return "I'm Free!" }
proc_that_returns.call

Running this code outside of a method will produce a LocalJumpError because it is trying to return out of the top-most context.

Finally, procs are surprisingly laidback objects in the Ruby world. They are comfortable ignoring nil values and are not picky about the number of arguments they are given.

proc_with_two_args = Proc.new { |x, y| x.even? }
proc_with_two_args.call(6) 
=> true

This proc expects two arguments: |x, y|. Even though it only receives one, no ArgumentError is raised!

Lambdas, Briefly

It's hard to dive into procs without talking about lambdas, but I'm here to talk about the safe operator so I'll make it quick. A lambda is a type of proc with slightly different behaviors. Namely, they do not return out of the surrounding scope with an explicit return, and they are particular about the number of arguments they accept. That's all!

lambda_with_two_args = lambda { |x, y| x.even? }
lambda_with_two_args.call(6) 
=> ArgumentError

The Safe Operator, Finally

So, what does this all mean for our friend the safe operator, &? Well, using what we now know, we can employ it to the benefit of some nice syntactic sugar.

This is most commonly seen when & is called on a symbol in the argument of an enumerator.

animals = ["dog", "platypus", "scarab"]
animals.map(&:length)
=> [3, 8, 6] 
#This is equivalent to: animals.map {|animal| animal.length}

This is a neat trick, but what's going on here? Well, the safe operator indicates that Ruby expects a proc to follow it. Instead, it finds a symbol (:length) so it calls to_proc on the symbol, resulting in something like this:

{ |a| a.send(self) }

In this case, self is the symbol :length, so Ruby calls the length method on the object that is calling (&:length). To be fair, this is likely a gross oversimplification of what is actually going on, but it helps clear things up a bit.

Another bit of syntactic wizardry the safe operator offers is a kind of failsafe. Because the safe operator is comfortable with missing arguments and nil data, it can be used when nil data may be present and you don't want it to break your code.

array = [1, 2, 3, nil, 5]
array.map { |e| e.even? }
=> NoMethodError
array.map { |e| e&.even? }
[false, true, false, nil, false]

This is a bit cleaner than writing lengthy if statements to check if all your data exist before using it. That said, it should be used carefully if having nil values in your data will be a major problem later. It can also be used when chaining method calls together. The safe operator will return nil when it finds the first nil object.

 #No safe operator :(
if genre && genre.artist && genre.artist.album
...
end
#With safe operator
if genre&.artist&.album
...
end

Wrap up

Safe operators and procs may not change your life or even your code, but they can clean things up a bit. At the very least, they make it look like you know what you're doing (maybe not always a good thing).

Forem: wlytle

Passing variables and objects in Javascript: Reference compared to Values

Motivation

Reference Vs. Value

Importance for Recursion

Final thoughts

Implementing a Searchable, Async Dropdown in React

Motivation

TLDR

Installation

Usage

A Short Digression About Data

Props

onInputChange

loadOptions

onChange

Bonus props

getOptionLabel and getOptionValue

isMulti

cacheOptions

Animations!

Putting It All Together

Animating Content Between Components in React

TL;DR

Set Up

Adding animation

Wrap-up

Full Code

CodePen

Code

Performance tradeoffs of querySelector and querySelectorAll

Single Element Search

Multiple Element Search

Wrapping It Up

Ruby's gsub method: What, Why, & How

gsub... What?

gsub... Why?

gsub... How?

Wrap Up

What's up with the & in Ruby and some background on procs

Procs

Special Behaviors of Procs

Lambdas, Briefly

The Safe Operator, Finally

Wrap up

`getOptionLabel` and `getOptionValue`

`isMulti`

`cacheOptions`