Tag Archives: javascript

Event Loop in JavaScript

Last week, I wrote about blocking vs. non-blocking code and the asynchronous nature of JavaScript.  This week I wanted to deep dive into the event loop to explain one way JavaScript is able to deal with asynchronous functions and enables it to have non-blocking behavior.

Runtime Environment

Many people use JavaScript for the client-side of their app, but it can also be used on the server-side while using NodeJS.  No matter where the code is being executed, i.e. its runtime environment, the event loop impacts the order that functions are called.

The JS engine goes through every line of code in your application and has to make decisions about when that code should be run.

The Infamous Call Stack


A stack!  Okay, so not a call stack, but delicious nonetheless.

A stack is a common data structure.  It functions exactly the stack of pancakes my dad makes for the whole family during the holidays – one at a time, people are able to remove a pancake from the top of the stack and to their plate.  A stack works the same way – data on top of the stack can be removed, as well as added to the top of the stack until it needs to be processed.

The call stack is a special kind of stack in the JS engine.  It processes one line of code at a time, and it executes whatever is on top of the stack.  As soon as that function is finished executing, it is removed from the stack, and the line that was previously second in line is pushed to the top and executed.

Callbacks and Event Queues

Say we arrive at a line of code that needs this asynchronous behavior.  Maybe you wrote a setTimeOut in your code to invoke a function at a later time, or perhaps a function that needs to get data from the database.  These are called callback functions and the JS engine has a special way of handling them.

Instead of putting them directly into the call stack, the JS engine puts them into an event queue where it waits to be executed.  Once the call stack is empty, it checks out the event queue and moves any function that is next in line to the call stack where it is executed.

Event Loop

The event loop is this process the JavaScript engine uses to execute functions on the call stack while also checking and eventually executing the next function in line in the event queue.  As the user interacts with an application, the call stack and event queues are constantly moving and cycling through the code and reacting in response to user behavior.  This keeps your program running smoothly!

While this is a very simplified version of what happens inside of a JavaScript engine, it is important information to keep in mind when writing code.


Problem-solving with React and Redux

Project: A web application to help users search for jobs and keep track of their applications.

Task: Implement a “delete” button that deletes a job from a user’s dashboard  – because sometimes you might not actually want to apply for a job anymore.

Tech Involved:

  • ReactJS – front-end
  • Redux – the store/object that takes care of state for the entire App
  • Redux DevTools – a GoogleChrome plugin that helps you see what’s in the redux store
  • Rethinkdb with Thinky – database and ORM to persistently store users and the jobs they’ve saved
  • Material-UI – for styling componenets

Structural Considerations: 

This was my first project using ReactJS and Redux.  Redux allows for what they call a “unidirectional” flow of data.  The concept is simple enough, but actually seeing how the flow of data travels through the application took a while for me to understand.  Also, the set-up is a lot to process the first time through, but the benefits are immense once you get it working.  When using an MVC framework like Backbone, every time you make a change to the model, you also have to re-render the view which can get complicated as your app grows and gets complicated.  But, ReactJS takes care of all rendering of the view for you, and Redux keeps track of all changes in the state of your app.

Thought Process: 

The user has a dashboard that displays all their saved jobs which they can then click on to get to an individual job view page.  We thought this would be a logical place to delete a job because you might read the details of a saved job and decide that it really wasn’t what you were looking for.

Before typing any code, I made a mental list of all the places that would be impacted by this button, which looked a little like this:

  1. Create a delete button component
  2. Import button into the job view container
  3. Create a method that initialized the process of deleting a job from the database in the Job View Container

All of my initial thoughts were mostly about the front-end.  It also made me realize that I had some questions about how properties and elements were passed between components and containers in React.  Before I started coding, I researched some example projects online, as well as other parts of the app that other members of my team had worked on.  I was then able to create a button in the job view container, as well as a skeleton for a handle-delete method that would be called when the button was clicked.  At this point, I had to go back into research mode to try to figure out how Redux would help us make the change to the database as well as communicate with the React components of our app to actually delete the job from our view.


I love Redux, and I highly recommend getting started with it by watching the series of videos on Egghead.io by its creator Dan Abramov which you can find here.

At the heart of Redux is a single STORE which is basically an object that keeps track of the entire state of your application.  That store can be modified with specific actions which are then put into play using a reducer.

Actions are simply all of those things that need to happen to make your app work.  In our project’s case, we have actions that add users to the database, add jobs, refresh the database, etc.  Reducers….reduce (if you need a refresher on what reduce does, checkout my Re: contains post).  In terms of Redux, a reducer takes an ACTION and applies it to the PREVIOUS STATE and reduces it to get a new state.

This is such a simple concept, but putting it into play when implementing the “Delete Jobs” feature from start to finish is finally how I was able to put this into practice.

In terms of my thought process, before I wrote my code I wrote comments and pseudo code in every file I had to touch to make this successful.  This included our reducer file, actions file, and action types files.  I hope to explain exactly what I did in the code in my next post.