DEV Community: jessrichmond

💾 ✨ Eager loading: in database queries and also in skill growth

jessrichmond — Tue, 17 Nov 2020 18:26:57 +0000

Well folks, my coding bootcamp experience is almost over. I’ve spent the past seven months hustling to learn full-stack Javascript, and it has culminated in a three week long thesis project in which I worked on a team to develop Goldilocks, a web application for users to facilitate one-to-one room swaps (think Airbnb sans exploitation and/or very short term, reciprocal subletting).

Goldilocks is a full stack application; we used React.js on the front end, Node.js and Express server-side, and Postgres with Sequelize for our database handling. While our database was nowhere near being classified as complex, it was the most nuanced approach anyone on my team had ever been faced with, and while a bit overwhelming at first glance, it was my favorite aspect of the project especially because I developed what I think are some really solid habits that lend themselves to best practice.

My database handling practice has come such a long way in the past couple of months (and it still has, undoubtedly, a lot of room for growth!). It’s sweet to reflect on how it has evolved & how my skills have, in time, loaded:

In my first semi-autonomous project, I was setting up components on the front end that made HTTP requests via Axios to the database, which then sent the response back to the front end, where I waited for that response to make another request to the database...
This approach was getting me the responses I was looking for, but I had a feeling that this wasn’t right. On my second project, a teammate helped me realize that that should all be done on the backend. I consolidated my requests a bit in that only one HTTP request was being made to the database from the frontend, but the code on the backend was a mess! I was chaining queries to other queries, and oh boy, there were many lines of code to be had.
This also did not feel right! It was easy to get lost in the code and be unsure of what response was coming back from where, so when it was time to get started on Goldilocks, I did some research into more efficient database querying. My crown jewel was discovering “eager loading” and learning that all of the database queries associated with one specific request from the frontend could be bundled into a singular response.

It took me a couple of tries to get it right. For it to work as intended, all model associations need to be set up properly, so my team and I had to go back and update our foreign keys (Postgres uses camelCase by default and not snake_case like we thought!) and then ensure all of our hasOne / hasMany / belongsTo / belongsToMany statements accurately demonstrated the relationships we were setting up. It was a hurdle having to go back and do that, but I knew that taking time to go back and adjust our models would pay off once we could integrate eager loading into our database query workflow. Once we got everything reconfigured, I could not stop singing the praises of eager loading! And what is even funnier is that four months ago, I was convinced that backend was not for me! I'm now finding myself getting fixated on learning more about query performance and being confident in my choices of data handling, and now that Goldilocks development is being put on hiatus & my program is wrapping up, I'm excited to transfer what I've learned thus far into a career.

Thanks for reading for the past couple of months y'all. Ttyl.

Exploring Mastodon & Thinking about the Decentralized Web 🌀 🌈

jessrichmond — Tue, 10 Nov 2020 07:02:24 +0000

Would I be the person I am today had I not spent hours and hours on the Internet as a young teen in the mid to late 2000s scrolling through sites like Myspace and Tumblr? I honestly do not think so! Having the opportunity to effortlessly interact with people my age from all over the world was wild! That time online genuinely broadened my imagination & I will always think fondly of my online experiences during those formative years. However, it feels like this experience is out of reach these days - and I don't think it's only because I'm older. Social media networks have grown exponentially and with sites like Facebook, Instagram, and Twitter, it’s become a far lot less about connecting with others than it has become about raking in revenue. While my desire to use these platforms has diminished, my desire to connect with my friends and other people I share interests with has not. I would just rather my data not be owned by corporations who are trying exploit that data in order to meet financial benchmarks.

Cue Mastodon. Cue decentralized networking apps. Cue the Fediverse!

(We are not talking about the metal band Mastodon here).

Mastodon is an open source microblogging project that wants to put social networking into the hands of its users. Similar to apps like Twitter and Tumblr, users share short messages called toots & follow other users to read (and boost) their toots. Dissimilar to apps like Twitter and Tumblr (and really any other huge corporate social media platform), Mastodon is not a central hub - rather, it is a network of connected servers, referred to as instances.

It is during the signup process for Mastodon that you select (or apply to) the server you want to be a member of; each server transparently lays out its purpose + values + guidelines, making it easy for new users to find their place.

Once you are a member of a server, you’ll be able to pick and choose the other folks on your server you’re interested in following. You’ll be able to see their toots, of course, but because each Mastodon server can communicate with other Mastodon servers, as mentioned before, you can be signed up one server and still easily interact with users on other servers.

This configuration fits into the federated model of decentralization (hence, Mastodon’s belonging in the Fediverse), and this model can be best explained by a comparison to email. Because all email servers use the same protocol to communicate, it ultimately does not matter which email provider you use. I can have a Gmail account and send a message to someone with an AOL account (my mom, probably) and it will go off without a hitch because those providers speak the same language.

A very similar thing is happening in the Fediverse. Mastodon, and other federated platforms, communicate using ActivityPub which defines how servers handle new user posts & how they can be interacted with. Any platform or application that implements ActivityPub is accessible to you on your Mastodon server. Imagine being able to log into one place and have your Facebook, Instagram, Youtube, and Twitter feed all in one place. That’d never happen because of corporate greed, but with the Fediverse you can do that. ActivityPub allows users to configure their experience on Mastodon (or any federated app) to not only interact with users on other Mastodon servers but also to include content from video platforms like Peertube and Funkwhale, image hosting platforms like Pixelfed, and blogging platforms like Plume or Write.as.

So what happens if you nose around on Mastodon and don’t find a server that suits your particular needs and desires? Well friend, head on over to the Mastodon code on Github and fork that baby down. Set up a new Mastodon instance to your preference & then define the vision and rules of that instance. Invite your friends, invite your family, invite your neighbors! Update your fork with personalized custom features. You are the leader - even if only temporarily - here; build/help build a meaningful community.

It is worth noting that setting up your own Mastodon instance is not a zero cost project. If you limit the size of your server, it is not an insanely expensive endeavor but do keep in mind that running a Mastodon (or any other ActivityPub app) instance comes with the cost of running and maintaining servers. Purposefully not generating ad revenue is pretty crucial to the premise of decentralized social networks; the operating cost of a Mastodon server is usually crowd funded by its users.

While Mastodon and other apps in the Fediverse are likely to never replace to the huge social media giants, I think I’m ok with that! Whereas Facebook has over a billion users, Mastodon only has about 2 million users spread out over 6500 instances worldwide; clearly this indicates that there’s an interest for something else and more community driven and & you can count me in that number. I’m looking forward to exploring Mastodon once I find myself with some more free time (coming soon!) and I’d encourage you to do the same.

I’d also like to shout out to Darius Kazemi and his moral + approachably technical guide to setting up your own social network on Mastodon, which is where I was introduced to this subject. You can (you should!) read that here.

Ps, header image was in part sourced via wildflowersbot@botsin.space, a bot on Mastodon that generates digital vistas of wildflowers. Way cool.

Reflections on Accessibility as a Budding Software Engineer

jessrichmond — Wed, 28 Oct 2020 15:49:52 +0000

The end of my coding bootcamp is approaching and it really feels like we - my cohort mates and I - are scaling up: in skill development, in project scope, in preparing for career transitions. While we’ve still got a bit of work ahead of us before we finish our program, it does feel like we are in the clear from most of the Immersion madness. Now that we are regaining our free time & our mental energy and are able to be a bit more thoughtful and reflective on the software dev work we are doing and want to do, we must get in the habit of thinking about how other people - especially people who have wonderfully different perspectives - will interact with & be affected by our web apps. We’ve got to get in the habit of developing with inclusivity and accessibility in mind.

When people hear about making the web accessible for disabled people, maybe the most immediate thought is “ok, how can I make my site accessible to someone who is blind and cannot see it?” However, the spectrum of functional disability is vast. There are 61 million people in the United States living with a disability and those disabilities range from mobility to cognition to independent living and self care; sometimes these disabilities are temporary, sometimes they are lifelong. When developing our apps, we must shift our perspective to consider what issues disabled people might face when using these apps and we must strive to eliminate those barriers… if we don’t, we are effectively excluding 25% of the US population.

This has been recognized by the World Wide Web Consortium (W3C) since the mid 1990s. They are the main international standards organization for the Internet, and in 1999, W3C released the first edition of the Web Content Accessibility Guides (WCAG); in 2008, they expanded on those guidelines and released WCAG 2.0.

WCAG mandates that websites be POUR: that is, perceivable, operable, understandable, and robust to its users. Let’s touch briefly on these four principles.

To be perceivable, a website should:

Provide text alternatives for any non-text content
Provide alternatives for time based media like video and audio
Create content that can be presented in different ways without losing its integrity ie its meaning or structure
Make it easier for users to see and hear content

To be operable, a website should:

Be fully operable via keyboard
Give users ample time to read and use content
Not be designed in a way that is known to trigger seizures
Help users navigate, find content, and determine where they are

To be understandable, a website should:

Make text easy to physically read and mentally comprehend
Be predictable and both appearance and functionality
Help users avoid mistakes and correct them if they occur

To be robust, a website should:

Be as compatible as possible with various user agents, such as assistive technologies

There are three levels for complying with WCAG guidelines: A, AA, and AAA. If a website is Level A, congrats. They have done the absolute bare minimum in following federal guidelines and are providing the most basic web accessibility features. What everyone in the the professional software dev world should instead be striving for is at least Level AA, which addresses the most common barriers for disabled web users. Level AAA can be achieved by providing the most complex and comprehensive level of web accessibility. Being AAA compliant is no easy feat, but there are a couple of features that are easy to implement in an already AA compliant environment - here's a link to WCAG's overview where you can familiarize yourself with accessible features.

Get in the habit of thinking about these things. Take one for the team. Show some empathy. What we are designing and developing as software engineers has the potential to impact people’s lives in meaningful ways. Let’s leave this world better than we found it.

Testing APIs & Getting the Most Out of Your Postman Workflow

jessrichmond — Mon, 19 Oct 2020 04:44:05 +0000

🔍 On being exposed to API requests for the first time

When setting up an app that will rely on third party APIs, it is important to make sure that whatever API you’re interested in will give you the data that you are after. You could go straight to your code and make requests to the API from your server and log to the console until you pinpoint the query you need to make to receive the response you want, but this would involve restarting your server and/or refreshing your webpage at least once but most likely way more than only once.

This is how my introduction to API calls went. I wasted a whole lot of time refreshing and revising before being satisfied with the response I’d receive from the API, and for a while, I accepted this fate. An instructor had introduced us to Postman without providing much context, so it took a while before I began to grasp what a helpful tool API clients (!!! Postman) can be for project setup. Now that I'm officially a fan of Postman, I encourage you to learn the ins and outs as well.

✨ Streamlining the process with Postman

So! Open up your desktop Postman app and follow along. Let's work to make this process as seamless as we can make it. When starting a new project, you'll want to set up a new workspace for you and your team members.

Create a workspace, name it whatever your heart desires, and invite your teammates via email. Once you have confirmed you are in that workspace, create a collection (this will be accessible by everyone on your team) and populate it with API requests. I've seen folks organize group their requests in collections according a specific method of required authentication, but as someone currently working on small projects that require only a handful of calls, I create my collections to reflect my projects.

Here are two projects I've recently worked on. On the Road is an app that maps out public campsites for people on road trips based on the number of hours they are willing to drive everyday until they reach their destination. Information for these campsites is retrieved using APIs from Recreation.gov and Reserve America. Radma was built as a resource to connect with one's local music scene. When my team inherited this legacy code, I added a tool to discover music based on genres a fan is interested in; this was done using Spotify's API.

🗝 API requests, authentication methods, & shortcuts

Before I plugged any of these APIs into my code, I used Postman to run tests to help me figure out how to access their data. The first API I tested - from Recreation.gov - could not have been more straightforward. It's an API that does not require authentication, so all I had to do was set the parameters to get the response I was looking for.

The Reserve America API, on the other hand, did require authentication but only by way of an API key. This was as simple as signing up for a free developer account & adding the assigned API key as a parameter in my requests.

Dialing in on the connection between a user's input and the request that would then be sent off to the API took a couple of days to complete. What proved to be the most helpful / biggest takeaway from working with these two APIs within Postman was realizing I could save all of my API requests to a collection. Being able to save my spot where I left off to pick up at a later time was helpful in not needing to repeatedly reference the API docs.

What also helped me streamline my workflow was realizing I could set my credentials as environmental variables. This allowed me to not only securely store my credentials but also made them really easy to reuse across requests.

Pasting my API key into the parameters of my requests to the Reserve America API was not the most tedious I've done in my coding journey, but once I started working with a third party API that required OAuth 2.0, I knew I needed to figure out a more efficient method.

Whereas an API key will generally remain the same for a project, OAuth2.0 requires that you use a client id & secret (password) to obtain an access token which will then grant you access to an API's data. The API dictates the amount of time an access token is valid for, so when testing an API that requires OAuth 2.0, it’s likely that you’ll have to frequently request a new access token. While I knew that, in my code, I'd have to figure out how to run two requests for the authorization flow (a POST request to receive access token that would allow me to send a GET request to receive music data), I appreciate that Postman simplifies this process for you while in testing. Navigating over to the 'Authorization' and selecting OAuth2.0 prompted me to set up the required information to gain an access token, and while I had to get a new access token every hour I was testing, it was not a huge inconvenience as Postman holds on to that required information for you.

💭 Final reflections

While you will probably never find me fretting about the hours I've wasted in my life doing x, y, and z and/or trying out the latest productivity hack, I've got to hand it to Postman for offering such a simple solution to API testing optimization as it has really allowed me to find my flow when setting up a new project. It is my hope, dear reader, that this post has demystified for you the magical tool that is Postman and that you feel a bit more equipped to process some data. Ciao.

Node.js & the Promise That Callback Hell Can Be Avoided

jessrichmond — Tue, 15 Sep 2020 05:05:02 +0000

Last week we saw an introduction to databases and servers where we were introduced to Node.js - an open source runtime envrionment that provides Javascript web developers with tools to talk to networks, file systems, and other input/output (I/O) sources.

We learned that one of the key features of Node.js is the ability to run functions asynchronously. Whereas the vanilla Javascript training wheels we’ve been rolling often had us reading a file of code from top to bottom without moving on to the next function until the current function is finished running, Node.js gives us the opportunity to work on a bunch of different functions all at the same time.

Real World Multitasking ≈ Async Javascript

Let’s look at a real world example that highlights the importance of this sort of multitasking: going to the DMV. It’s almost always an objectively unpleasant experience, but can you imagine how much more awful it would be if the DMV did not sort folks into categories and instead just took care of people in the order that they arrived? When some people come into the DMV they are there to get a driver’s license for the first time, register their vehicle, get temporary tags, etc! Each of these services takes a different amount of time to execute, so instead of making everyone wait in relation to the order in which they arrived, the DMV recognizes that it’s more efficient to first categorize the services they provide and then give people a place in line based on what they came in for.

Node.js does almost this exact same thing, except in a Javascript file. Instead of reading lines of code from top to bottom and waiting for one line to finish executing before moving on to the next, Node.js does not block the request thread and instead operates asynchronously.

Non-blocking Functions & Callbacks

Callbacks are what allow Node.js to operate this way; they’re used when doing any sort of I/O service ie downloading files, reading files, talking to databases. Our vanilla Javascript training has introduced us to functions that immediately return a result.

const greeting = () => {
  console.log('hello!');
}

greeting(); // 'hello!'

Functions that use callbacks, however take some time to produce a result.

const greeting = 'hello,';

const personalizedGreeting = (greeting, callback) => {
  if (err) {
    console.log('oops, an error.');
  } else {
    callback(greeting);
  }
};

personalizedGreeting(greeting, hiBetty);

function hiBetty (err, message) {
  if (err) {
    console.log('there is an error...');
  } else {
    console.log(`${message} betty the dog!`);
  }
};

Important to understanding Node.js is understanding that functions are allowed to jump around based on completion. In the above example, the hiBetty function is declared & hoisted (that is why we will not get a reference error); the personalizedGreeting function is invoked and passed getName as its callback; once getName has completed, the interpreter will print to the console, “hello Betty the dog”.

Entering the Realm of Callback Hell

Now, this is a pretty readable code but I/O operations are not usually this simple. Let’s say that instead of simply printing to the console when Betty the dog logs in, I want to check if her online portal is complete? Did she sign up with a name, a photo, her health records, and daily schedule? Let's see...

const profileComplete = (dog, callback) => {
  // is name attached to profile?
  isNameLoaded(dog, (err, loaded) => {
    if (err) {
      callback(err, null);
    } else if (!loaded) {
      callback('enter your name!', null);
    } else {
      // if name is attached, is photo attached?
      isPhotoUploaded(dog, (err, uploaded) => {
        if (err) {
          callback(err, null);
        } else if (!uploaded) {
          callback('upload a photo!', null);
        } else {
          // are health records online?
          checkHealthRecords(dog, (err, available) => {
            if (err) {
              callback(err, null);
            } else if (!available) {
              callback('please upload your health records', null);
            } else {
              // is daily schedule online?
              isScheduleAttached(dog, (err, attached) => {
                if (err) {
                  callback(err, null);
                } else if (!attached) {
                  callback('add your daily schedule!', null);
                } else {
                  callback(null, attached);
                }
              })
            }
          })
        }
      })
    }
  })
}

This code hurts the eyes and writing this code hurt the brain. Do you see how the code gradually extends to the right? This is what ppl who code affectionately call the pyramid of doom aka the defining characteristic of 🔥 callback 🔥 hell 🔥.

There are a handful of ways to get around callback hell. You can do as callbackhell.com suggests: keep your code shallow, modularize your functions, and handle every single error. The other option is to level UP and learn how to implement 🤞🏼 promises 🤞🏼.

Making Promises in Async Functions

Introduced in ES6, promises are Javascript objects that link producing code and consuming code. With promises, there’s an agreement that one function will execute once another function has been completed.

const funcName = new Promise((resolve, reject) => {...});

The function that is passed to a new Promise is an “executor”… it encapsulates a function that will eventually return a result. When the executor returns the result, it will then call ‘resolve’ with the value or “reject” with an error. If the executing function resolves to a value rather than being rejected as an error, its return value can be registered using handlers such as ‘.then’, ‘.catch’, and ‘.finally’; ‘.then’ continues on the passing along of resolved values, ‘.catch’ takes care of any errors that may pop up, and ‘.finally’ is a good for doing cleanup as it’ll stop any loading indicators.

Now let’s take a look at our previous example but refactored to include promises.

const profileComplete = (dog) => {
  return isNameLoaded(dog)
    .then((dog) => {
      return isPhotoUploaded(dog);
    })
    .then((dog) => {
      return checkHealthRecords(dog);
    })
    .then ((dog) => {
      return isScheduleAttached(dog)
    })
    .catch((err) => {
     return console.log('an error has occurred.')
    });
};

See, way easier to follow along! Promises are maybe, at this point of our coding journey, not the most intuitive functions to construct but it’s important to begin getting in the habit of making code more universally understandable as it is teamwork that makes the dream work.

A Glimpse Into Back End Data Encryption: Schemes, Protocols, and Breadth

jessrichmond — Mon, 07 Sep 2020 06:15:31 +0000

Encryption refers to the encoding of data. As data is sent and transferred from a user to a server, algorithms encrypt data and decrypt the data once it has reached the intended destination. The only way for the data to be decrypted is if that destination provides the proper key. The process of encryption can happen in so many different ways; first we’ll explore the two types of encryption and a couple of protocols & then we’ll take a look at the implications of a few real world examples.

Symmetric & Asymmetric Encryption

There are two leading schemes of encryption: symmetric and asymmetric. Symmetric encryption requires both the sender and receiver to have the same key. When both the sender and receiver have the same key, the algorithm is able to use the same method to encrypt & decrypt and thus is able to process more quickly. However, what must be considered is what happens if the recipient does not have the key… because the key must be sent to them, the key is vulnerable to being intercepted. This is why symmetric encryption is best for use within small, closed networks.

Asymmetric encryption, on the other hand, operates a bit slower but is considered to be more secure. This method utilizes a public key in addition to a private key. It is the public key that encrypts the data... everybody has access to the public key. The only way to decrypt the data, though, is to have access to the private key.

These schemes are deployed within a wide range of cryptographic protocols; each protocol has its own set of rules and methods to determine the functioning of an algorithm. The two you've probably encountered most frequently are Transport Layer Security and Secure Shell.

TLS & SSH: Examples of Encryption Protocols

Formerly known as Secure Sockets Layer (SSL), Transport Layer Security (TLS) provides a secure connection between a client and a website's server. The connection between a client and a server begins with a TLS 'handshake' in which asymmetric encryption is used to establish a session-specific key. Once the connection is established, data is transferred via symmetric encryption.

Secure Shell (SSH) allows for network services to be accessed over unsecured networks, and is often used to log into platforms. SSH does this by using asymmetric encryption to authenticate a remote network and consequently its user; all that is needed for authentication is a matching public-private key pair.

Ok, but Encrypted To Which Point?

Encryption protocols all provide secure connections; however, maybe more important is in which direction that connection is secure. Let's place this into context by exploring something that is pretty crucial to our current reality as people living in social isolation: messaging services! They're essential to staying connected these days! Sending a message to someone, whether it is over Facebook, Zoom, Slack, WhatsApp, Signal etc, requires a connection between one user, a server, and another user.

With client-to-server encryption, servers are able to decrypt & store the data it's received from the client. Because that data is sitting decoded in a database, it is susceptible to being intercepted by someone it was not intended for. Think attackers, internet service providers, governments surveilling citizens. When we're sending a message over Slack or Zoom or Facebook, that message is being stored in plaintext on Slack's servers and can be accessed by someone that message was not intended for.

End-to-end encryption, on the other hand, is designed to where the data being sent is only available to the person who is receiving it. The server does not decode the information, generally stores little metadata on the transfer, and simply acts as a traffic router. Examples of this would be Signal, Discord, or WhatsApp.

🔗 🌐 📡 🔗 🌐 📡 🔗 🌐 📡 🔗 🌐 📡 🔗 🌐 📡

In conclusion, plenty of folks have never even considered what happens to the data they shoot into the world wide web and its subsidiaries. As we head into learning about servers and databases, it is my hope that this post was able to prime you with some of the fundamentals of data encryption.

Using Sinon.js Spies & Stubs in Javascript Unit Testing

jessrichmond — Mon, 31 Aug 2020 05:12:02 +0000

Say you've been tasked with an objective and have spent a significant amount of time constructing Javascript code that you assume will result in your desired output. How can you know for sure? You could just push that code into production and wait for the bug reports to roll in, oooor you could take a more proactive approach and test as you go for any potential issues while in development.

If you choose this route (honestly, as you should), you'll need to familiarize yourself with automated tests. When written properly, tests can give developers an idea of where their code might break. There are a different few types of automated tests, but here we'll be touching on unit tests.

the utility of unit tests

As budding software developers putting our newfound knowledge into practice via sprints and toy problems, we are often evaluating the efficacy of our code by way of unit tests. Just as you might imagine, these tests evaluate units, or small chunks, of code. With unit tests (as opposed to, say, functional or integrated), we're often checking if a function is running as intended.

There are a bunch of Javascript unit test frameworks out there, but in this post we'll be touching on some of the ins and outs of Sinon.js, which offers "standalone test spies, stubs, and mocks [that also] works with any unit testing framework".

When dipping your toes into the waters of unit testing, it may be hard to conceptualize how to test code that depends on complex and dynamic external sources, such as servers or databases. We don't want to be sending requests to those servers or databases with every test we run, so it's important to figure out a way to simplify complex functions for the sake of testing.

... cue Sinon!

Sinon offers an answer to this issue by allowing programmers to create "test-doubles," that is ephemeral replacements for chunks of code. These test-doubles replace specific functions during test time, and can be configured in a multitude of ways.

There are three types of test-doubles in Sinon: spies, stubs, and mocks. Because mocks are essentially spies and stubs packaged into one, we'll be reviewing here the contrast between those building blocks.

the spies and stubs of Sinon.js

Sinon spies gather info about function calls. Spies can be used to verify whether or not a function was called, the number of times the function was called, the arguments that were passed in at call time, and then also the return value of that function call.

Here's an example of a Sinon spy some of you may recognize. This spy is verifying that a function, Parse.create();, is being called after a form's submit button is clicked.

sinon.spy(Parse, 'create');
App.initialize();
$('#message').val('Why so many Mel Brooks quotes?');
$('form .submit').trigger('submit');
expect(Parse.create.called).to.be.true;
Parse.create.restore();

One takeaway here is that Sinon spies rely on the original function running. Sinon stubs, on the other hand, go one step further by not only spying on what a function does, but also by completely replacing the original function during the test. Take our earlier example of having a block of code that is requesting information from external sources. Testing that function as it is would slow down our processing time as well as burden our external sources with unimportant data. Substituting the function with a stub would sufficiently avoid that. Here's an example from the Sinon.js documentation.

describe("stub", function() {
    it("should behave differently on consecutive calls", function() {
        const callback = sinon.stub();
        callback.onCall(0).returns(1);
        callback.onCall(1).returns(2);
        callback.returns(3);

        assert.equals(callback(), 1); // Returns 1
        assert.equals(callback(), 2); // Returns 2
        assert.equals(callback(), 3); // All following calls return 3
    });
});

Of course you shall learn more about automated testing frameworks as you progress through your coding journey & encounter various projects with their unique objectives, but it is my hope that after reading this post you have deepened your understanding of the unit tests that you'll often face as a student of software development.

Exploring the Nuances of JavaScript Arrow Functions & Why We Love 'Em

jessrichmond — Mon, 24 Aug 2020 07:00:56 +0000

When I was first introduced to JavaScript arrow functions, I understood them to be a shinier version of traditional function syntax. Sure, it made sense that as time went on, EcmaScript (ES) would have to update and adapt to new problems that developers aimed to solve, BUT I (naively) figured any sort of revision on an already existing feature was purely for aesthetics.

However, as I spend more and more time coding, I’m realizing these updates are far more nuanced than my baby programmer brain could initially wrap my head around, and I'm excited to share this with you.

Ok! So functions. What are they?

We know that functions allow us to execute a particular block of code whenever we want. We create the function via declaration or expression, we pass in an input (though not necessarily always), and then we invoke the function to produce an output.

Classic function syntax requires a 'function' keyword, a set of parenthesis to hold your parameters, and a block of code encapsulated by curly brackets. Let's take a look at an example function that helps us figure out the current price of an item on sale implemented in this traditional function style:

Arrow function syntax, on the other hand, does not require the 'function' keyword & only really requires a '=>' and a placeholder for parameters.

Other than those two default requirements, arrow functions are able to take syntax simplification even further! Let's dive into a couple of specific situations that allow you to personalize stylization.

- If your function has no parameters...

Demonstrate this with a pair of empty parenthesis or an underscore!

- If your function is one line...

Curly brackets are not needed and neither is a return statement!

- If your function has one parameter...

It is up to you to determine your preference for setting up the parameter inside a pair of parenthesis or without any at all.

- Otherwise...

If your function has multiple parameters, parentheses are required, and/or if your function spans multiple lines, you'll need to encapsulate it in curly braces in addition making your return statement explicit.

Now! That's enough about syntax. Arguably more interesting is how arrow functions interact with the keyword this.

The above examples are pretty simple implementations of JavaScript functions. However, as you progress through your coding journey, you'll come to encounter functions stored inside of other blocks of code, and you'll also be exposed to the usage of the this keyword.

In classic function expressions, the binding of this changes in relation to the context it is called in. Check out the code below:

Maybe you'd expect the result of invoking popStar.displaySingles(); in the above code to be the singles from Britney Spears' hit album, "Oops!...I Did It Again" (2000) logged to the console, BUT...

Didn't you remember that this, as Mariya Diminsky over at FreeCodeCamp explains, "always references the owner of the function it is in"? The keyword this, inside of an object, will refer to its parent object, but if this is inside of a classic function expression, it will then refer to the global window object. So, when we invoke the above code, we will print to the console the following because the global window object does not have a .name property:

There are a couple of ways to get around this issue in ES5 (check out the FreeCodeCamp article for examples), but ES6 -- the most recent major update to EcmaScript -- provided a straightforward solution: arrow functions!

Arrow functions were designed so that the binding of this is lexically scoped. This means this will always refer to the block of code that the arrow function is declared in.

If we revise the .displaySingles property on the popStar object to be an arrow function, we'll be able to print our desired output to the console.

👏🏼 👏🏼 👏🏼 👏🏼 👏🏼 👏🏼

All is well now in our popStar object, but! Don't go thinking that arrow functions and classic functions are completely interchangeable. Arrow functions do have a couple of downsides and we shall explore those another time! Thanks for reading!