DEV Community: Lydia Hallie

✋🏼🔥 CS Visualized: CORS

Lydia Hallie — Mon, 27 Jul 2020 14:55:58 +0000

It’s every developer’s frustration once in a while to see that big red Access to fetched has been blocked by CORS policy error in your console! 😬 Although there are some ways to quickly get rid of this error, let’s not take anything for granted today! Instead, let’s see what CORS is actually doing, and why it’s actually our friend 👏🏼

❗️ In this blog post I won’t explain HTTP basics. In case you’d like to know more about HTTP requests and responses, I wrote a small blog post about it a while ago though 🙂 In my examples I use HTTP/1.1 instead of HTTP/2, this doesn’t affect CORS.

✋🏼 Same-Origin Policy
S H O R T C U T S
🔥 Client-side CORS
💻 Server-side CORS
🚀 Preflight Requests
🍪 Credentials

On the frontend, we often want to display data that's located elsewhere! Before we can display this data, the browser first has to make a request to a server in order to fetch that data! The client sends an HTTP request with all the information that the server needs in order to send that data back to the client 🙂

Let’s say we’re trying to fetch some user information on our www.mywebsite.com website from a server that’s located at api.website.com!

Perfect! 😃 We just sent an HTTP request to the server, which then responded with the JSON data we asked for.

Let's try the exact same request but from another domain. Instead of making the request from www.mywebsite.com, we’re now making the request from a website located at www.anotherdomain.com.

Wait, what? We sent the exact same request, but this time the browser shows us a weird error?

We just saw CORS in action! 💪🏼 Let’s see why this error occurred, and what it exactly means.

✋🏼 Same-Origin Policy

The web enforces something called the same-origin policy. By default, we can only access resources that are located at the same origin as the origin of our request! 💪🏼 It's totally okay to load an image that's located at https://mywebsite.com/image1.png, for example.

A resource is cross-origin when it's located at a different (sub)domain, protocol, or port!

Cool, but why does the same-origin policy even exist?

Let's say that the same-origin policy didn't exist, and you accidentally clicked one of the many virus links your aunt sent you on Facebook. This link redirects you to an "evil website" that has an iframe embedded which loads your bank's website, and successfully logs you in by some set cookies! 😬

The developers of this "evil website" made it possible for the website to access this iframe and interact with the DOM contents of your bank's website in order to send money to their account on your behalf!

Yeah... this is a huge security risk! We don't want anyone to just be able to access everything 😧

Luckily, the same-origin policy helps us out here! This policy makes sure that we can only access resources from the same origin.

In this case, the origin www.evilwebsite.com tried to access cross-origin resources from www.bank.com! The same-origin policy blocked this from happening and made sure that the evil website's devs couldn't just access our bank data 🥳

Okay, so... what does this have to do with CORS?

🔥 Client-side CORS

Although the same-origin policy actually only applies to scripts, browsers "extended" this policy for JavaScript requests: by default, we can only access fetched resources from the same origin!

Hmm, but... We often have to access cross-origin resources 🤔 Maybe our frontend needs to interact with our backend API in order to load the data? In order to allow cross-origin requests safely, the browser uses a mechanism called CORS! 🥳

CORS stands for Cross-Origin Resource Sharing. Although the browser disallows us from accessing resources that aren’t located at the same origin, we can use CORS to change those security restrictions a bit while still making sure that we’re accessing those resources safely 🎉

User agents (a browser, for example) can use the CORS mechanism in order to allow cross-origin requests which otherwise would've been blocked, based on the values of certain CORS-specific headers in the HTTP response! ✅

When a cross-origin request is made, the client automatically adds an extra header to our HTTP request: Origin. The value of the Origin header is the origin where the request came from!

In order for the browser to allow accessing cross-origin resources, it expects certain headers from the server's response, which specify whether this server allows cross-origin requests!

💻 Server-side CORS

As a server developer, we can make sure that cross-origin requests are allowed by adding extra headers to the HTTP response, which all start with Access-Control-* 🔥 Based on the values of these CORS response headers, the browser can now allow certain cross-origin responses which would’ve normally been blocked by the same-origin policy!

Although there are several CORS headers we can use, there is one header that the browser needs in order to allow cross-origin resource access: Access-Control-Allow-Origin! 🙂
The value of this header specifies which origins are allowed to access the resources that they're requesting from the server.

If we’re developing a server that https://mywebsite.com should have access to, we can add the value of that domain to the Access-Control-Allow-Origin header!

Awesome! 🎉 This header is now added to the response that the server sends back to the client. By adding this header, the same-policy origin will no longer restrict us from receiving resources that were located at the https://api.mywebsite.com origin, if we sent the request from https://mywebsite.com!

The CORS mechanism within the browser checks whether the value of the Access-Control-Allow-Origin header equals the value of the Origin that was sent by the request 🤚🏼

In this case, the origin of our request is https://www.mywebsite.com, which is listed in the Access-Control-Allow-Origin response header!

Perfect! 🎉 We were able to receive the cross-origin resources successfully! So what happens when we’re trying to access these resources from an origin that’s not listed in the Access-Control-Allow-Origin header? 🤔

Ahh yeah, CORS throws the notorious error that can be so frustrating at times! But now we actually see that it makes total sense



The 'Access-Control-Allow-Origin' header has a value
 'https://www.mywebsite.com' that is not equal 
to the supplied origin.

In this case, the supplied origin was https://www.anotherwebsite.com. However, the server didn’t have this supplied origin in the list of allowed origins in the Access-Control-Allow-Origin header! CORS successfully blocked the request, and we cannot access the fetched data in our code 😃

CORS also allows us to add the wildcard * as the value for the allowed origins. This means that requests from all origins should have access to the requested resources, so be careful!

Access-Control-Allow-Origin is one of the many CORS headers we can provide. A server developer can extend the server's CORS policies in order to (dis)allow certain requests! 💪🏼

Another common header is the Access-Control-Allow-Methods header! CORS will only allow cross-origin requests if they were sent with the listed methods.

In this case, only requests with a GET, POST, or PUT method will be allowed! Other methods such as PATCH or DELETE will be blocked ❌

If you're curious about what the other possible CORS headers are and what they're used for, check out this list.

Speaking of PUT, PATCH, and DELETE requests, CORS actually handles those requests differently! 🙃 These "non-simple" requests initiate something called a preflight request!

🚀 Preflighted Requests

CORS has two types of requests: a simple request and a preflighted request. Whether a request is simple or preflighted depends on some values within the request (don't worry, you don't have to memorize this lol).

A request is simple when the request is a GET or POST method and doesn't have any custom headers! Any other request, such as requests with a PUT, PATCH, or DELETE method, will be preflighted.

In case you’re just curious about which requirements a request has to meet in order to be a simple request, MDN has a useful list!

Okay sure, but what does "preflighted request" even mean, and why does this happen?

Before the actual request gets sent, the client generates a preflighted request! The preflighted request contains information about the actual request we’re about to in its Access-Control-Request-* headers 🔥

This gives the server information about the actual request that the browser is trying to make: what is the method of the request, what are the additional headers, and so on.

The server receives this preflighted request, and sends an empty HTTP response back with the server's CORS headers! The browser receives the preflight response, which contains no data besides the CORS headers, and checks whether the HTTP request should be allowed! ✅

If that's the case, the browser sends the actual request to the server, which then responds with the data we asked for!

However, if it’s not the case, CORS will block the preflighted request, and the actual request never gets sent ✋🏼 The preflighted request is a great way to prevent us from accessing or modifying resources on servers that don't have any CORS policies enabled (yet)! Servers are now protected from potentially unwanted cross-origin requests 😃

💡 In order to reduce the number of roundtrips to our server, we can cache the preflighted responses by adding an Access-Control-Max-Age header to our CORS requests! We can cache the preflighted response this way, which the browser can use instead of sending a new preflighted request!

🍪 Credentials

Cookies, authorization headers, and TLS certificates are by default only set on same-origin requests! However, we may want to use these credentials in our cross-origin request. Maybe we want to include cookies on the request that the server can use in order to identify the user!

Although CORS doesn't include credentials by default, we can change this by adding the Access-Control-Allow-Credentials CORS header! 🎉

If we want to include cookies and other authorization headers to our cross-origin request, we need to set the withCredentials field to true on the request and add the Access-Control-Allow-Credentials header to the response.

All set! We can now include credentials in our cross-origin request 🥳

Although I think we can all agree that CORS errors can be frustrating at times, it's amazing that it enables us to safely make cross-origin requests in the browser (it should receive a bit more love lol) ✨

Obviously there is so much more to the same-origin policy and CORS than I was able to cover here in this blog post! Luckily, there are many great resources out there like this one or the W3 spec if you want to read more about it 💪🏼

And as always, feel free to reach out to me! 😊

✨ Twitter

👩🏽‍💻 Instagram

💻 GitHub

💡 LinkedIn

📷 YouTube

💌 Email

⭐️🎀 JavaScript Visualized: Promises & Async/Await

Lydia Hallie — Tue, 14 Apr 2020 16:46:40 +0000

If you're here in 2024 (or later), here's an updated video:

Ever had to deal with JS code that just... didn't run the way you expected it to? Maybe it seemed like functions got executed at random, unpredictable times, or the execution got delayed. There's a chance you were dealing with a cool new feature that ES6 introduced: Promises!

My curiosity from many years ago has paid off and my sleepless nights have once again given me the time to make some animations. Time to talk about Promises: why would you use them, how do they work "under the hood", and how can we write them in the most modern way?

If you haven't read my previous post on the JavaScript Event Loop yet, it may be useful to read that first! I'll be covering the event loop again assuming some basic knowledge about the call stack, Web API and the queue, but this time we'll also be covering some exciting extra features 🤩

✨♻️ JavaScript Visualized: Event Loop

Lydia Hallie ・ Nov 20 '19

#javascript #webdev

If you're already somewhat familiar with promises, here are some shortcuts to save you some precious scrolling time.

🥳 Introduction

⚡️ Promise Syntax

♻️ Event Loop: Microtasks and (Macro)tasks

🚀 Async/Await

Introduction

When writing JavaScript, we often have to deal with tasks that rely on other tasks! Let's say that we want to get an image, compress it, apply a filter, and save it 📸

The very first thing we need to do, is get the image that we want to edit. A getImage function can take care of this! Only once that image has been loaded successfully, we can pass that value to a resizeImage function. When the image has been resized successfully, we want to apply a filter to the image in the applyFilter function. After the image has been compressed and we've added a filter, we want to save the image and let the user know that everything worked correctly! 🥳

In the end, we'll end up with something like this:

Hmm... Notice anything here? Although it's... fine, it's not great. We end up with many nested callback functions that are dependent on the previous callback function. This is often referred to as a callback hell, as we end up with tons of nested callback functions that make the code quite difficult to read!

Luckily, we now got something called promises to help us out! Let's take a look at what promises are, and how they can help us in situations like these! 😃

Promise Syntax

ES6 introduced Promises. In many tutorials, you'll read something like:

"A promise is a placeholder for a value that can either resolve or reject at some time in the future"

Yeah... That explanation never made things clearer for me. In fact it only made me feel like a Promise was a weird, vague, unpredictable piece of magic. So let's look at what promises really are.

We can create a promise, using a Promise constructor that receives a callback. Okay cool, let's try it out!

Wait woah, what just got returned?

A Promise is an object that contains a status, ([[PromiseStatus]]) and a value ([[PromiseValue]]). In the above example, you can see that the value of [[PromiseStatus]] is "pending", and the value of the promise is undefined.

Don't worry - you'll never have to interact with this object, you can't even access the [[PromiseStatus]] and [[PromiseValue]] properties! However, the values of these properties are important when working with promises.

The value of the PromiseStatus, the state, can be one of three values:

✅ fulfilled: The promise has been resolved. Everything went fine, no errors occurred within the promise 🥳
❌ rejected : The promise has been rejected. Argh, something went wrong..
⏳ pending: The promise has neither resolved nor rejected (yet), the promise is still pending.

Alright this all sounds great, but when is a promise status "pending", "fulfilled" or "rejected"? And why does that status even matter?

In the above example, we just passed the simple callback function () => {} to the Promise constructor. However, this callback function actually receives two arguments. The value of the first argument, often called resolve or res, is the method to be called when the Promise should resolve. The value of the second argument, often called reject or rej, is the value method to be called when the Promise should reject, something went wrong.

Let's try and see that gets logged when we invoke either the resolve or reject method! In my example, I called the resolve method res, and the reject method rej.

Awesome! We finally know how to get rid of the "pending" status and the undefined value! The status of a promise is "fulfilled" if we invoked the resolve method, and the status of the promise is "rejected" if we invoked the rejected method.

The value of a promise, the value of [[PromiseValue]], is the value that we pass to the either the resolved or rejected method as their argument.

Fun fact, I let Jake Archibald proofread this article and he actually pointed out there's a bug in Chrome that currently shows the status as "resolved" instead of "fulfilled". Thanks to Mathias Bynens it's now fixed in Canary! 🥳🕺🏼 // Detect dark theme var iframe = document.getElementById('tweet-1248179232775319559-992'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1248179232775319559&theme=dark" }

Okay so, now we know a little bit better how to control that vague Promise object. But what is it used for?

In the introductory section, I showed an example in which we get an image, compress it, apply a filer, and save it! Eventually, this ended up being a nested callback mess.

Luckily, Promises can help us fix this! First, let's rewrite the entire code block, so that each function returns a Promise instead.

If the image is loaded and everything went fine, let's resolve the promise with the loaded image! Else, if there was an error somewhere while loading the file, let's reject the promise with the error that occurred.

Let's see what happens when we run this in the terminal!

Cool! A promise got returned with the value of the parsed data, just like we expected.

But... what now? We don't care about that entire promise object, we only care about the value of the data! Luckily, there are built-in methods to get a promise's value. To a promise, we can attach 3 methods:

.then(): Gets called after a promise resolved.
.catch(): Gets called after a promise rejected.
.finally(): Always gets called, whether the promise resolved or rejected.

The .then method receives the value passed to the resolve method.

The .catch method receives the value passed to the rejected method

Finally, we have the value that got resolved by the promise without having that entire promise object! We can now do whatever we want with this value.

FYI, when you know that a promise will always resolve or always reject, you can write Promise.resolve or Promise.reject , with the value you want to reject or resolve the promise with!

You'll often see this syntax in the following examples 😄

In the getImage example, we ended up having to nest multiple callbacks in order to run them. Luckily, the .then handlers can help us with that! 🥳

The result of the .then itself is a promise value. This means that we can chain as many .thens as we want: the result of the previous then callback will be passed as an argument to the next then callback!

In the case of the getImage example, we can chain multiple then callbacks in order to pass the processed image onto the next function! Instead of ending up with many nested callbacks, we get a clean then chain.

Perfect! This syntax already looks way better than the nested callbacks.

Microtasks and (Macro)tasks

Okay so we know a little better how to create a promise and how to extract values out of a promise. Let's add some more code to the script, and run it again:

Wait what?! 🤯

First, Start! got logged. Okay we could've seen that one coming: console.log('Start!') is on the very first line! However, the second value that got logged was End!, and not the value of the resolved promise! Only after End! was logged, the value of the promise got logged. What's going on here?

We've finally seen the true power of promises! 🚀 Although JavaScript is single-threaded, we can add asynchronous behavior using a Promise!

But wait, haven't we seen that before? 🤔 In the JavaScript event loop, can't we also use methods native to the browser such as setTimeout to create some sort of asynchronous behavior?

Yes! However, within the Event Loop, there are actually two types of queues: the (macro)task queue (or just called the task queue), and the microtask queue. The (macro)task queue is for (macro)tasks and the microtask queue is for microtasks.

So what's a (macro)task and what's a microtask? Although there are a few more than I'll cover here, the most common are shown in the table below!

(Macro)task	`setTimeout` \| `setInterval` \| `setImmediate`
Microtask	`process.nextTick` \| `Promise callback` \| `queueMicrotask`

Ahh, we see Promise in the microtask list! 😃 When a Promise resolves and calls its then(), catch() or finally(), method, the callback within the method gets added to the microtask queue! This means that the callback within the then(), catch() or finally() method isn't executed immediately, essentially adding some async behavior to our JavaScript code!

So when is a then(), catch() or finally() callback executed? The event loop gives a different priority to the tasks:

All functions in that are currently in the call stack get executed. When they returned a value, they get popped off the stack.
When the call stack is empty, all queued up microtasks are popped onto the callstack one by one, and get executed! (Microtasks themselves can also return new microtasks, effectively creating an infinite microtask loop 😬)
If both the call stack and microtask queue are empty, the event loop checks if there are tasks left on the (macro)task queue. The tasks get popped onto the callstack, executed, and popped off!

Let's take a look at a quick example, simply using:

Task1: a function that's added to the call stack immediately, for example by invoking it instantly in our code.
Task2, Task3, Task4: microtasks, for example a promise then callback, or a task added with queueMicrotask.
Task5, Task6: a (macro)task, for example a setTimeout or setImmediate callback

First, Task1 returned a value and got popped off the call stack. Then, the engine checked for tasks queued in the microtask queue. Once all the tasks were put on the call stack and eventually popped off, the engine checked for tasks on the (macro)task queue, which got popped onto the call stack, and popped off when they returned a value.

Okay okay enough pink boxes. Let's use it with some real code!

In this code, we have the macro task setTimeout, and the microtask promise then() callback. Once the engine reaches the line of the setTimeout function. Let's run this code step-by-step, and see what gets logged!

Quick FYI - in the following examples I'm showing methods like console.log, setTimeout and Promise.resolve being added to the call stack. They're internal methods and actually don't appear in stack traces - so don't worry if you're using the debugger and you don't see them anywhere! It just makes explaining this concept easier without adding a bunch of boilerplate code 🙂

On the first line, the engine encounters the console.log() method. It gets added to the call stack, after which it logs the value Start! to the console. The method gets popped off the call stack, and the engine continues.

The engine encounters the setTimeout method, which gets popped on to the call stack. The setTimeout method is native to the browser: its callback function (() => console.log('In timeout')) will get added to the Web API, until the timer is done. Although we provided the value 0 for the timer, the call back still gets pushed to the Web API first, after which it gets added to the (macro)task queue: setTimeout is a macro task!

The engine encounters the Promise.resolve() method. The Promise.resolve() method gets added to the call stack, after which is resolves with the value Promise!. Its then callback function gets added to the microtask queue.

The engine encounters the console.log() method. It gets added to the call stack immediately, after which it logs the value End! to the console, gets popped off the call stack, and the engine continues.

The engine sees the callstack is empty now. Since the call stack is empty, it's going to check whether there are queued tasks in the microtask queue! And yes there are, the promise then callback is waiting for its turn! It gets popped onto the call stack, after which it logs the resolved value of the promise: the string Promise!in this case.

The engine sees the call stack is empty, so it's going to check the microtask queue once again to see if tasks are queued. Nope, the microtask queue is all empty.

It's time to check the (macro)task queue: the setTimeout callback is still waiting there! The setTimeout callback gets popped on to the callstack. The callback function returns the console.log method, which logs the string "In timeout!". The setTimeout callback get popped off the callstack.

Finally, all done! 🥳 It seems like the output we saw earlier wasn't so unexpected after all.

Async/Await

ES7 introduced a new way to add async behavior in JavaScript and make working with promises easier! With the introduction of the async and await keywords, we can create async functions which implicitly return a promise. But.. how can we do that? 😮

Previously, we saw that we can explicitly create promises using the Promise object, whether it was by typing new Promise(() => {}), Promise.resolve, or Promise.reject.

Instead of explicitly using the Promise object, we can now create asynchronous functions that implicitly return an object! This means that we no longer have to write any Promise object ourselves.

Although the fact that async functions implicitly return promises is pretty great, the real power of async functions can be seen when using the await keyword! With the await keyword, we can suspend the asynchronous function while we wait for the awaited value return a resolved promise. If we want to get the value of this resolved promise, like we previously did with the then() callback, we can assign variables to the awaited promise value!

So, we can suspend an async function? Okay great but.. what does that even mean?

Let's see what happens when we run the following block of code:

Hmm.. What's happening here?

First, the engine encounters a console.log. It gets popped onto the call stack, after which Before function! gets logged.

Then, we invoke the async function myFunc(), after which the function body of myFunc runs. On the very first line within the function body, we call another console.log, this time with the string In function!. The console.log gets added to the call stack, logs the value, and gets popped off.

The function body keeps on being executed, which gets us to the second line. Finally, we see an await keyword! 🎉

The first thing that happens is that the value that gets awaited gets executed: the function one in this case. It gets popped onto the call stack, and eventually returns a resolved promise. Once the promise has resolved and one returned a value, the engine encounters the await keyword.

When encountering an await keyword, the async function gets suspended. ✋🏼 The execution of the function body gets paused, and the rest of the async function gets run in a microtask instead of a regular task!

Now that the async function myFunc is suspended as it encountered the await keyword, the engine jumps out of the async function and continues executing the code in the execution context in which the async function got called: the global execution context in this case! 🏃🏽‍♀️

Finally, there are no more tasks to run in the global execution context! The event loop checks to see if there are any microtasks queued up: and there are! The async myFunc function is queued up after resolving the valued of one. myFunc gets popped back onto the call stack, and continues running where it previously left off.

The variable res finally gets its value, namely the value of the resolved promise that one returned! We invoke console.log with the value of res: the string One! in this case. One! gets logged to the console and gets popped off the call stack! 😊

Finally, all done! Did you notice how async functions are different compared to a promise then? The await keyword suspends the async function, whereas the Promise body would've kept on being executed if we would've used then!

Hm that was quite a lot of information! 🤯 No worries at all if you still feel a bit overwhelmed when working with Promises, I personally feel that it just takes experience to notice patterns and feel confident when working with asynchronous JavaScript.

However, I hope that the "unexpected" or "unpredictable" behavior that you might encounter when working with async JavaScript makes a bit more sense now!

And as always, feel free to reach out to me! 😊

✨ Twitter

👩🏽‍💻 Instagram

💻 GitHub

💡 LinkedIn

📷 YouTube

💌 Email

If you want to know more about promises states (and fates!), this Github repo does an excellent job explaining the differences.

domenic / promises-unwrapping

The ES6 promises spec, as per September 2013 TC39 meeting

🌳🚀 CS Visualized: Useful Git Commands

Lydia Hallie — Wed, 01 Apr 2020 16:48:56 +0000

Although Git is a very powerful tool, I think most people would agree when I say it can also be... a total nightmare 😐 I've always found it very useful to visualize in my head what's happening when working with Git: how are the branches interacting when I perform a certain command, and how will it affect the history? Why did my coworker cry when I did a hard reset on master, force pushed to origin and rimraf'd the .git folder?

I thought it would be the perfect use case to create some visualized examples of the most common and useful commands! 🥳 Many of the commands I'm covering have optional arguments that you can use in order to change their behavior. In my examples, I'll cover the default behavior of the commands without adding (too many) config options! 😄

Merge

Rebase

Reset

Revert

Cherry-Pick

Fetch

Pull

Reflog

Merging

Having multiple branches is extremely convenient to keep new changes separated from each other, and to make sure you don't accidentally push unapproved or broken changes to production. Once the changes have been approved, we want to get these changes in our production branch!

One way to get the changes from one branch to another is by performing a git merge! There are two types of merges Git can perform: a fast-forward, or a no-fast-forward 🐢

This may not make a lot of sense right now, so let's look at the differences!

Fast-forward (`--ff`)

A fast-forward merge can happen when the current branch has no extra commits compared to the branch we’re merging. Git is... lazy and will first try to perform the easiest option: the fast-forward! This type of merge doesn’t create a new commit, but rather merges the commit(s) on the branch we’re merging right in the current branch 🥳

Perfect! We now have all the changes that were made on the dev branch available on the master branch. So, what's the no-fast-forward all about?

No-fast-foward (`--no-ff`)

It's great if your current branch doesn't have any extra commits compared to the branch that you want to merge, but unfortunately that's rarely the case! If we committed changes on the current branch that the branch we want to merge doesn't have, git will perform a no-fast-forward merge.

With a no-fast-forward merge, Git creates a new merging commit on the active branch. The commit's parent commits point to both the active branch and the branch that we want to merge!

No big deal, a perfect merge! 🎉 The master branch now contains all the changes that we've made on the dev branch.

Merge Conflicts

Although Git is good at deciding how to merge branches and add changes to files, it cannot always make this decision all by itself 🙂 This can happen when the two branches we're trying to merge have changes on the same line in the same file, or if one branch deleted a file that another branch modified, and so on.

In that case, Git will ask you to help decide which of the two options we want to keep! Let's say that on both branches, we edited the first line in the README.md.

If we want to merge dev into master, this will end up in a merge conflict: would you like the title to be Hello! or Hey!?

When trying to merge the branches, Git will show you where the conflict happens. We can manually remove the changes we don't want to keep, save the changes, add the changed file again, and commit the changes 🥳

Yay! Although merge conflicts are often quite annoying, it makes total sense: Git shouldn't just assume which change we want to keep.

Rebasing

We just saw how we could apply changes from one branch to another by performing a git merge. Another way of adding changes from one branch to another is by performing a git rebase.

A git rebase copies the commits from the current branch, and puts these copied commits on top of the specified branch.

Perfect, we now have all the changes that were made on the master branch available on the dev branch! 🎊

A big difference compared to merging, is that Git won't try to find out which files to keep and not keep. The branch that we're rebasing always has the latest changes that we want to keep! You won't run into any merging conflicts this way, and keeps a nice linear Git history.

This example shows rebasing on the master branch. In bigger projects, however, you usually don't want to do that. A git rebase changes the history of the project as new hashes are created for the copied commits!

Rebasing is great whenever you're working on a feature branch, and the master branch has been updated. You can get all the updates on your branch, which would prevent future merging conflicts! 😄

Interactive Rebase

Before rebasing the commits, we can modify them! 😃 We can do so with an interactive rebase. An interactive rebase can also be useful on the branch you're currently working on, and want to modify some commits.

There are 6 actions we can perform on the commits we're rebasing:

reword: Change the commit message
edit: Amend this commit
squash: Meld commit into the previous commit
fixup: Meld commit into the previous commit, without keeping the commit's log message
exec: Run a command on each commit we want to rebase
drop: Remove the commit

Awesome! This way, we can have full control over our commits. If we want to remove a commit, we can just drop it.

Or if we want to squash multiple commits together to get a cleaner history, no problem!

Interactive rebasing gives you a lot of control over the commits you're trying to rebase, even on the current active branch!

Resetting

It can happen that we committed changes that we didn't want later on. Maybe it's a WIP commit, or maybe a commit that introduced bugs! 🐛 In that case, we can perform a git reset.

A git reset gets rid of all the current staged files and gives us control over where HEAD should point to.

Soft reset

A soft reset moves HEAD to the specified commit (or the index of the commit compared to HEAD), without getting rid of the changes that were introduced on the commits afterward!

Let's say that we don't want to keep the commit 9e78i which added a style.css file, and we also don't want to keep the commit 035cc which added an index.js file. However, we do want to keep the newly added style.css and index.js file! A perfect use case for a soft reset.

When typing git status, you'll see that we still have access to all the changes that were made on the previous commits. This is great, as this means that we can fix the contents of these files and commit them again later on!

Hard reset

Sometimes, we don't want to keep the changes that were introduced by certain commits. Unlike a soft reset, we shouldn't need to have access to them any more. Git should simply reset its state back to where it was on the specified commit: this even includes the changes in your working directory and staged files! 💣

Git has discarded the changes that were introduced on 9e78i and 035cc, and reset its state to where it was on commit ec5be.

Reverting

Another way of undoing changes is by performing a git revert. By reverting a certain commit, we create a new commit that contains the reverted changes!

Let's say that ec5be added an index.js file. Later on, we actually realize we didn't want this change introduced by this commit anymore! Let's revert the ec5be commit.

Perfect! Commit 9e78i reverted the changes that were introduced by the ec5be commit. Performing a git revert is very useful in order to undo a certain commit, without modifying the history of the branch.

Cherry-picking

When a certain branch contains a commit that introduced changes we need on our active branch, we can cherry-pick that command! By cherry-picking a commit, we create a new commit on our active branch that contains the changes that were introduced by the cherry-picked commit.

Say that commit 76d12 on the dev branch added a change to the index.js file that we want in our master branch. We don't want the entire we just care about this one single commit!

Cool, the master branch now contains the changes that 76d12 introduced!

Fetching

If we have a remote Git branch, for example a branch on Github, it can happen that the remote branch has commits that the current branch doesn't have! Maybe another branch got merged, your colleague pushed a quick fix, and so on.

We can get these changes locally, by performing a git fetch on the remote branch! It doesn't affect your local branch in any way: a fetch simply downloads new data.

We can now see all the changes that have been made since we last pushed! We can decide what we want to do with the new data now that we have it locally.

Pulling

Although a git fetch is very useful in order to get the remote information of a branch, we can also perform a git pull. A git pull is actually two commands in one: a git fetch, and a git merge. When we're pulling changes from the origin, we're first fetching all the data like we did with a git fetch, after which the latest changes are automatically merged into the local branch.

Awesome, we're now perfectly in sync with the remote branch and have all the latest changes! 🤩

Reflog

Everyone makes mistakes, and that's totally okay! Sometimes it may feel like you've screwed up your git repo so badly that you just want to delete it entirely.

git reflog is a very useful command in order to show a log of all the actions that have been taken! This includes merges, resets, reverts: basically any alteration to your branch.

)

If you made a mistake, you can easily redo this by resetting HEAD based on the information that reflog gives us!

Say that we actually didn't want to merge the origin branch. When we execute the git reflog command, we see that the state of the repo before the merge is at HEAD@{1}. Let's perform a git reset to point HEAD back to where it was on HEAD@{1}!

We can see that the latest action has been pushed to the reflog!

Git has so many useful porcelain and plumbing commands, I wish I could cover them all! 😄 I know there are many other commands or alterations that I didn't have time for to cover right now - let me know what your favorite/most useful commands are, and I may cover them in another post!

And as always, feel free to reach out to me! 😊

✨ Twitter

👩🏽‍💻 Instagram

💻 GitHub

💡 LinkedIn

📷 YouTube

💌 Email

⭐️ Interactive JavaScript Quiz #2

Lydia Hallie — Mon, 09 Mar 2020 06:28:11 +0000

This is the second post of the JavaScript Quiz series! Make sure to check out the first one 🥳 Before starting this quiz, it may be useful to read through some of my older Dev.to posts! 😃

💡🎁 JavaScript Visualized: Generators and Iterators

Lydia Hallie ・ Jan 16 '20

#javascript #node

🎉👨‍👩‍👧‍👧 JavaScript Visualized: Prototypal Inheritance

Lydia Hallie ・ Jan 3 '20

#javascript #computerscience #webdev

lydiahallie / javascript-questions

A long list of (advanced) JavaScript questions, and their explanations ✨

Of course, the examples are still minimal and don't show "the best/most performant way to do it". Sometimes I have to do things a certain way in order to be able to show certain behavior that may happen, and explain it that way 🙂

Okay, ready? Let's get started!

1. What's the output?

Explanation

In this code snippet, we have a person object and two arrow functions: changeAge and changeAgeAndName. The two arrow functions expect a parameter x. If we don't provide a value (or provide undefined) for x while invoking either changeAge or changeAgeAndName, the value of x will be equal to {...person}.

First, we invoke the changeAge function. We pass an object: the person object! The default variable { ...person } won't be used: we provided a value after all 😊

The changeAge function increments the value of the age property on the object that x holds a reference to, by 1. This means that the value of age on the person object will be incremented by one.
The person object is now { name: "Lydia", age: 22 }.

Then, we invoke the changeAgeAndName function without providing a value. This means that the value of x will be equal to the default value { ...person }, which is a new object with the copied properties of the person object: { name: "Lydia", age: 22 }.

The changeAgeAndName function increments the value of the age property by 1, and sets the value of name equal to "Sarah".

When we log the person object, we'll only see the modification that was made by the changeAge function: { name: "Lydia", age: 22 } 🎉

2. What's the output?

Explanation

In this code snippet, we have a generator function range, which receives a start and end value. It loops over the values that range between the value of start and end, and yields a resolved promise for each value 🔥

When we invoke the immediately invoked function, we set the variable gen equal to the iterator that got returned by the range generator function.

If we were to manually call the next method on the gen iterator, we'd see the resolved promises for the values within the range that we provided. We passed the values 1 to 3, meaning that when we iterate over the iterator, it first yields Promise {1}, then Promise {2}, then Promise {3}.

We can iterate over the yielded values of the iterator with a for..in loop. This way, we don't have to manually call the next() method each time 😃

We want to get the resolved values of each promise. We can do so, by awaiting each promise in a for await .. in loop.

With the for await...in loop, we can loop over the iterator and await each value. By awaiting the resolved promises, the resolved values get returned: 1, 2, and 3 in this case 💪🏼

3. What's the output?

Explanation

We invoke the getInfo function. On the very first line of this function, we're trying to log the value of the randomValue variable.

In this snippet, we see two variables called randomValue, both declared with the const keyword. Variables declared with the const keyword are block-scoped, and not initialized until we get to the line where we actually declare them.

Within the getInfo function, we try to access the block-scoped randomValue before the line on which we declare the variable. The "zone" within a block scope that cannot reference the variable yet, is called the temporal dead zone. When we try to reference an uninitialized variable, like we try to do by trying to log typeof randomValue, a ReferenceError gets thrown! ❌

How'd it go? Did you get all 3 right? If yes, awesome! 🎉 If you made some mistakes, no worries at all!

Hopefully you can learn something from the explanations, and take that new information into consideration the next time you may run into behavior that may seem "unexpected" 🙂

Feel free to reach out to me!

✨ Twitter

👩🏽‍💻 Instagram

💻 GitHub

💡 LinkedIn

📷 YouTube

💌 Email

⭐️ Interactive JavaScript Quiz #1

Lydia Hallie — Tue, 25 Feb 2020 18:16:05 +0000

We all know that JavaScript quizzes can be... awful and confusing 😐 The pointless foo bar baz questions ruin all the fun of JavaScript and often just cause even more confusion!

Last year, I made a GitHub Repo with tons of JavaScript questions that aren't questions like "tricky" or "NaN === NaN", but rather focus on more realistic situations. I thought it would be fun to make it into an interactive game series here on Dev.to, with animated explanations wherever possible! 🥳

lydiahallie / javascript-questions

A long list of (advanced) JavaScript questions, and their explanations ✨

Of course, the examples are still minimal and don't show "the best/most performant way to do it". Sometimes I have to do things a certain way in order to be able to show certain behavior that may happen, and explain it that way 🙂

1. What's the output?

Explanation

With the bind() and call() method, we can decide to which object the this keyword should refer. In this example, we're saying that the this keyword within the sayHi function should refer to the person object by calling both bind and call on the sayHi function 🥳

Although the bind() and call() methods both allow us to specify which object the this keyword should refer to, there's a tiny difference:

bind() only returns a copy of the bound function
call() executes the bound function immediately

First, we log sayHi.call(person, 21). The call method executes the (bound) function immediately, which results in Lydia is 21.

Then, we log sayHi.bind(person, 21). The bind method returns a copy of the bound function, meaning that we're simply logging a new, copied function 😃

2. What's the output?

Explanation

Whenever we declare a set a variable equal to an object, we're not actually giving that variable the value of that object. Instead, we're giving it the value of a reference (or actually pointer) to that object in memory! ⚡️

In this case, we give the person variable the value of a reference (pointer) to the object { name: "Lydia" } in memory.

Then, we declare a variable called members. The value of members is a reference to that array in memory!

The first element in the array that members has a reference to, is the object that person has a reference to. When we set objects equal to each other, we're actually creating a copy of the reference. This means that now person and the first element in the members array point to the same object in memory! 😃

Then, we set person equal to null. This means that person no longer has the value of the reference to the { name: "Lydia" } object in memory: it now has a reference to null! 🎉 Since the first element in the array that members has a reference to has its own, copied reference, the change of the value of person does not affect the first element in that array!

Since the first element in the members array still has a reference to the object { name: "Lydia" }, that object gets returned when logging the first element!

3. What's the output?

Explanation

We have a list of groceries! One item in this list is our favorite item, and one item in this list is our least favorite item.

First, we want to get the value of our favorite item, the grapes! One way of doing this, is by using the find() method. The find method returns the value of the item in the array that we're trying to find: the string with the grapes in this case "🍇". We assign the variable favoriteItem to that returned value.

Since the string "🍇" is a primitive data type (it's a string! 🥳), the string gets passed by value. This means that the value of favoriteItem is a copy of the item "🍇" in the groceries array, without containing any references to the groceries array.

We no longer want the grapes as our favorite item! Instead, we want to make the avocado "🥑" our favorite item. The variable favoriteItem gets reassigned with the value "🥑".

Then, we want to find the index of our least favorite food: the string with the cheese "🧀"! In order to find the index of the cheese, we can use the indexOf method. To the indexOf method, we pass the value of the element of which we're trying to get the index in the groceries array: "🧀" in this case.

Perfect! We now have the index of our least favorite item. Time to replace the least favorite item with some good food: a pizza "🍕". By replacing the value of the item on a specific index, we're modifying the groceries array.

Cool! We just changed the least favorite item in the groceries array. When logging the groceries array, ["🍅", "🍇", "🍕"] got returned.

How'd it go? Did you get all 3 right? If yes, awesome! 🎉 If you made some mistakes, no worries at all!

Hopefully you can learn something from the explanations, and take that new information into consideration the next time you may run into behavior that may seem "unexpected" 🙂

Feel free to reach out to me!

✨ Twitter

👩🏽‍💻 Instagram

💻 GitHub

💡 LinkedIn

📷 YouTube

💌 Email

💡🎁 JavaScript Visualized: Generators and Iterators

Lydia Hallie — Thu, 16 Jan 2020 05:22:29 +0000

ES6 introduced something cool called generator functions 🎉 Whenever I ask people about generator functions, the responses are basically: "I've seem them once, got confused, never looked at it again", "oh gosh no I've read so many blog posts about generator functions and I still don't get them", "I get them but why would anyone ever use that" 🤔 Or maybe that's just the conversations I've been having with myself because that's how I used to think for a long time! But they're actually quite cool.

So, what are generator functions? Let's first just look at a regular, old-fashioned function 👵🏼

Yep absolutely nothing special about this! It's just a normal function that logs a value 4 times. Let's invoke it!

"But Lydia why did you just waste 5 seconds of my life by making me look at this normal boring function", a very good question. Normal functions follow something called a run-to-completion model: when we invoke a function, it will always run until it completes (well, unless there's an error somewhere). We can't just randomly pause a function somewhere in the middle whenever we want to.

Now here comes the cool part: generator functions don't follow the run-to-completion model! 🤯 Does this mean that we can randomly pause a generator function in the middle of executing it? Well, sort of! Let's take a look at what generator functions are and how we can use them.

We create a generator function by writing an asterisk * after the function keyword.

But that's not all we have to do to use generator functions! Generator functions actually work in a completely different way compared to regular functions:

Invoking a generator function returns a generator object, which is an iterator.
We can use the yield keyword in a generator function to "pause" the execution.

But what does that even mean!?

Let's first go over the first one: Invoking a generator function returns a generator object. When we invoke a regular function, the function body gets executed and eventually returns a value. However when we invoke a generator function, a generator object gets returned! Let's see what that looks like when we log the returned value.

Now, I can hear you screaming internally (or externally 🙃) because this can look a little overwhelming. But don't worry, we don't really have to use any of the properties you see logged here. So what's the generator object good for then?

First we need to take a small step back, and answer the second difference between regular functions and generator functions: We can use the yield keyword in a generator function to "pause" the execution.

With generator functions, we can write something like this (genFunc is short for generatorFunction):

What's that yield keyword doing there? The execution of the generator gets "paused" when it encounters a yield keyword. And the best thing is that the next time we run the function, it remembered where it previously paused, and runs from there on! 😃 Basically what's happening here (don't worry this will be animated later on):

The first time it runs, it "pauses" on the first line and yields the string value '✨'
The second time it runs, it starts on the line of the previous yield keyword. It then runs all the way down till the second yield keyword and yields the value '💕'.
The third time it runs, it start on the line of the previous yield keyword. It runs all the way down until it encounters the return keyword, and returns the value 'Done!'.

But... how can we invoke the function if we previously saw that invoking the generator function returned a generator object? 🤔 This is where the generator object comes into play!

The generator object contains a next method (on the prototype chain). This method is what we'll use to iterate the generator object. However, in order to remember the state of where it previously left off after yielding a value, we need to assign the generator object to a variable. I'll call it genObj short for generatorObject.

Yep, the same scary looking object as we saw before. Let's see what happens when we invoke the next method on the genObj generator object!

The generator ran until it encountered the first yield keyword, which happened to be on the first line! It yielded an object containing a value property, and a done property.

```{

value: ... , done: ... }


The `value` property is equal to the value that we yielded.
The `done` property is a boolean value, which is only set to `true` once the generator function _*returned*_ a value (not yielded! 😊). 

We stopped iterating over the generator, which makes it look like the function just paused! How cool is that. Let's invoke the `next` method again! 😃

<img src="https://thepracticaldev.s3.amazonaws.com/i/e7hz87c6xtd31qjx19va.gif" /> 

First, we logged the string `First log!` to the console. This is neither a `yield` nor `return` keyword, so it continues! Then, it encountered a `yield` keyword with the value `'💕'`. An object gets _yielded_ with the `value` property of `'💕'` and a `done` property. The value of the `done` property is `false`, since we haven't _returned_ from the generator yet. 

We're almost there! Let's invoke `next` for the last time. 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/33epxsx8znmhm0qojsuu.gif)

We logged the string `Second log!` to the console.  Then, it encountered a `return` keyword with the value `'Done!'`. An object gets returned with the `value` property of `'Done!'`. We actually _returned_ this time, so the value of `done` is set to `true`! 

The `done` property is actually very important. **We can only iterate a generator object _once_.** What?! So what happens when we call the `next` method again? 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/wooo83by4eh12akmg5wb.gif)

It simply returns `undefined` forever. In case you want to iterate it again, you just have to create a new generator object!

---

As we just saw, a generator function returns an iterator (the generator object). But.. wait an _iterator_? Does that mean we can use `for of` loops, and the spread operator on the returned object? Yas! 🤩

Let's try to spread the yielded values in an array, using the `[... ]` syntax.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/xgk99j592vbx3qirw5or.gif)

Or maybe by using a `for of` loop?!

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/98k242jz3bqorkjhukwl.gif)

Heck so many possibilities! 

But what makes an iterator an iterator? Because we can also use `for-of` loops and the spread syntax with arrays, strings, maps, and sets. It's actually because they implement the _iterator protocol_: the `[Symbol.iterator]`. Say that we have the following values (with very descriptive names lol 💁🏼‍♀️):
<img width="500" src="https://thepracticaldev.s3.amazonaws.com/i/hs2sf1oj537c56yaej1h.png" />

The `array`, `string`, and `generatorObject` are all iterators! Let's take a look at the value of their `[Symbol.iterator]` property.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/a7inxsrvrp8ykg3xw6zu.gif)

But then what's the value of the `[Symbol.iterator]` on the values that aren't iterable? 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/tpuzuy58g8m7grxvqw8x.gif)

Yeah, it's just not there. So.. Can we simply just add the `[Symbol.iterator]` property manually, and make non-iterables iterable? Yes, we can! 😃

`[Symbol.iterator]` has to return an iterator, containing a `next` method which returns an object just like we saw before: `{ value: '...', done: false/true }`. 

To keep it simple (as lazy me likes to do) we can simply set the value of `[Symbol.iterator]` equal to a generator function, as this returns an iterator by default. Let's make the object an iterable, and the yielded value the entire object:
<img width="500" src="https://thepracticaldev.s3.amazonaws.com/i/oysyy7v71o2q9q9mrcsx.png" />

See what happens when we use the spread syntax or a for-of loop on our `object` object now!

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/pw2qq1tkfbp8zccuecac.gif)

Or maybe we only wanted to get the object keys. "Oh well that's easy, we just yield `Object.keys(this)` instead of `this`"! 
<img width="500" src="https://thepracticaldev.s3.amazonaws.com/i/ankit4dn67unnwzfkv9y.png" />

Hmm let's try that.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/75kf40lqcqrudzqgkeb7.gif)

Oh shoot. `Object.keys(this)` is an array, so the value that got yielded is an array. Then we spread this yielded array into another array, resulting in a nested array. We didn't want this, we just wanted to yield each individual key! 

Good news! 🥳 We can yield individual values from iterators within a generator using the `yield*` keyword, so the `yield` with an asterisk! Say that we have a generator function that first yield an avocado, then we want to yield the values of another iterator (an array in this case) individually. We can do so with the `yield*` keyword. We then _delegate_ to another generator! 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/jtyn5s5o3vdhjkbwwyb0.gif)

Each value of the delegated generator gets yielded, before it continued iterating the `genObj` iterator. 

This is exactly what we need to do in order to get all object keys individually! 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/btr4ytbb04c44qfs96v2.gif)

---

Another use of generator functions, is that we can (sort of) use them as observer functions. A generator can wait for incoming data, and only if that data is passed, it will process it. An example:
<img width="500" src="https://thepracticaldev.s3.amazonaws.com/i/fts36exs5chxacikjeo3.png" />

A big difference here is that we don't just have `yield [value]` like we saw in the previous examples. Instead, we assign a value called `second`, and yield value the string `First!`. This is the value that will get yielded the first time we call the `next` method.

Let's see what happens when we call the `next` method for the first time on the iterable. 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/ob5a4yi79it9q2ben137.gif)

It encountered the `yield` on the first line, and yielded the value `First!`. So, what's the value of the variable `second`? 

That's actually the value that we pass to the `next` method the _next time we call it_! This time, let's pass the string `'I like JavaScript'`.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/l1840pp2k9h9bgpt1geo.gif)

It's important to see here that the first invocation of the `next` method doesn't keep track of any input yet. We simply start the observer by invoking it the first time. The generator waits for our input, before it continues, and possibly processes the value that we pass to the `next` method. 

 ---

So why would you ever want to use generator functions? 

One of the biggest advantages of generators is the fact that they are **lazily evaluated**. This means that the value that gets returned after invoking the `next` method, is only computed after we specifically asked for it! Normal functions don't have this: all the values are generated for you in case you need to use it some time in the future. 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/7b24mkp7io3gmnn8pzwa.gif)

There are several other use cases, but I usually like to do it to have way more control when I'm iterating large datasets! 

Imagine we have a list of book clubs! 📚 To keep this example short and not one huge block of code, each book club just has one member. A member is currently reading several books, which is represented in the `books` array!

<img width="500" src="https://thepracticaldev.s3.amazonaws.com/i/8opapd1iddlgj1ljixje.png" />

Now, we're looking for a book with the id `ey812`. In order to find that, we could potentially just use a nested for-loop or a `forEach` helper, but that means that we'd still be iterating through the data even after finding the team member we were looking for!

The awesome thing about generators, is that it doesn't keep on running unless we tell it to. This means that we can evaluate each returned item, and if it's the item we're looking for, we simply don't call `next`! Let's see what that would look like.

First, let's create a generator that iterates through the `books` array of each team member. We'll pass the team member's `book` array to the function, iterate through the array, and yield each book!

<img width="500" src="https://thepracticaldev.s3.amazonaws.com/i/vokf28crwuvbmksd57m5.png" />

Perfect! Now we have to make a generator that iterates through the `clubMembers` array. We don't really care about the club member itself, we just need to iterate through their books. In the `iterateMembers` generator, let's delegate the `iterateBooks` iterator in order to just yield their books!

<img width="500" src="https://thepracticaldev.s3.amazonaws.com/i/fy8mxxjj0uvs6rarm6mi.png" />

Almost there! The last step is to iterate through the bookclubs. Just like in the previous example, we don't really care about the bookclubs themselves, we just care about the club members (and especially their books). Let's delegate the `iterateClubMembers` iterator and pass the `clubMembers` array to it.

<img width="500" src="https://thepracticaldev.s3.amazonaws.com/i/x1lor0omqw9t5k2kq4iv.png" />

In order to iterate through all this, we need to get the generator object iterable by passing the `bookClub` array to the `iterateBookClubs` generator. I'll just call the generator object `it` for now, for iterator.

<img width="500" src="https://thepracticaldev.s3.amazonaws.com/i/omg23omwi8a1d7nn1it3.png" />

Let's invoke the `next` method, until we get a book with the id `ey812`.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/72ghm4ev6el3no9esk1l.gif)

Nice! We didn't have to iterate through all the data in order to get the book we were looking for. Instead, we just looked for the data on demand! of course, calling the `next` method manually each time isn't very efficient... So let's make a function instead! 

Let's pass an `id` to the function, which is the id of the book we're looking for. If the `value.id` is the id we're looking for, then simply return the entire `value` (the book object). Else, if it's not the correct `id`, invoke `next` again!  
<img width="500" src="https://thepracticaldev.s3.amazonaws.com/i/hxyeemfr3q8pqqotk51j.png" />

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/x1zh0ygt5yfq5vb2f5at.gif)

Of course this was a tiny tiny data set. But just imagine that we have tons and tons of data, or maybe an incoming stream that we need to parse in order to just find one value. Normally, we'd have to wait for the entire dataset to be ready, in order to begin parsing. With generator functions, we can simply require small chunks of data, check that data, and the values are only generated when we invoke the `next` method! 

---

Don't worry if you're still all "what the heck is happening" mindset, generator functions are quite confusing until you've used them yourself and had some solid use cases for it! I hoped some terms are a bit clearer now, and as always: if you have any questions, feel free to reach out! 😃

<table>
  <tr>
 <td>✨ <a href="https://www.twitter.com/lydiahallie">Twitter</a></td>
<td>👩🏽‍💻 <a href="https://www.instagram.com/theavocoder">Instagram</a></td>
<td>💻 <a href="https://www.github.com/lydiahallie">GitHub</a></td>
<td>💡 <a href="https://www.linkedin.com/in/lydia-hallie">LinkedIn</a></td>
<td>📷 <a href="https://www.youtube.com/channel/UC4EWKIKdKiDtAscQ9BIXwUw">YouTube</a></td>
<td>💌 <a href=mailto:lydiahallie.dev@gmail.com">Email</a></td>

</tr>
</table>

🎉👨‍👩‍👧‍👧 JavaScript Visualized: Prototypal Inheritance

Lydia Hallie — Fri, 03 Jan 2020 08:26:18 +0000

Ever wondered why we can use built-in methods such as .length, .split(), .join() on our strings, arrays, or objects? We never explicitly specified them, where do they come from? Now don't say "It's JavaScript lol no one knows, it's magic 🧚🏻‍♂️", it's actually because of something called prototypal inheritance. It's pretty awesome, and you use it more often than you realize!

We often have to create many objects of the same type. Say we have a website where people can browse dogs!

For every dog, we need object that represents that dog! 🐕 Instead of writing a new object each time, I'll use a constructor function (I know what you're thinking, I'll cover ES6 classes later on!) from which we can create Dog instances using the new keyword (this post isn't really about explaining constructor functions though, so I won't talk too much about that).

Every dog has a name, a breed, a color, and a function to bark!

When we created the Dog constructor function, it wasn't the only object we created. Automatically, we also created another object, called the prototype! By default, this object contains a constructor property, which is simply a reference to the original constructor function, Dog in this case.

The prototype property on the Dog constructor function is non-enumerable, meaning that it doesn't show up when we try to access the objects properties. But it's still there!

Okay so.. Why do we have this property object? First, let's create some dogs that we want to show. To keep it simple, I'll call them dog1 and dog2. dog1 is Daisy, a cute black Labrador! dog2 is Jack, the fearless white Jack Russell 😎

Let's log dog1 to the console, and expand its properties!

We see the properties we added, like name, breed, color, and bark.. but woah what is that __proto__ property! It's non-enumerable, meaning that it usually doesn't show up when we try to get the properties on the object. Let's expand it! 😃

Woah it looks exactly like the Dog.prototype object! Well guess what, __proto__ is a reference to the Dog.prototype object. This is what prototypal inheritance is all about: each instance of the constructor has access to the prototype of the constructor! 🤯

So why is this cool? Sometimes we have properties that all instances share. For example the bark function in this case: it's the exact same for every instance, why create a new function each time we create a new dog, consuming memory each time? Instead, we can add it to the Dog.prototype object! 🥳

Whenever we try to access a property on the instance, the engine first searches locally to see if the property is defined on the object itself. However, if it can't find the property we're trying to access, the engine walks down the prototype chain through the __proto__ property!

Now this is just one step, but it can contain several steps! If you followed along, you may have noticed that I didn't include one property when I expanded the __proto__ object showing Dog.prototype. Dog.prototype itself is an object, meaning that it's actually an instance of the Object constructor! That means that Dog.prototype also contains a __proto__ property, which is a reference to Object.prototype!

Finally, we have an answer to where all the built-in methods come from: they're on the prototype chain! 😃

For example the .toString() method. Is it defined locally on the dog1 object? Hmm no.. Is it defined on the object dog1.__proto__ has a reference to, namely Dog.prototype? Also no! Is it defined on the object Dog.prototype.__proto__ has a reference to, namely Object.prototype? Yes! 🙌🏼

Now, we've just been using constructor functions (function Dog() { ... }), which is still valid JavaScript. However, ES6 actually introduced an easier syntax for constructor functions and working with prototypes: classes!

Classes are only syntactical sugar for constructor functions. Everything still works the same way!

We write classes with the class keyword. A class has a constructor function, which is basically the constructor function we wrote in the ES5 syntax! The properties that we want to add to the prototype, are defined on the classes body itself.

Another great thing about classes, is that we can easily extend other classes.

Say that we want to show several dogs of the same breed, namely Chihuahuas! A chihuahua is (somehow... 😐) still a dog. To keep this example simple, I'll only pass the name property to the Dog class for now instead of name, breed and color. But these chihuahuas can also do something special, they have a small bark. Instead of saying Woof!, a chihuahua can also say Small woof! 🐕

In an extended class, we can access the parent class' constructor using the super keyword. The arguments the parent class' constructor expects, we have to pass to super: name in this case.

myPet has access to both the Chihuahua.prototype and Dog.prototype (and automatically Object.prototype, since Dog.prototype is an object).

Since Chihuahua.prototype has the smallBark function, and Dog.prototype has the bark function, we can access both smallBark and bark on myPet!

Now as you can imagine, the prototype chain doesn't go on forever. Eventually there's an object which prototype is equal to null: the Object.prototype object in this case! If we try to access a property that's nowhere to be found locally or on the prototype chain, undefined gets returned.

Although I explained everything with constructor functions and classes here, another way to add prototypes to objects is with the Object.create method. With this method, we create a new object, and can specify exactly what the prototype of that object should be! 💪🏼

We do this, by passing an existing object as argument to the Object.create method. That object is the prototype of the object we create!

Let's log the me object we just created.

We didn't add any properties to the me object, it simply only contains the non-enumerable __proto__ property! The __proto__ property holds a reference to the object we defined as the prototype: the person object, which has a name and an age property. Since the person object is an object, the value of the __proto__ property on the person object is Object.prototype (but to make it a bit easier to read, I didn't expand that property in the gif!)

Hopefully, you now understand why prototypal inheritance is such an important feature in the wonderful world of JavaScript! If you have questions, feel free to reach out to me! 😊

✨ Twitter

👩🏽‍💻 Instagram

💻 GitHub

💡 LinkedIn

📷 YouTube

💌 Email

🚀⚙️ JavaScript Visualized: the JavaScript Engine

Lydia Hallie — Fri, 13 Dec 2019 07:47:14 +0000

JavaScript is cool (don't @ me), but how can a machine actually understand the code you've written? As JavaScript devs, we usually don't have to deal with compilers ourselves. However, it's definitely good to know the basics of the JavaScript engine and see how it handles our human-friendly JS code, and turns it into something machines understand! 🥳

| Note: This post is mainly based on the V8 engine used by Node.js and Chromium-based browsers.

The HTML parser encounters a script tag with a source. Code from this source gets loaded from either the network, cache, or an installed service worker. The response is the requested script as a stream of bytes, which the byte stream decoder takes care of! The byte stream decoder decodes the stream of bytes as it’s being downloaded.

The byte stream decoder creates tokens from the decoded stream of bytes. For example, 0066 decodes to f, 0075 to u, 006e to n, 0063 to c, 0074 to t, 0069 to i, 006f to o, and 006e to n followed by a white space. Seems like you wrote function! This is a reserved keyword in JavaScript, a token gets created, and sent to the parser (and pre-parser, which I didn't cover in the gifs but will explain later). The same happens for the rest of the byte stream.

The engine uses two parsers: the pre-parser, and the parser. In order to reduce the time it takes to load up a website, the engine tries to avoid parsing code that's not necessary right away. The preparser handles code that may be used later on, while the parser handles the code that’s needed immediately! If a certain function will only get invoked after a user clicks a button, it's not necessary that this code is compiled immediately just to load up a website. If the user eventually ends up clicking the button and requiring that piece of code, it gets sent to the parser.

The parser creates nodes based on the tokens it receives from the byte stream decoder. With these nodes, it creates an Abstract Syntax Tree, or AST. 🌳

Next, it's time for the interpreter! The interpreter which walks through the AST, and generates byte code based on the information that the AST contains. Once the byte code has been generated fully, the AST is deleted, clearing up memory space. Finally, we have something that a machine can work with! 🎉

Although byte code is fast, it can be faster. As this bytecode runs, information is being generated. It can detect whether certain behavior happens often, and the types of the data that’s been used. Maybe you've been invoking a function dozens of times: it's time to optimize this so it'll run even faster! 🏃🏽‍♀️

The byte code, together with the generated type feedback, is sent to an optimizing compiler. The optimizing compiler takes the byte code and type feedback, and generates highly optimized machine code from these. 🚀

JavaScript is a dynamically typed language, meaning that the types of data can change constantly. It would be extremely slow if the JavaScript engine had to check each time which data type a certain value has.

In order to reduce the time it takes to interpret the code, optimized machine code only handles the cases the engine has seen before while running the bytecode. If we repeatedly used a certain piece of code that returned the same data type over and over, the optimized machine code can simply be re-used in order to speed things up. However, since JavaScript is dynamically typed, it can happen that the same piece of code suddenly returns a different type of data. If that happens, the machine code gets de-optimized, and the engine falls back to interpreting the generated byte code.

Say a certain function is invoked a 100 times and has always returned the same value so far. It will assume that it will also return this value the 101st time you invoke it.

Let’s say that we have the following function sum, that’s (so far) always been called with numerical values as arguments each time:

This returns the number 3! The next time we invoke it, it will assume that we’re invoking it again with two numerical values.

If that’s true, no dynamic lookup is required, and it can just re-use the optimized machine code. Else, if the assumption was incorrect, it will revert back to the original byte code instead of the optimized machine code.

For example, the next time we invoke it, we pass a string instead of a number. Since JavaScript is dynamically typed, we can do this without any errors!

This means that the number 2 will get coerced into a string, and the function will return the string "12" instead. It goes back to executing the interpreted bytecode and updates the type feedback.

I hope this post was useful to you! 😊 Of course, there are many parts to the engine that I haven't covered in this post (JS heap, call stack, etc.) which I might cover later! I definitely encourage you to start to doing some research yourself if you're interested in the internals of JavaScript, V8 is open source and has some great documentation on how it works under the hood! 🤖

V8 Docs || V8 Github || Chrome University 2018: Life Of A Script

Feel free to reach out to me! Twitter || Instagram || GitHub || LinkedIn

FAQ: I use Keynote to make the animations and screen record it lol. Feel free to translate this blog to your language, and thanks so much for doing so! Just keep a reference to the original article and let me know if you've translated it please! 😊

⚡️⛓JavaScript Visualized: Scope (Chain)

Lydia Hallie — Wed, 20 Nov 2019 07:12:21 +0000

Time for the scope chain 🕺🏼 In this post I assume you know the basics of execution contexts: I’ll soon write a post on that too though 😃

Let's take a look at the following code:



const name = "Lydia"
const age = 21
const city = "San Francisco"


function getPersonInfo() {
  const name = "Sarah"
  const age = 22

  return `${name} is ${age} and lives in ${city}`
}

console.log(getPersonInfo())

We're invoking the getPersonInfo function, which returns a string containing the values of the name, age and city variables:
Sarah is 22 and lives in San Francisco. But, the getPersonInfo function doesn't contain a variable named city 🤨? How did it know the value of city?

First, memory space is set up for the different contexts. We have the default global context (window in a browser, global in Node), and a local context for the getPersonInfo function which has been invoked. Each context also has a scope chain.

For the getPersonInfo function, the scope chain looks something like this (don't worry, it doesn't have to make sense just yet):

The scope chain is basically a "chain of references" to objects that contain references to values (and other scopes) that are referencable in that execution context. (⛓: "Hey, these are all the values you can reference from within this context".) The scope chain gets created when the execution context is created, meaning it's created at runtime!

However, I won't talk about the activation object or the execution contexts in general in this post, let's just focus on scope! In the following examples, the key/value pairs in the execution contexts represent the references that the scope chain has to the variables.

The scope chain of the global execution context has a reference to 3 variables: name with the value Lydia, age with the value 21, and city with the value San Francisco. In the local context, we have a reference to 2 variables: name with the value Sarah, and age with the value 22.

When we try to access the variables in the getPersonInfo function, the engine first checks the local scope chain.

The local scope chain has a reference to name and age! name has the value of Sarah and age has the value of 22. But now, what happens when it tries to access city?

In order to find the value for city the engine "goes down the scope chain". This basically just means that the engine doesn't give up that easily: it works hard for you to see if it can find a value for the variable city in the outer scope that the local scope has a reference to, the global object in this case.

In the global context, we declared the variable city with the value of San Francisco, thus has a reference to the variable city. Now that we have a value for the variable, the function getPersonInfo can return the string Sarah is 22 and lives in San Francisco 🎉

We can go down the scope chain, but we can't go up the scope chain. (Okay this may be confusing because some people say up instead of down, so I'll just rephrase: You can go to outer scopes, but not to more inner... (innerer..?) scopes. I like to visualize this as a sort of waterfall:

Or even deeper:

Let's take this code as an example.

It's almost the same, however there's one big difference: we only declared city in the getPersonInfo function now, and not in the global scope. We didn't invoke the getPersonInfo function, so no local context is created either. Yet, we try to access the values of name, age and city in the global context.

It throws a ReferenceError! It couldn't find a reference to a variable called city in the global scope, and there were no outer scopes to look for, and it cannot go up the scope chain.

This way, you can use scope as a way to "protect" your variables and re-use variable names.

Besides global and local scopes, there is also a block scope. Variables declared with the let or const keyword are scoped to the nearest curly brackets ({}).



const age = 21

function checkAge() {
  if (age < 21) {
    const message = "You cannot drink!"
    return message
  } else {
    const message = "You can drink!"
    return message
  }
}

You can visualize the scopes as:

We have a global scope, a function scope, and two block scopes. We were able to declare the variable message twice, since the variables were scoped to the curly brackets.

To quickly recap:

You can see "scope chain" as a chain of references to values that we can access in the current context.
Scopes also make it possible to re-use variable names that were defined further down the scope chain, since it can only go down the scope chain, not up.

That was it for scope (chains)! There's tons more to say about this so I may add extra info when I have some free time. Feel free to ask questions if you're struggling with anything, I love to help! 💕

🔥🕺🏼 JavaScript Visualized: Hoisting

Lydia Hallie — Wed, 20 Nov 2019 07:12:16 +0000

Hoisting is one of those terms that every JS dev has heard of because you googled your annoying error and ended up on StackOverflow, where this person told you that this error was caused because of hoisting 🙃 So, what is hoisting? (FYI - scope will be covered in another post, I like to keep posts small and focused)

If you’re new to JavaScript, you may have experienced “weird” behavior where some variables are randomly undefined, ReferenceErrors get thrown, and so on. Hoisting is often explained as putting variables and functions to the top of the file but nah, that’s not what’s happening, although the behavior might seem like it 😃

When the JS engine gets our script, the first thing it does is setting up memory for the data in our code. No code is executed at this point, it’s simply just preparing everything for execution. The way that function declarations and variables are stored is different. Functions are stored with a reference to the entire function.

With variables, it’s a bit different. ES6 introduced two new keywords to declare variables: let and const. Variables declared with the let or const keyword are stored uninitialized.

Variables declared with the var keyword are stored with the default value of undefined.

Now that the creation phase is done, we can actually execute the code. Let's see what happens if we had 3 console.log statements on top of the file, before we declared the function or any of the variables.

Since functions are stored with a reference to the entire function code, we can invoke them even before the line on which we created them! 🔥

When we reference a variable declared with the var keyword before their declaration, it’ll simply return its default value that it was stored with: undefined! However, this could sometimes lead to "unexpected" behavior. In most cases this means you’re referencing it unintentionally (you probably don’t want it to actually have the value of undefined) 😬

In order to prevent being able to accidentally reference an undefined variable, like we could with the var keyword, a ReferenceError gets thrown whenever we try to access uninitialized variables. The "zone" before their actual declaration, is called the temporal dead zone: you cannot reference the variables (this includes ES6 classes as well!) before their initialization.

When the engine passes the line on which we actually declared the variables, the values in memory are overwritten with the values we actually declared them with.

(Oops I notice now this should be number 7. Will update asap 😬)

All done! 🎉 Quick recap:

Functions and variables are stored in memory for an execution context before we execute our code. This is called hoisting.
Functions are stored with a reference to the entire functions, variables with the var keyword with the value of undefined, and variables with the let and const keyword are stored uninitialized.

I hope that the term hoisting is a bit less vague now that we've looked at what's happening when we execute our code. As always, don't worry if it still doesn't make a lot of sense yet. You'll get a lot more comfortable with it the more you work with it. Feel free to ask me for help, I'd love to help you! 😃

✨♻️ JavaScript Visualized: Event Loop

Lydia Hallie — Wed, 20 Nov 2019 07:12:11 +0000

If you're here in 2024 (or later), here's an updated blog post!](https://lydiahallie.com/blog/event-loop)

Oh boi the event loop. It’s one of those things that every JavaScript developer has to deal with in one way or another, but it can be a bit confusing to understand at first. I’m a visual learner so I thought I’d try to help you by explaining it in a visual way through low-res gifs because it's 2019 and gifs are somehow still pixelated and blurry.

But first, what is the event loop and why should you care?

JavaScript is single-threaded: only one task can run at a time. Usually that’s no big deal, but now imagine you’re running a task which takes 30 seconds.. Ya.. During that task we’re waiting for 30 seconds before anything else can happen (JavaScript runs on the browser’s main thread by default, so the entire UI is stuck) 😬 It’s 2019, no one wants a slow, unresponsive website.

Luckily, the browser gives us some features that the JavaScript engine itself doesn’t provide: a Web API. This includes the DOM API, setTimeout, HTTP requests, and so on. This can help us create some async, non-blocking behavior 🚀

When we invoke a function, it gets added to something called the call stack. The call stack is part of the JS engine, this isn’t browser specific. It’s a stack, meaning that it’s first in, last out (think of a pile of pancakes). When a function returns a value, it gets popped off the stack 👋

The respond function returns a setTimeout function. The setTimeout is provided to us by the Web API: it lets us delay tasks without blocking the main thread. The callback function that we passed to the setTimeout function, the arrow function () => { return 'Hey' } gets added to the Web API. In the meantime, the setTimeout function and the respond function get popped off the stack, they both returned their values!

In the Web API, a timer runs for as long as the second argument we passed to it, 1000ms. The callback doesn’t immediately get added to the call stack, instead it’s passed to something called the queue.

This can be a confusing part: it doesn't mean that the callback function gets added to the callstack(thus returns a value) after 1000ms! It simply gets added to the queue after 1000ms. But it’s a queue, the function has got to wait for its turn!

Now this is the part we’ve all been waiting for… Time for the event loop to do its only task: connecting the queue with the call stack! If the call stack is empty, so if all previously invoked functions have returned their values and have been popped off the stack, the first item in the queue gets added to the call stack. In this case, no other functions were invoked, meaning that the call stack was empty by the time the callback function was the first item in the queue.

The callback is added to the call stack, gets invoked, and returns a value, and gets popped off the stack.

Reading an article is fun, but you'll only get entirely comfortable with this by actually working with it over and over. Try to figure out what gets logged to the console if we run the following:




const foo = () => console.log("First");
const bar = () => setTimeout(() => console.log("Second"), 500);
const baz = () => console.log("Third");

bar();
foo();
baz();

Got it? Let's quickly take a look at what's happening when we're running this code in a browser:

We invoke bar. bar returns a setTimeout function.
The callback we passed to setTimeout gets added to the Web API, the setTimeout function and bar get popped off the callstack.
The timer runs, in the meantime foo gets invoked and logs First. foo returns (undefined),baz gets invoked, and the callback gets added to the queue.
baz logs Third. The event loop sees the callstack is empty after baz returned, after which the callback gets added to the call stack.
The callback logs Second.

Hope that this makes you feel a bit more comfortable with the event loop! Don't worry if it still seems confusing, the most important thing is to understand where certain errors/behavior can come from in order to Google the right terms efficiently and end up on the correct Stack Overflow page 💪🏼 Feel free to reach out to me if you have any questions!

DEV Community: Lydia Hallie

✋🏼🔥 CS Visualized: CORS

✋🏼 Same-Origin Policy

🔥 Client-side CORS

💻 Server-side CORS

🚀 Preflighted Requests

🍪 Credentials

⭐️🎀 JavaScript Visualized: Promises & Async/Await

✨♻️ JavaScript Visualized: Event Loop

Lydia Hallie ・ Nov 20 '19

Introduction

Promise Syntax

Microtasks and (Macro)tasks

Async/Await

domenic / promises-unwrapping

The ES6 promises spec, as per September 2013 TC39 meeting

🌳🚀 CS Visualized: Useful Git Commands

Merging

Fast-forward (--ff)

No-fast-foward (--no-ff)

Merge Conflicts

Rebasing

Interactive Rebase

Resetting

Soft reset

Hard reset

Reverting

Cherry-picking

Fetching

Pulling

Reflog

⭐️ Interactive JavaScript Quiz #2

💡🎁 JavaScript Visualized: Generators and Iterators

Lydia Hallie ・ Jan 16 '20

🎉👨‍👩‍👧‍👧 JavaScript Visualized: Prototypal Inheritance

Lydia Hallie ・ Jan 3 '20

lydiahallie / javascript-questions

A long list of (advanced) JavaScript questions, and their explanations ✨

1. What's the output?

Explanation

2. What's the output?

Explanation

3. What's the output?

Explanation

⭐️ Interactive JavaScript Quiz #1

lydiahallie / javascript-questions

A long list of (advanced) JavaScript questions, and their explanations ✨

1. What's the output?

Explanation

2. What's the output?

Explanation

3. What's the output?

Explanation

💡🎁 JavaScript Visualized: Generators and Iterators

🎉👨‍👩‍👧‍👧 JavaScript Visualized: Prototypal Inheritance

🚀⚙️ JavaScript Visualized: the JavaScript Engine

⚡️⛓JavaScript Visualized: Scope (Chain)

🔥🕺🏼 JavaScript Visualized: Hoisting

✨♻️ JavaScript Visualized: Event Loop

Fast-forward (`--ff`)

No-fast-foward (`--no-ff`)