DEV Community: Sergio B

On the Virtues of RegExp in JS

Sergio B — Mon, 15 Aug 2022 03:01:06 +0000

When it comes to regex, I have a disproportionate amount of love for the lil' fella. Much like a tire iron clanking around in the trunk of your car, or a corkscrew in the back of the silverware drawer, it only truly shines when you find yourself desperately needing it. I recently found myself looking to implement a search function in a React app and would like to share how you can make one that works as snappy, effectively, and easily as mine.

The Old Way

A while ago I had an assignment that featured a search bar that utilized the classic .startsWith() method to determine which entries to display on a page.

In the background, it utilized state that was derived from a user-input search field. Using this, it compared the item description with a lowercase version of the user input (for uniformity) and then the aforementioned startsWith() to get back entries beginning with the supplied search.

And yeah sure, it works, but what if the item doesn't startsWith free? What if the people posting on Gregory's list weren't at 100% that day and they wrote dfree braun 3735 elemtric tothbrush ? Or what if the word free wasn't the first word? What then?

I could've sworn I saw a guy selling these.

The RegEx Way

Long story short, there's a way to make a better and cleaner search method, if you're willing to learn a little regex. Here's an altered version using an implementation I discovered while working on a search field for a project of my own.

And the result.

There it is!

As you'll notice, this doesn't start with "Braun" at all. As a matter of fact...

Some of this stuff ended with free. So what gives? Is regex magic?

Yes.

The .search() method in JavaScript will search through a string using a regular expression (or a string that gets converted to a regular expression) and return the index of where it finds a match, or -1 if there's no match. Hence comparing the final return to see if it is positive.

The RegExp object in JS allows you to create a new regular expression based on a string you hand it, alongside a second argument in the form of a string of optional flags. Here, I used interpolation to set the string the regular expression will look for alongside the special i flag to designate case-insensitive matching. This results in a regex equivalent of /{user search}/i.

So why not just interpolate directly inside of the .search() and save the hassle of messing around with a new Object?

Because I DO NOT recommend mucking about with back and forward slashes to make interpolation work inside a standard regex. Seriously, regex takes things very literally and $ , { , and } are all reserved characters.

/tl;dr/i

Regular Expressions are cool as heck and have lots of potential applications with searches being just the tip of the iceberg. For more information, I highly recommend RegexOne, the place I learned everything I know about RegEx.

Intro to useRef hook

Sergio B — Mon, 04 Jul 2022 04:22:45 +0000

In the course of working on a project for Flatiron School, I stumbled upon a use case for a React hook that I had yet to encounter. It was actually in compiling my code that my console suggested the useRef hook and I'd like to show how it solved my problem.

A < div /> in Motion

The central idea behind my project involved getting a div element to "bounce" off a boundary and come back. I initially used a combination of useState and useEffect to achieve this within the component I intended to bounce.

Because I needed to actually re-render the component to reflect where its calculation had moved it to, I needed to nest a setInterval() inside a useEffect hook. The reason I am returning a cleanup function here to clear my clock interval is because without it, a new setInterval would be created on every state change until they all piled up and updated the component's position wayyy too many times.

The bouncer at the start of its journey.

Everything seemed fine with this approach until I got to a point where multiple state changes need to happen synchronously. Here's what happens when this code reaches the boundary condition at 93 viewport width units:

As you can see, it's just running into the wall over and over (much like myself trying to fix this problem).

After console.logging extensively and reviewing state, I localized the problem to my state variable for the current direction of my component (xSpeed) not being able to change fast enough to accurately change the value of my xPosition state. So when the variables become unsynced due to not having updated together as they should've, xSpeed is constantly flipped due to xPosition being on the right side of the boundary, a place I hadn't considered possible to reach.

Another thing about the way I implemented my bouncing div is that state was constantly updating, which is a lot of re-rendering. In attempting to fix this without useRef, I managed to cause my first infinite re-render loop. I could've reworked the way I assigned the value for state or just made one state calculable from the other by perhaps refactoring my whole code for this, but the error I got from running this on a development server actually suggested the useRef hook as a fix.

When is a State Not a State?

So what does useRef do to remedy this? Well, to put it in an overly simplistic way, it offers a way to make a state variable that can be updated without triggering a re-render. Here's the changed section of my code with the useRef hook instead of another state.

Note how I am still re-rendering through useEffect with the position of my bouncing div.

useRef creates an object with a special property under the object's .current key. This key has a value that you can set to whatever you like, just like useState, but this property is readable just like a variable you're used to in JavaScript. In my implementation of it, it means that when I update this div's speed to -1, I am immediately able to access xSpeed.current's new value and subtract 1 from my xPosition state. This fixes my logic and reduces the number of re-renders needed.

And now we get a proper bounce!

TL;DR

So, if you ever need to have a variable stored in a component like a state, but you don't want to re-render every time you re-assign the value of that variable, consider useRef. If you ever need to reassign state and aren't patient enough to wait for a re-render before accessing that new state for another statement, definitely consider useRef.

Array and Object Manipulation + DOM differences

Sergio B — Thu, 19 May 2022 01:39:53 +0000

For too long (about a few weeks), I have second guessed myself every time I've started writing a For... loop. Here, I will show you how to know which one you should use for the task at hand, what can happen when you choose the wrong one, and how this extends to DOM elements.

For... of

When handling arrays of data, using a For...of loop is a great option.

Every time the loop is entered here, a new entry from the array is loaded into the value of i. The first console.log here will show i as being equal to the value of array[0], or 'apple'. The second as 'banana' and so on. Note that i is not equal to the index value of the item.

For... in

Now for objects, a For...in loop is what you want to use. I like to imagine that I'm looking inside of the object to see all the keys and values.

For this type of loop, every time i is reassigned, it gets a new key. Now, let's change our objectLogger function to see if we can view the values instead.

By choosing to log object[i] instead of i, we can see every value in our object. So by using this type of loop, we can gain complete insight into every key:value pair in our object. An important thing to keep in mind when accessing objects like this is to NOT use dot notation and instead use the computed member access operator, aka brackets, for getting object properties. In this function, attempting to console.log object . i results in an undefined error as JavaScript tries to look through the object for a key literally called i.

What happens if we forget?

In the case of trying to treat an object as if it were an array, disastrous consequences will immediately occur and your IDE will make that clear as soon as you try to run the code.

arrayLogger(animalObject)
// will return the following:
index.js:6 Uncaught TypeError: array is not iterable
    at arrayLogger (index.js:6:25)
    at HTMLDocument.<anonymous> (index.js:24:5)

However, in the case of treating an array as an object, something interesting happens.

objectLogger(fruitArray)
//=> apple, banana, cantaloupe

You are actually able to treat an array as an object in JavaScript, because it is a subtype of object.

Check it out:

console.log(typeof fruitArray)
//=> object
console.log(typeof animalObject)
//=> object

Interesting. This is also why it is also a terrible idea to use the typeof operator to distinguish between an array and an object.

DOM Elements and Notes on Handling Them

After some experimentation on a beautiful HTML page, I've been able to get a better handle on what exactly happens when putting together a collection of HTML/Node elements.

The relevant portion of my test HTML file.

I'll spare you the eye-searing entirety of the output.

So let's see what happens when we gather the elements up in HTML collection form.

const divItems = document.getElementsByTagName('div')
console.log(divItems)
//=> HTMLCollection(7) [div, div, div, div, div, div, div]
for (const i of divItems) {
    console.log(i)
}
// will output :
 //   <div>Hey</div>
 //   <div>it's</div>
 //   <div>a</div>
 //   <div>whole</div>
 //   <div>bunch</div>
 //   <div>of</div>
 //   <div>divs!</div>

Okay, so this HTML collection is a type of array. But what if we handle it like an object?

for (const i in divItems) {
    console.log(i)
}
// will output the following (numbers on one line for readability)
// 0, 1, 2, 3, 4, 5, 6
// length
// item
// namedItem

Whoa, secret properties. So this is why an HTML collection is a bit more substantial than a mere array. But let's get into the far superior querySelectorAll to see why I make that claim in the first place.

const divList = document.querySelectorAll('section div')
console.log(divList)
//=> NodeList(7) [div, div, div, div, div, div, div]
for (const i of divItems) {
    console.log(i)
}
// will output :
 //   <div>Hey</div>
 //   <div>it's</div>
 //   <div>a</div>
 //   <div>whole</div>
 //   <div>bunch</div>
 //   <div>of</div>
 //   <div>divs!</div>

Alright so far, pretty much the same. Except it's called a NodeList. Whatever, right? But hang on, let's try to read it like an object.

for (const i in divItems) {
    console.log(i)
}
// will output the following (numbers on one line for readability)
// 0, 1, 2, 3, 4, 5, 6
// entries
// keys
// values
// forEach
// length
// item

And there's why I like a NodeList more. It has the forEach method available for use because it is inherited from its Prototype (maybe I'll write about that later). If you expand the console.log for the HTML/Node collection as a whole and look at the last entry, you can spot the additional object 'keys' that are read by a For...in loop.

Peering inside our HTML collection entry.

So if your goal is to iterate through bunch of HTML elements on a page, your best best is to querySelectorAll those bad boys and either use a For...of loop or a forEach method on them.

TL;DR

Use a For... of loop on an array when you want to know the 1st, 2nd, or nth item of the array. Use a For... in loop on an object when you want to see the key:value pairs inside it. HTMLCollections and NodeLists are both a type of array, but only a NodeList has access to the forEach method.

Thanks for reading!

Precipitates, Plato, and Programming

Sergio B — Sat, 09 Apr 2022 17:20:52 +0000

To say that software development was always in my future would be a great exaggeration. Sure, I loved video games and computers growing up, but I wasn’t truly aware of the backstage code making it all possible and was more than content to just chicken-peck my keyboard well into high school. Similarly, my experience with school during that time was that I enjoyed learning things in most classes, but there weren’t any that inspired me to step into their greater depths of knowledge. The first one to defy this norm for me was 10th grade chemistry. This subject struck a nice balance between physical and mathematical theories that weren’t much by themselves, and the practice of thoughtful experimentation, to reveal something fundamentally amazing about the universe. Outside of this passion, I had a great appreciation for geometry, French, and even psychology but none could compete with the hands-on aspect of chemistry.

A New World

It wasn't until my digital electronics class two years later that I once again had a class that let me take my knowledge and test it out in the real world. In this class, we were introduced to Boolean logic and gradually guided from there to understand logic gates. Some time after that, we were capable of designing large-scale systems on a breadboard with capacitors, resistors, and many, many wires that would be capable of carrying out a simple objective autonomously.

A circuit board that displayed my birthdate on an LED display.

I was so obsessed with all this that one day at my friend's house, I realized the light switch at the top and bottom of his staircase both controlled the same bulb. Applying what I’d learned, I immediately drew up a truth table for all the switch positions and recorded the lightbulb's "output". I was ecstatic when I discovered that whatever wiring was connecting the two switches to the bulb behaved exactly like a XOR gate. Unfortunately, my friend did not share the same elation and we swiftly moved on to our task of shooting virtual zombies on his PS3, powered by more transistors and logic circuits than either of us could conceive of.

One year and some months after that, I found myself at CU Boulder, totally set to rock my way through the next three years of a chemical engineering degree. The first year had been interesting because I was learning my new rhythm of having independence (albeit in a campus dorm room of ~150 square feet shared with another person) and getting to learn all sorts of new things in algebra, chemistry, and introductory engineering. I was doing quite well but other than my writing course where we had lively discussions hosted by a professor with a passion for inspiring our curiosity, I didn't really feel like I was having an experience worth half of a brand spanking new Subaru Outback.

Lovely.

That is, until I reached sophomore year and got into both my Greek philosophy and introduction to computer engineering courses. Here were two classes, on different ends of the conceptual-to-actual spectrum, with dedicated instructors who clearly had a great deal of knowledge and interest in their subject. Through philosophy, I was introduced to some of the earliest conceptions of formalized logic and reasoning that figures from Plato to Diogenes Laertius would use to try and sort out everything from making a government, to why the sun is probably a giant ball of fire really far away from us. Meanwhile, in my computer engineering course, we were introduced to basic programming languages including Microsoft’s Visual Basic in Excel and Matlab’s proprietary language. These were used as vehicles for us to craft programs and functions, conceived in theory and ultimately executed with real data, to obtain concrete figures and plans for the purposes of engineering.

A New Way of Thinking

Through everything I learned and all the tests I passed in my two years at college, the one thing that stuck with me more than anything else was a function I wrote for that engineering class. It wasn’t a very complicated function I needed to program but it took me the better part of a day to reason through. I remember thinking through the problem conceptually and figuring out the different cases my algorithm would need to account for and what kinds of data I should expect. The objective was to write a function that would accept two circles given the radius of each, along with the distance between the two circles. The function would then need to calculate the area taken up by the two circles, including the case where they overlap, without double counting any area. I remember getting to the end of my coding, plotting a sample curve to test whether my program worked, and just staring at the resulting graph.

My function plotted for circles of radius 1 and 2, from a distance of 0 to 4 units.

It was exactly what I was imagining but it was a testament to the true power of logic and computation to bring a concept out like that into the real world. And that’s also what led me to realize I had chosen the wrong major.

To Begin Again

After a long bout with myself and careful stock of my situation, I decided to return home and focus on many aspects of my health I’d completely neglected in the single-minded pursuit of being able to say I got a chemical engineering degree. I ended up working real jobs for a while, a harsh contrast to the only one I’d held before as the overnight receptionist for the campus dorm halls. I worked at grocery stores for a couple of years before moving into retail where I was able to go from unloading trucks at 5 AM on a conveyor line, to running a whole department by myself. And after a couple years of that, I decided I’d had enough and joined Amazon to start from the bottom again.

Coincidentally, I ended up in the stow department focusing on something much akin to merchandising at my previous workplace. Although this place was in large part run by algorithms talked about by my coworkers as if they were pagan gods or some force of nature.

I'd hear things like, “the system doesn’t like it when you try and put two similar items in the same bin!” and “the system goes around trying to clean up any little mistake we make.”

Over the next two years, I gained a lot of experience and slowly formed a picture of how the processes in the warehouse flowed and even got to learn how to troubleshoot them using our inventory website. Now, it’s clear to me how people’s interactions with the digital systems built into and behind the scenes of every Amazon warehouse influence the environment and culture of such a workplace. Seeing this and reflecting on my past experiences and the opportunity Amazon has put in front of me through Flatiron School fills me with resolve.

To the Future

I don’t have a “master plan” for what I want from software development but I do have 3 goals in mind:

Gain more autonomy in my career options, hopefully starting out with a higher-paying position within or close to my current Amazon Fulfillment Center.
Host my own website that I will build to represent me, my interests, and any fun or interesting projects I choose to share.
Learn enough about mobile development to work on my own grocery list app, partially inspired by living with my roommates.

I am learning how to learn more than I ever did in all my schooling and I can’t wait to be challenged more than I’ve ever been in this bootcamp. I am excited to begin a new journey of discovery and enter into a community of people making things we rely on that not everyone really stops and thinks about. Lastly, I am looking forward to sharing what I learn and getting to know people extraordinarily different from myself that will also use this medium to turn their conceptions into reality.