Hi, I'm Max 👋
  I'm a Full Stack Web Developer,
   based in SF Bay Area.
    Thrilled about all things JavaScript,
     passionate about teaching
Algorithms' performance oftentimes depends on the data - whether it's an array of random numbers, nearly sorted numbers, few unique, reversed etc. Whilst Insertion Sort in terms of performance is very similar to Bubble Sort and Selection Sort, there is however one case when Inserion Sort could be a preferred choice. And that's when the data is almost sorted.
The way Insertion Sort works is a little different than Bubble Sort and Selection Sort. It doesn't rely on the swap
function, it inserts elements instead. Once we scanned through the elements and found the one that needs to be sorted, we then make the space by shifting elements to the right. And that operation of freeing the space, i.e. shifting numbers, is not costy, which is the advantage of the algorithm. There's nothing that complicated about it, but there needs to be "a-ha" moment to properly understand what "shifting" vs "swapping" is, and why exactly it is needed here.
As far as implementation goes - in order for us to not have a tempation to do "swapping" instead of "shifting", defeating the purpose of the algorithm, preferred way is to use the while
loop instead of for
as the nested loop. It also won't result in variable visibility issue and we won't need to use var
keyword to solve it.
Selection sort is the probaby the second simplest sorting algorithm out there. And it's not very efficient as well - you definitely don't wanna use it for large amounts of data. But understanding this algorithm is another step to understanding more faster and more efficient ones, and it's a very logical progression from the Bubble Sort, because these 2 algorithms are similar to one another.
Selection Sort is often called a "reversed Bubble Sort". Just like Bubble Sort, it uses nested for loop
and swipe
function, but after each iteration, instead of placing the largest number to the very end of unsorted part of the array, as the result of a so-called "bubbling", we select the smallest number and place it in the very beginning of the unsorted part of the array. Also, instead of swapping elements each time we go through numbers, comparing one to another, we just keep the smallest number of the each iteration in memory, and then do the swapping, once iteration is over. It is a considerable win over a Bubble Sort. More about the differences between the 2 algorithms you can find in this article.
Algorithms, as well as data structures, are fundamentals of computer science. They are patterns for solving problems, and the more you know them - the better problem solver, i.e. programmer, you are.
There are many sorting algorithms out there. Some are fast, some are slow, a lot of times efficiency of an algorithm depends on the data being sorted. There are algorithm visualizations that demonstrate the algorithms' peformances in comparison to one another. I recommend watching this youtube video to get the overview of different algorithms and get the idea of how vastly they differ from each another. And as you probably have guessed already, we're gonna start with the one that is the slowest of all, because it must be the simplest as well. Of course, we need to start building the foundation, and it's best to start building from the very bottom. Bubble Sort is the one we'll be looking at first.
The algorithm is called Bubble Sort because of the way largest values are being pushed, or "bubbled" up to the top, one by one, until the array is sorted. It's done by going over each number, comparing it with the next one, and if the current (left) number is greater than the next (right) number, we swap those numbers, and so on. It's very important to deeply understand what is going on, because this understanding will be very important for moving on to the next level.
In this video we'll be looking at useEffect
hook. As the name suggests, it lets us perform side effects in our function components. It's what componentDidMount
, componentDidUpdate
and componentWillUnmount
did for our class components – whenever we needed to call document
or window
API, or do some data fetching, that's how we would do it.
We're gonna be working with the todo app, and we're gonna see how this hook works – how just one function can replace 3 lifecycle methods at once. We will use Firebase as our database. We'll have to retrieve data when our component mounts, meaning, after our app is rendered – that's the way to do asynchronous data fetching until there's data fetching solution compatible with React Suspense. We will also look at how we handle component updates and component cleanups, and again, all of that within just one function! It's pretty neat if you ask me, I really enjoy it. We can have multiple useEffect
calls in one component, and that's exactly what we're gonna do.
Writing function components instead of class ones feels very natural to me. But to people who are just starting out I would still suggest to get familiar with class components. Nobody (or not many people) will be rewriting their code, so jumping straight into hooks, and then getting to work with class component based codebase might be an unpleasant experience, to say the least.
In this video we're building the same todo app that we built using class components in part 1 of the video, but this time we're using function components. We'll look specifically at the useState
hook, how it works. As the name suggests, it creates a state for us. We have to destructure its 2 values, first one of which is our actual state, and second is the the state updater function. Btw I'm glad that ES6 destructuring is taking place here as the recommended way because there are still people who don't use this amazing ES6 feature.
We can have as many states as we want, and each one we'll have to create using the useState
function. It's really a neat way to write components - it's more readable, less code, and we don't have to deal with the this
keyword. But there are few important rules that we need to follow when using Hooks in our applications. We can only use hooks at the top level of our app – we can't call them inside loops, conditions or nested functions. It ensures that they will be called in the same order each time a component renders. Another rule is that we need to call hooks only from React functions, not from regular JavaScript functions, which will ensure that all stateful logic in a component is clearly visible from its source code.
There is also a way to build your own hooks, that lets you to extract component logic into reusable functions. We can find plenty of examples online on how to do it and a lot of already written hooks which we can just use. There's a great resource usehooks.com where we can find a lot of those. Community loves hooks and it's very clear why. There are other important hooks that we will explore in the next videos. See you soon!
Hooks is a total game changer. Ever since they were introduced on last October's React Conf, community has completely embraced it and started playing with them even before they have officially landed in the library. But now they've been finally released! And they're definitely gonna change the way we write React apps from now on.
I was never a huge fan of class
keyword in JavaScript, but the concept of the Component
, as the abstract class, kinda made sense. Well, we simply didn't know a better way, although we all felt that the boilerplate is too big. Luckily we don't have to use super()
and do this
bindings for quite some time now, but it still felt like a bad idea to have 2 types of components in our app - stateful and stateless. Whenever our stateless function components needed a state - we had to turn them into the stateful class ones, and it could get painful. I'm pretty sure every React developer has experienced this pain at least once... Well now it's seems to be over! We can really get rid of class components and write our apps using only function components. And that's the direction people behind the library have taken and users have approved. And there's more to just that, how about an opportunity to get rid of Redux for the most part? How does that sound? We'll see how that will play out, since there are hooks for that too :)
In the video we're gonna be looking at the useState()
hook... Actually no, I'm lying, we're gonna be building a todo app using class compenents (R.I.P.) and in the next video we'll rebuild the same app, using funcion components with useState
hook. I was just planning to do one video, but React is so verbose... You know what I'm talking about :) See you in the next video!
Our so loved Math.floor(Math.random() * 10)
... why it's so ugly? Do you still google it? Lol we really wish it was easier, don't we? Why isn't it build into the language, put on the Math
object's prototype?..
Well, JavaScript doesn't have integers. As strange as it sounds, it is true. It does have a number
data type, but that is a double precision floating point number, not an integer. And that's exactly what Math.random()
generates and what we have to take as our base, and then multiply by the number we want to be the ceiling for our generated random number, so say if we want a number from 0 to 9 - we have to multiply the output of Math.random()
by 10... And then we'll have to use Math.floor()
or Math.ceiling()
to turn it into an integer... Yes, we have to do all that stuff, and there's no sugar built into the language that would do that for us....
In the video, I'm showing you an example of how to use that method, doing a little ranting, and also showing you how to build a function that generates a random number in the range, hooking it into the form thereafter, for fun. And I promise, you'll always google that range function :) Unless you love numbers.
In the browser, timer events, or simply timers, such as setInterval
and setTimeout
, are Web APIs, globally available for our JavaScript code. Interesting thing is that both of these methods are not a part of the JavaScript. Along with DOM API, XHR (Ajax), fetch, canvas etc, they are part of aforementioned Web APIs, provided to us by the browser environment. Think about them as separate C++ modules of code, that do their job separately from the main execution stack.
Imagine our JavaScript engine parses our code and it stumbles upon some setInterval
. The callback, passed to a function as a second parameter, is scheduled to be executed after a certain period of time. And who's gonna be responsible for counting the time and then pushing it into the call stack in the due time? You guessed it, a separate from JavaScript engine, Web API. When we retrieve the data from an external source asynchronously using fetch
or XMLHttpRequest
- who's doing all that work for us? Same thing, Web APIs. Understanding this process is a key to understanding one of the most important concepts behind JavaScript - event loop. You can watch this great video on Event Loop if you're interested about what is going on under the hood.
In my video, I don't go into the concepts of timers, I show the practical example of how you can use them. Sure, there is a lot going on with them, I didn't even mention closures that they create, but we can apply timers for the simple and fun DOM manipulations without going into depths of the language. And now that you can see some examples - get creative and come up with something cool :)