DEV Community: Branden Kim

TIL - Generating Permutations and API Level Testing

Branden Kim — Tue, 08 Sep 2020 15:29:37 +0000

Today I learned...

A method for generating permutations and patterns for API level testing!

Generating Permutations

While trying to solve a new programming problem, I recognized that it involved generating all permutations of an array. While I wasn't able to solve it completely as I missed permutations in the generation sequence, I dove deep in the solutions and internalized the patterns.

This method involves Divide and Conquer, Swapping, and Backtracking.

Namely this method is for generating all permutations of an array by swapping elements that you haven't seen so far with ones that you have.

The divide and conquer part comes from dividing the length of the array into two parts, a prefix from 0 -> i and a postfix from i -> end. The postfix essentially becomes a smaller subproblem of the original as we consider the prefix part done, hence making it divide and conquer.

The swapping is used to swap elements in the prefix and postfix to generate different permutations as an array of [1, 2, 3] has a valid permutation [2, 1, 3] which is out of order. The swapping creates that out of order.

The backtracking is to go back to a previous state after a swap since you can swap the first index with the second, but want to reverse that process so you can also swap the first with the third.

The base case is when the current index is the same as the length of the array as it means your prefix has become the entire array, indicating that you have finished that path of generating permutations.

Quick example of generating permutations from Leetcode image

The pseudo-code looks something like this:

def outerFunction():
    initialize vars needed

    helperFunction()

def helperFunction(array, start_index):
    if (start_index == len(array)):
        Do base case work here
        return;

    for (i = start_index; i < len(array); i++):
        swap(start_index, i)
        helperFunction(array, start_index + 1)
        swap(start_index, i)

    return;

API level testing patterns

I also looked into API level testing patterns for my productivity tracker. I learned a lot of information such as the cases you need to test for API's (status code, response body, response headers, etc) as well as what to mock in API level testing.

In my case, I am trying to automate the API level testing from end-to-end so I learned in general you should only mock anything external to what you are trying to test including external libraries / APIs.

Furthermore, different test cases should be handled for security groups, authentication, headers, cookies depending on the API implementation.

I also found out that a common pattern people use to develop APIs is having a combination of a real-api backend and mocked apis. The real-api backends are kept/utilized once the APIs are implemented while the mocked ones are for new features and made quickly so that it doesn't block any frontend workers.

This paradigm reduces the amount of time spent doing nothing as much as possible.

TIL - Tarjan's Algorithm

Branden Kim — Tue, 01 Sep 2020 19:00:31 +0000

While practicing some competitive programming, I came across an interesting subsection of Graph Theory - Strongly Connected Components (SCC).

In a directed graph, strongly connected components are nodes that have edges such that each node in the SCC is able to have a path to every other node in the SCC. To help you find these SCCs one can use something called Tarjan's Algorithm!

Tarjan's algorithm is an algorithm that can find SCCs in a directed graph with one DFS pass O(V+E) time and using just a stack O(V) space, where V is the number of nodes and E is the number of edges.

The way it works is that it keeps track of two lists discovery and low_link that are the length of the number of nodes. Tarjan's algorithm works correctly because it makes use of a stack to remember what nodes are counted in the SCC. Without this it is possible to run the DFS on the graph in a order such that you locate less SCCs than what actually is on the graph.

The stack is used to keep track of nodes that are already included in the SCC so far so if you encounter a node that is on the stack, it must be part of the current SCC.

A high level overview of the algorithm is as follows:

Traverse through all the nodes with a for loop, running DFS on the node if it is not visited.

As you visit nodes mark the node as visited, and have a counter that marks each node with ids and sets that node's discovery and low_link equal to the node id. Also, push the node onto the stack and remember that it is on the stack.
This algorithm uses the idea that a node's discovery time and low_link value is equal to the order that it got visited as this order is how the algorithm finds the lowest common ancestor.

Loop through all of the node's neighbors if and run DFS on the unvisited nodes.

After coming back from the recursion, set the low_link value of the current node equal to the min between itself and the neighbor.

Also, check if the neighbor is on the stack and if it is, it means it is part of the SCC. Set the low_link value to the min between itself and the discovery time of the neighbor.

After checking all neighbors, check if the current node's discovery value is equal to the low_link value as this means its the root node to the SCC. Pop of all the nodes up to and including that current node.

At the end, your low_link list should have all of the SCCs!

Theoretical Properties

Apparently, this algorithm works off the fact that SCCs are maximal in a way, meaning if you find an SCC, it is guarenteed that there won't be another SCC within it. Another useful property of the algorithm is that no SCC will be identified before any of its successors.

Implementation

Here is my implementation of Tarjan's Algorithm!


class TarjansGraph {
    public:
        inline static int UNVISITED = -1;
        vector<int> *adj_list;
        int n;

        TarjansGraph(int size) {
            this -> n = size;
            adj_list = new vector<int>[size];
        }

        void addEdge(int u, int v) {
            adj_list[u].push_back(v);
        }

        void dfs(int at, vector<int> &ids, vector<int> &low_list, vector<bool> &onStack, stack<int> &myStack) {
            ids[at] = at;
            low_list[at] = at;
            onStack[at] = true;
            myStack.push(at);

            for(auto iter : adj_list[at]) {
                if(ids[iter] == UNVISITED){
                    dfs(iter, ids, low_list, onStack, myStack);
                    low_list[at] = min(low_list[at], low_list[iter]);
                }
                else if (onStack[iter]) {
                    low_list[at] = min(low_list[at], ids[iter]);
                }
            }

            if (ids[at] == low_list[at]) {
                while(myStack.top() != at){
                    int stack_node = myStack.top();
                    cout << stack_node << " ";
                    onStack[stack_node] = false;
                    myStack.pop();
                }

                int at_stack_node = myStack.top();
                cout << at_stack_node << endl;
                onStack[at_stack_node] = false;
                myStack.pop();
            }
        }

        void findSCCs() {
            vector<int> ids(this -> n, TarjansGraph::UNVISITED);
            vector<int> low_list(this -> n, 0);
            vector<bool> onStack(this -> n, false);
            stack<int> myStack;

            for(int i = 0; i < this -> n; i++){
                if (ids[i] == TarjansGraph::UNVISITED) {
                    dfs(i, ids, low_list, onStack, myStack);
                }
            }
            cout << "\n\n\n LOW LIST VALUES: ";
            for (int i = 0; i < this -> n; i++){
                cout << low_list[i] << " ";
            }
            cout << endl;
        }

};

PC Building! My first experience building a desktop

Branden Kim — Mon, 31 Aug 2020 19:00:32 +0000

Last weekend, I set out to do something that I had been itching to do for a while... Building my own PC!

I just wanted to share some of my experiences during the build process and point out some difficulties that may aid those that are looking to get into PC building!

PCPartPicker

Probably the most useful site that everyone needs to use when building a pc is pcpartpicker. This website nicely lays out all the parts that are required to build a new PC as well as a compatibility checker that lets you know if there are any compatibility issues between the pieces of hardware you check out.

PCPartPicker pc building tool

The website nicely lays out the necessary components as well as some compatibility issue information. This website made the building process very manageable since it broke down and listed exactly what parts I needed as well as compatibility information between them.

Picking out my parts for my build

As a newcomer, finding all the parts to build a PC with a theme was really overwhelming especially when considering all of the compatibility issues between the hardware pieces.
I ended up opting to look at the parts of that someone else had already made and then I substituted pieces that I wanted from that already made build.
To me, this was the way to teach myself about the options I had for each PC part and how to find the compatibility between the different parts since I could focus on just one part at a time. Looking back on it, this method is not really necessary because PCPartPicker's compatibility check is super helpful, but it was the method that made the most sense for me.

Picking out the parts

I, by no means, am an expert on the technicalities on different PC parts and the exact compatibility knowledge between every part, but throughout this experience, I picked up a few tips that might be helpful! Also, I think PCPartPicker warns you of most of the compatibility issues I am listing.

The Motherboard

The motherboard was one of the most important parts of the whole process as it interacts with all of the other parts of the PC. This is where a majority of compatibility issues will arise.
Here are some of the compatibility tips that I learned:

Make sure that the model of the CPU is compatible with the motherboard that you pick
- Often Intel CPUs have models that only work with certain motherboards while AMD have their own respective compatible models
Double check if your motherboard comes with features like a wifi adapter and the number of PCIe slots for your video card and other expansions that you put in the motherboard
If you buy an M.2 SSD, make sure that your Motherboard supports that, I think most modern ones do

PC Case Dimensions

The size of your PC case should be big enough to fit all your components! Often the video card is the biggest part so make sure the case's width, height, and depth are big enough to fit the video card

Power Supply Unit

Make sure that your power supply unit covers has more than enough wattage than what is utilized by the parts. This can easily be found on PCPartPicker's building service. My build said it uses around 513W, so I got a 850W PSU just to be safe

The build process!

Building the PC was quite a process. Since I spent so much money on the parts, I really really didn't want to mess anything up and accidentally break any pins or scratch my motherboard. I watched Linus Tech Tips POV video and Bitwit's Step by Step PC building video over and over and over again following every step carefully.

It was probably a good thing that I followed the videos meticulously, but also the creators of the parts did such a good job in abstracting a lot of the details out. Assembling things together was really simple and error-prone, I genuinely think that anyone can just pick it up and do it.

The easiest part was probably connecting the parts to the motherboard.

Motherboard with CPU, SSD, Memory, and Cooler installed

I won't go through all the details because the Linus and Bitwit cover the details so much better than I can.

The parts that they recommended to install first on the motherboard were: CPU, Memory, M.2 SSDs, and the CPU cooler.

The PC Case and the dreaded Wire Management

Where I really had trouble and the part of the building that took the most time was assembling all the parts onto the PC case.

The PC case itself has a bunch of wires that connect to the front of the PC and the manual has no explanation on what any of the wires are for. Because it was my first time and I wanted to be super careful, I spent a lot of time trying to figure out where the wires go and what they were for.

Hopefully, I can save you some time. The wires are basically to connect the buttons on the front of the case with the motherboard. Generally, your motherboard manual will layout the specific pins that should connect to the front of the case and what each one does.

These buttons include turning the PC on and off, reset, LED control, and connection to USB ports.

More connections mean more wires and sooner or later they will start to get overwhelming as the number of connections to your motherboard increases.

Managing all of the wires was very overwhelming at first, but I think the most simple and manageable way is to use zip ties and bands to group up wires for similar purposes. I grouped all the front case wires together, the fan connections together, and the ones coming from the power supply unit.

Also, bring the wires from the back to the front from a hole closest to the place it should connect to. It is the most efficient and cleanest way to connect wires to the PC.

Don't connect the video card until the end!

One of the most annoying mistakes that I made was connecting the video card too early. The video card took up much more space than I thought and I connected the video card before connecting the front wires to the bottom of the motherboard.

Since I connected the video card early, it was like defusing wires trying to connect the other wires to the bottom of the motherboard without damaging any of the pins.

Connecting the big boy wires from the PSU

Figuring out what wires connect to the PSU was also sort of ambiguous to me. The manuals didn't explain what parts needed to connect to the PSU so I was a bit worried.

I think generally any wire that can't connect to your motherboard and requires power is going to be connected to the PSU. This includes:

CPU
GPU
Fans
CPU Cooler
External Storage Devices

With everything connected, I finally finished my PC!

My Finished Build!

Installing Windows!

Finally, I got to the step of installing Windows! Unfortunately, I had a lot of issues installing because the other machines that I had available were MacBooks and the file systems for windows and mac were different.

I had to format my USB to FAT32 format, but this format doesn't allow any files greater than 4GB and the latest windows iso image has a file install.wim that's bigger than 4GB.

This guide by Quincy Larson on FreeCodeCamp worked like a charm for me and I was able to end up booting windows! For some reason, I kept failing to install Windows since I think something was wrong with my memory partitioning. However, after multiple tries of formatting my USB and redownloading Windows, it just started working randomly; I am still not sure what the cause of the error was. After booting I followed this video by JayzTwoCents and it helped me walkthrough step-by-step what I needed.

In general, I figured out that the right drivers need to be installed for all of the hardware parts (Asus had a Q-Installer program that did it all for me). Also, I configured my memory speed to run at the advertised speed in the BIOS which apparently a lot of people forget to do.

Gaming and Linux!

This whole process was super fun as it was a really cool beginner hands-on project on something that is very useful to me. I would highly recommend building a PC for everyone. It's more approachable than it looks like and feels super rewarding!

I can't wait to max out the graphics settings on Final Fantasy 14 and install Arch Linux on it to customize my development workflow!

Please let me know if I messed up any information or if something could be improved in my build or explanation!

Gamify! - A Gamified Approach to Named vs Arrow Functions

Branden Kim — Fri, 21 Aug 2020 03:09:12 +0000

Background

This is one part in a series called Gamify! where I try to create Gamified versions of the typical tutorial. I try to gamify learning since I believe its the best way for all skill and passion levels to get what they want out of the tutorial as well as been fun and informative. When going through this tutorial, there is a level that corresponds to how much and how in-depth you want to learn about the topic. If you just want to know what the topic is about Level 0 should be enough, but if you care about the nitty gritty details, Level 4 might be of interest.

Levels
Level 0 🕹️
Level 1 🎲
Level 2 🃏
Level 3 🎮
Level 4 🎯

Introduction

Within Javascript you have probably seen something like:

const fun = () => {
    // statements...
}

When encountering this syntax for the first time, it can really confuse you (it did for me) and it took me a while to get used to what it mean and why it was used.

Well fret no further because I am going to demystify this for you!

Level 0

What are "Arrow Functions"?

Arrow functions are another syntactical method to declare functions in Javacript (and Typescript). Basically its another form of function declarations with the following syntax:

(param1, param2, param3, ..., paramN) => { statements }

However with arrow functions, they must be assigned to a variable.

Here is an example:

// Declaration
const func = (a) => {
    return a * a;
}

// invocation
func(10) // returns 100

This as opposed to the regular function declaration:

// Declaration
function namedFunction(a) {
    return a*a;
}

// Invocation
namedFunction(10) // returns 100

Notice how the two functions had the exact same result with the same input! Basically, whenever you encounter this syntax, just read it as a regular function in your head!

If you want to learn more, progress to the next level!

Level 1

Differences between Named vs Arrow Functions

Out of all the differences, there is one really important difference between Named and Arrow functions:

"This" context

Arrow functions do not redefine the context of the this keyword when created. This is different from that of named functions which do redefine the this context based on what scope it is in.

Back when I first encountered arrow functions and read about their differences, I still didn't understand what the difference was. To help you avoid frustration and understand better, I have created a quick analogy:

Think of Named functions (ie. when using "function" keyword) as Mario and Arrow functions (ie. "() =>" syntax) as Luigi. Named functions and Arrow functions have the same end goal: defining a function similar to how Mario and Luigi have the same end goal of defeating Bowser and saving Princess Peach. However, Mario's fireball ability and Luigi's fireball ability differ in that Mario's fireball adheres to the rules of gravity while Luigi's fireball does not and is independent of the rules of gravity. Named functions and Arrow functions have a similar pattern. Named functions always follow the rule of defining the "this" context to its outer scope, while Arrow functions do not follow this rule. Basically, Named functions similar to Mario's fireballs follow rules while Arrow functions and Luigi's fireballs do not follow the rules, even though the overall goals for both are the same.

How "this" changes

Above is a basic demonstration of the this binding in action. At a high level, we can see that when this is returned within the arrow function, it is not pointing to the level1obj but rather to the global window context. On the other hand, the named function return this points to level1obj.

We can see here that calling the named function and returning the this value results in this referring to our level1obj which allows us to do things like:

This allows us to access members of the level1obj.

On the other hand, when we access the arrowFunctions this that gets returned, we actually get the global window object. This is because the arrow function does not change the this context.

Hence, accessing testParam with this will not work.

When to use Named vs Arrow

Now that you know some basic on how the Arrow function changes this, here are some general guidelines for when to use Named functions vs Arrow functions.

1. Don't use arrow functions as members of an object

For reasons that we can see above. In the example given above, if for some reason within the function we have to access the members of the object (level1obj in the example), then we can't access them from within the function which will make things quite difficult.

2. Use arrow functions within callbacks

There is a deeper explanation for why this rule should be adhered to in the higher levels, but as a general guideline, arrow functions should be used in callbacks as you will be able to preserve your this.

3. Use arrow functions within dynamic contexts

By dynamic contexts, I mean anytime you are trying access or modify an object and its methods after the program runs. This usually appears when using events with some kind of event handler. When a callback function is passed to the event handler, the this reference points to the object that is listening for the event rather than the object that created the callback. Most times, it is advantageous to have the this reference point to the object that created it to modify its member variables or state. This is a common problem in React that arises when developers first learn about passing functions as props.

Here we can see that when the Named Function is called within the class, the this context is not pointing to the class but rather the global window.

On the other hand, the arrow function preserves the this context and can access the Dynamic classes's member variables within the callback function.

If you want to go more in-depth in the differences go to the next level!

Level 2

Arrow functions have more differences than just the this context and for simplification, I spared the explanation on why the differences occur.

Arguments Binding

Named functions have this feature called arguments binding. Utilizing the new keyword, you can create an instance of a function and store the arguments to a function within a variable.

Here we can see that when utilizing a named function, we are able to bind the arguments by utilizing the arguments keyword within the function.

However, in the arrow function, it doesn't keep that reference to the arguments keyword.

Constructable and Callable

Named functions are constructable and callable meaning that they are able to be called utilizing the new keyword, creating a new instance of the function, and are able to be called as regular functions.

Arrow functions, on the other hand, are only callable. This means that arrow functions cannot be called utilizing the new keyword.

In the screenshot above, we can see that new could be used with named functions to create a new object. However, when utilized with the arrow function, the compiler gives an error: "TypeError: y is not a constructor".

Generators

Named functions have access to a special keyword yield. This keyword along with a special syntax on the function declaration allows the function to become a Generator function. A generator function is one that can be exited and later re-entered where the information within the function context is saved even after exiting the function. If this sounds a bit confusing don't worry! What generator functions are, how they work, and use cases will be covered in another Gamify! series post.

While named functions have access to yield, arrow functions do not, meaning arrow functions cannot be generator functions.

Above we can see that when using the named function, we were able to create generator functions and utilize them with yield. However, when the same syntax was made the arrow function, the parser couldn't figure out what yield was.

In-depth explanation of "this" context

In the previous level, we found several use cases of named and arrow functions based on how the this context changes. While I explained the "what" I haven't yet explained the "why".

When generalized, the rules of how the this context switches are fairly simple:

new keyword

The new keyword changes the context of the outermost this context for everything within that scope. This means that any functions defined within the object that gets created using new will have its this reference pointing to that new object. Let's see a very simple example of how this changes.

Normally in the global scope, this refers to either the window or undefined. If we were to create a new object with new, then if any of the functions within that new object reference this, they will point to the new object that was created.

Here we can see that we create a new obj1 that logs its this reference and it points to itself. Within its member functions, it creates a new instance of obj2 which logs it own this reference which points to its own member variables in both the named function and arrow function.

The new keyword changes all of the this contexts of functions (both named and arrow) defined in its scope to point to instance of the newly instantiated object.

Callbacks

Callbacks makes things a bit messy. When encountering a function declaration to find the this context, the outer scope needs to be identified. While the scope of normal variables are determined by the lexical scope, the this scope is determined by where it is called. Generally, the way callbacks work is that the compiler stores the context of where the callback function was passed as the callback's scope.

let obj = {
    name: "test",
    cb() {
        return ("Hi", this.name)
    }
}

setTimeout(obj.cb, 1000)

In this example, this it will print out "Hi undefined". In this case, the callback "obj.cb" was defined in the global scope and as such the this reference will be lost and not set to obj.

Unlike named functions, arrow functions are treated as variables and thus are subject to the compiler's lexical scope. This means that within callbacks, there will be a difference in functionality with the this keyword.

We can see in the above example that when a named function is used within the callback, the this context becomes global as when setTimeout is invoked, where the callback gets defined and run is in the global context not in obj, hence the this context points to the window.

On the other hand, when an arrow function is used, since it is treated as a variable, it doesn't redefine the this context which is why it still points to obj.

Nested objects within classes

The simplest way to handle how named and arrow functions differ is to treat named functions as redefining this to the parent context of where it is defined and arrow functions as not redefining this.

In this nested objects example, the named function this reference points to the innermost nested object while the arrow function this reference points to the outermost object.

Thats all for this level, in the next one we will cover different instances and common patterns for fixing losing this context.

Level 3

Here I wanted to cover several examples of using named vs arrow functions and explaining the results of each example.

Asynchronous Functions

With asynchronous functions, the binding of this follows the same rules as for regular functions and callbacks. In the example above, we can see that when using named functions for the callback to the Promise, we lose the context of this and it gets sent to the window. However, when we use arrow functions, we retain our context to the object. One aspect to note is that because our "arrowFunction" member variable is a named function, the this context within it points to the obj. If we had used an arrow function instead, it this would point to the window instead.

A takeaway we can note here is that, asynchronous functions don't change any differences between named and arrow functions, they both retain the same rules when used as regular functions and callbacks.

Classes

Within classes, the context of this changes due to the use of the new keyword. Because new is an identifier for detecting the start of a new context, both namedFunction and arrowFunc have their this context pointing to class Testing.

Following the rule for callbacks mentioned previously, when we call namedFunction because of the use of named functions within the callbacks, the this context is lost within the Promise.

On the other hand, arrowFunc uses arrow functions in the callback handlers, so the this context is kept.

Object.create() and Prototypes

Prototypes are the method in which Javascript objects inherit base and additional features from one another. Using Object.create() syntax, you are able to create the equivalent of classes using prototypes in Javascript with Objects.create().

In the example above, using the prototype of the object proto I created a new object using Object.create(). Here it just creates a new object with the prototype that gets passed in meaning, p is a new object with the member variables and methods of proto.

In this scenario, namedFunc has a this reference to the member variables of proto but just returning this by itself shows an empty object. This is probably due to the fact that Javascript cannot determine whether this is referring to proto or the prototype for objects as Object.create() creates an object with the existing object as the prototype of the newly created object.

When using arrowFunc there is no new keyword used here, even though we are creating a new object. This combined with the rules for arrow functions never change the this context, thus not changing it from pointing to the window.

Patterns for fixing losing `this`

So how do we not lose this (nice pun)?

Using arrow functions

Arrow functions in Javascript are actually treated as variables that are bound to the lexical scope as opposed to functions (more on this in the next level). This is why arrow functions don't change the this context when created.

const arrowFunc = () => {
    console.log(this)
}

function higherOrder(callback) {
    let obj = {
        name: "some new object"
    }

    obj.callback = callback

    obj.callback()
}

function namedFunction() {
    console.log(this)
}

higherOrder(namedFunction)
higherOrder(arrowFunc)

What do you think is going to be printed to the console in both cases?

Here namedFunction actually prints the obj that was defined within the higherOrder function while arrowFunc prints the global window.

The reason this happens is because when arrowFunc was defined, it was treated as a variable meaning where this was referring to was already known as the lexer was able to scope the variable to the outermost scope.

However, with namedFunction, it is treated as a function and when it got passed into higherOrder, there was no way it could know what this was referring to until it was tied as a member function to obj within higherOrder

Because of this effect within callbacks, it is generally preferred to pass arrow functions within callbacks as the this context doesn't change as much and cause confusion.

Use bind(), call(), or apply()

When using bind() on a function, this returns a copy of the function with this pointing to the object passed into the bind function.

let obj = {
  aProp: "this is a property",

  namedFunction() {
    console.log(this)
  }

}

let obj2 = {
  message: "When passed to bind, this object will be referenced by 'this'"
}

let funcBind = obj.namedFunction.bind(obj2)

obj.namedFunction() // returns obj

funcBind() // returns obj2

Here we can see that by using bind() we were able to bind the this reference to another object. When using bind() it expects a parameter that is an object to bind the this reference to and then returns a copy of the function with the this reference changed. Also, the original function is not changed as above, obj.namedFunction() still has its this pointing to itself.

A common pattern is for an object to pass itself in bind() so that its member function can be passed to another function as a callback, but still modify properties in the original object.

class ChangeMe {
    constructor() {
        this.state = []
    }

    handleChange() {
        this.state = [1, 2, 3]
    }
}

Commonly used in React components, if handleChange() is passed as a prop to a child component without calling bind(), this will point towards the child component and will change the child state not the parent.

Using bind, however, we can fix this!

class ChangeMe {
    constructor() {
        this.state = []

        this.bindHandleChange = this.handleChange.bind(this)
    }

    handleChange() {
        this.state = [1, 2, 3]
    }
}

There are two other functions: apply() and call() that have a similar functionality as bind() except, they call and run the function immediately.

let obj = {
  aProp: "this is a property",

  namedFunction(param1, param2) {
    console.log(param1)
    console.log(param2)
    console.log(this)
  }

}

let obj2 = {
  message: "When passed bind, this object will be referenced by 'this'"
}

obj.namedFunction.apply(obj2, ["test", "test2"])
obj.namedFunction.call(obj2, "test", "test2")

Both apply and call takes the object to bind this to as the first parameter and run the function immediately. However, apply() takes an array of parameters, while call() takes parameters separated by commas.

Bind(), call(), and apply() all bind this to the object that gets passed in. In common cases, the class that owns that function usually binds its own this reference to the function in case that the function is used in a callback.

Level 4

I know what some of you are thinking at this level, exactly why does Javascript treat named and arrow functions differently?

In this level lets take a look at the AST that gets generated from Javascript compilers, specifically Node.

const { Parser } = require('acorn')

const namedAst = Parser.parse("function namedFunction() { return 1}")
console.log(namedAst)
const arrowAst = Parser.parse("const arrowFunction = () => {return 1}")
console.log(arrowAst)

I am just passing a very simple named function and arrow function in the form of a string to a package called acorn which is a package for a small Javascript parser that can generate the AST for a given Javascript program (for those that are not familiar, AST is abstract syntax tree).

Looking at the AST node output for a named function, we can see that it is of type FunctionDeclaration.

On the other hand, an arrow function is treated as a node of type VariableDeclaration.

FunctionDeclaration and VariableDeclaration types are interesting, but we don't know what they are yet. After digging into the source code for the Node compiler,
I was able to pin down some files where these types were referenced.

From the Node compiler, this is the source code within scopes.cc to generatee the scope for default function variables.

Highlighted is a function within the same file that checks if the function is derived from an object and then assigns the this variable as a function local variable.

In addition there is a function called DeclareDynamicGlobal that gets used within the declaration of the scope that references this, most likely to change it dynamically based on the current scope.

On the other hand for variable declarations, there is no changing of the this variable within its declaration.

There is more to this function, however, there was nothing reeferencing the two methods, DeclareThis and DeclareDynamicGlobal within this function for declaring the scope of variables.

While I am not too familiar with this source code as I haven't written or contributed to it, I think I was able to make a reasonable assumption as to why functions reassign this but variables do not.

Conclusion

If you made it this far congrats! 🎉

This was a part in the series of Gamify! where I try to write gamified tutorials that go in-depth (to the best of my ability) into a topic while also providing simplifications and steps towards learning more advanced knowledge within the topic. This time we covered Named vs Arrow functions, specifically, how they are the same, but also how they differ as well as providing solutions to common problems faced when handling those differences. Furthermore, we went in-depth into the AST of a Javascript compiler to figure out why and how the compiler made those differences happen.

TIL - Spread and Copying Objects in Javascript

Branden Kim — Tue, 11 Aug 2020 12:57:48 +0000

Background

This is a part of a series of writing a tutorial of what I learn everyday. I try to learn something new related to CS and programming everyday and I believe that writing some sort of post, report, or tutorial from memory really solidifies the understanding and makes it stick in your brain.

Today I learned...

How to utilize the spread operator and how copying objects in Javascript work.

What do you think the code below will output?

let obj = {
    prim: 2,
    anotherObj: {
        val: 'red'
    }
}

let truck = { ...obj }
truck.anotherObj.val = 'blue'
console.log(truck.anotherObj.val) 
console.log(obj.anotherObj.val)

It turns out that the "val" within "anotherObj for both truck and obj will be "blue". This is a bit confusing since shouldn't the two objects be separate since they are stored in separate variables?

Deep vs Shallow Copy

In Javascript, all primitive types are assigned and passed by value, but all objects are assigned and passed by reference. This explains why in the previous code block changing the value of a property of an object resulted in the copy of the object to have its property updated as well.

let obj = {
    prim: 2,
    anotherObj: {
        val: 'red'
    }
}

let truck = { ...obj }

truck.prim = 123123 
console.log(truck.prim) // 123123
console.log(obj.prim) // 2

In this case since we are modifying the "prim" property which is a primitive type it is not reflected across the other object since in Javascript, primitive types are assigned by value not reference.

What does by reference mean?

Passing or assigning by reference means that when copied the new variable holds a reference or "points" to the space in memory where the original object lies. This means that any changes to either the original object or anything that references it changes the values within the original object.

Shallow copies

Using the spread operator or Object.assign() you can create shallow copies of objects!

let obj1 = {
    testing: 'testing'
    nestedObj: {
        nestedTesting: 'nestedTesting'
    }
}

let obj2 = { ...obj1 }

As seen above, the spread operator is "...".

Deep copies

When another object is created with a deep copy, any nested objects are newly created so they don't share the same reference. This means that changes to the copy of the object are not reflected in the original object since a new object is created for the copy.

A way to perform a deep copy is to use the lodash clonedeep package.

Merging Objects

Merging objects can also be performed with the spread operator.

let obj1 = {
    name: 'obj1',
    testing() {
        console.log(this.name)
    }
}

let obj2 = {
    name2: 'obj2',
    testing2() {
        console.log(this.name)
    }
}

const obj3 = {...obj1, ...obj2} // obj3 has all of the properties in both obj1 and obj2

A thing to note is that if there are properties with the same name in the objects, the value of the last object with that property gets assigned.

DEV Community: Branden Kim

TIL - Generating Permutations and API Level Testing

Generating Permutations

API level testing patterns

TIL - Tarjan's Algorithm

Theoretical Properties

Implementation

PC Building! My first experience building a desktop

PCPartPicker

Picking out my parts for my build

Picking out the parts

The Motherboard

PC Case Dimensions

Power Supply Unit

The build process!

The PC Case and the dreaded Wire Management

Don't connect the video card until the end!

Connecting the big boy wires from the PSU

Installing Windows!

Gaming and Linux!

Gamify! - A Gamified Approach to Named vs Arrow Functions

Background

Table of Contents

Introduction

Level 0

What are "Arrow Functions"?

Level 1

Differences between Named vs Arrow Functions

"This" context

How "this" changes

When to use Named vs Arrow

1. Don't use arrow functions as members of an object

2. Use arrow functions within callbacks

3. Use arrow functions within dynamic contexts

Level 2

Arguments Binding

Constructable and Callable

Generators

In-depth explanation of "this" context

Level 3

Patterns for fixing losing this

Level 4

Conclusion

If you made it this far congrats! 🎉

TIL - Spread and Copying Objects in Javascript

Background

Today I learned...

Deep vs Shallow Copy

What does by reference mean?

Shallow copies

Deep copies

Merging Objects

Patterns for fixing losing `this`