Forem: charliekroon

Closures and callbacks in Javascript

charliekroon — Mon, 24 Apr 2023 15:27:15 +0000

In the month of April, I'll publish a small blog series called "Questions from the Past". I'll be going through my old notebooks from my first year as a developer and answering the questions I think are most important. Today we will go into Closures and Callbacks in Javascript.

Closures
Closures are functions that have access to variables from an outer function, even after the outer function has finished executing. This might sound a bit confusing, but let's go through it together.
Imagine you have a function that defines a variable, like this:

function outerFunction() {
  let outerVariable = "Hiiii!";

  function innerFunction() {
    console.log(outerVariable);
  }

  return innerFunction;
}

const inner = outerFunction();
inner(); // logs "Hiiii!" to the console

In this example, innerFunction has access to outerVariable, even though it's not defined inside the innerFunction itself. This is because innerFunction closes over outerVariable, creating a closure that allows it to access the variable's value even after outerFunction has finished executing.

Callbacks
A callback is a function that is passed as an argument to another function and is executed at a later time. Here's an example:

function doSomething(num1, num2, callback) {
  let result = num1 + num2;
  callback(result);
}

function logResult(result) {
  console.log(`The result is ${result}`);
}

doSomething(3, 4, logResult); // logs "The result is 7" to the console

In this example, logResult is a callback function that's passed as an argument to doSomething. When doSomething is executed, it performs an operation on num1 and num2 and then calls the callback function, passing in the result as an argument. In this case, logResult is executed and the result is logged to the console.

That's all there is to it! Once you get a handle on closures and callbacks, you'll be able to write better and more efficient code.

How does useEffect really work?

charliekroon — Wed, 12 Apr 2023 14:38:14 +0000

In the month of April I’ll publish a small blog series called “Questions from the past”. I’ll be going through my old notebooks from my first year as a developer and answer the questions I think are most important. Today we will discuss the workings of the useEffect hook.

useEffect is a React Hook that can be both useful and messy at the same time. I know there are already a bunch of blog posts on this, but I want to make it super clear for you when, how and why you can use it. Let's go into it!

You can use useEffect to perform various tasks, such as fetching data, updating the DOM, optimising performance or cleaning up resources when the component is unmounted*.

Let’s take a look at the useEffect hook, and analyse bit by bit what it does. To begin, here's the basic code for the useEffect hook:

useEffect(() => {
// code to run on every render
return () => {
// clean up!
}
  }, [dependencyArray]);

The dependency array

The dependency array is the second parameter of useEffect. It’s called literally ‘dependency array’ because this is the array that useEffect is dependent on. With that I mean that depending on what's inside the dependency array, your useEffect will either run or not run.

There are three things that you can do with the dependency array:

Leave it empty. useEffect will run only once when the component loads for the first time. This is because there are no dependencies that could trigger a re-run of the code.
```
useEffect(() => {
console.log("The component was loaded for the first time!")
}, []); 
```

Don’t include it at all. useEffect is called on every single state change.

useEffect(() => {
console.log("I ran because there was a state change!")
});

Put a variable inside the dependencyArray. useEffect will run every time that variable changes.

const [dogCount, setDogCount] = useState(0);
useEffect(() => {
console.log(`There are now ${dogCount} dogs!`)
}, [dogCount]);

The return function

The return function (aka the Clean Up function) is called when the component is about the be removed from the screen, or when the useEffect needs to cancel the previous effect.

For example, in this code snippet, the useEffect will fetch user data every time the value of userId changes.

const [user, setUser] = useState(null);

useEffect(() => {
  let isRendered = true;

  fetchUserData(userId).then(user => {
    if(isRendered) setUser(user);
  });

  return () => {
    isRendered = false;
  }; 
}, [userId]);

When the component is first mounted, it uses the fetchUserData function to get the data from the initial userId. If the userId changes while the component is still showing, the useEffect hook makes sure that component only displays the data for the current userId and not the old data.

When the fetchUserData function returns with the user data, it uses setUser to update the component with the new data. This makes sure that the component always shows the correct user data.

So, to sum it up: if you're using React, it's important to know how useEffect works, the dependency array, and the return function. I know it can be confusing at first, but once you get the hang of it, it can really help make your React app better and faster.

*Component mounting is when React creates and adds a new component to the page for the first time. It sets up the component's initial state, properties, and children, and assigns it a unique identifier. After it's mounted, it can be updated with new information.

What is hoisting in Javascript?

charliekroon — Thu, 06 Apr 2023 15:50:34 +0000

In the upcoming three weeks, I’ll publish a small blog series called “Questions from the past”. I’ll be going through my old notebooks from my first year as a developer and answer the questions I think are most important. For this first blog in the series, let’s discuss the concept of hoisting in Javascript.

Despite its name, hoisting in Javascript has nothing to do with lifting something up or moving something around. All it means is that JS sets up memory space for variables and functions that you create in your code. This way, when your code starts running and gets executed line by line, JS can access these variables and functions.

However, when Javascript sets aside that memory space, it doesn’t know what the value of the variables and functions will be. Therefore, it sets a placeholder called undefined.

What’s interesting about hoisting is that the Javascript engine may execute your code in a different order than the way it’s written. That’s because it can access variables and functions that were hoisted before they were even declared in the code. But since the value of hoisted variables and functions is undefined, relying too heavily on hoisting can lead to unexpected results.

Let’s take a look at this code:

console.log(a)
console.log(b)

var a = "I am a variable!"

function b() {
  console.log("I am a function!")
}

In most programming languages, you might expect an error as soon as you try to run this code, but with Javascript, it’s different. Because the memory space is already set aside for the variable and the function before the code is executed, it will not throw an error. What it will do is return undefined. So, while you can technically call functions and variables that are declared later, it’s generally not a good idea to rely too much on hoisting.

So, in summary:

Hoisting in Javascript simply means JS sets up memory space for variables and functions that you create in your code. This way, when your code starts running and gets executed line by line, JS can access these variables and functions.
Variables and function declarations can be hoisted.
It’s best to declare variables and functions before accessing them. This way you’ll avoid weird bugs and undefined warnings in your console.

How to test with RSpec: an extensive beginners guide

charliekroon — Fri, 03 Mar 2023 18:10:41 +0000

I had only been coding for a year when I started working at HackerOne. At HackerOne, we primarily use Ruby on Rails on the backend. However, I only knew JavaScript and TypeScript, so I had to learn Ruby on Rails. On top of that, I had to learn how to write tests with RSpec. Nothing confused me more than the official RSpec documentation, and there was little online content. Because I don’t want you to struggle as I have, I’ve written a beginner’s guide to help you get started with RSpec.

What is RSpec
RSpec is a testing framework used to test Ruby on Rails code. It is designed for behavior-driven development (BDD), which originates from Test Driven Development (TDD). In simpler terms, RSpec allows you to write tests that describe how you want your code to behave. RSpec is intended to test the backend of your app only, as it is solely Rails-focused.

What to test for
Before writing any tests, it’s important to know what to test for. A good rule of thumb is to always look at the implementation first, as it provides guidance when writing a test. As a general rule, you should always test for the following:

What happens in the happy path?
What happens when I create an error or add invalid input? (check the validation)
Am I the right person to make this action? (check the authorization)

Now, imagine we would be creating a second Instagram app. One of the most important models for that app would be the user model. Before we get into testing with Rspec, let’s write a very simple user model.

# models/user.rb
class User < ApplicationRecord
  validates :name, presence: true
  validates :email, presence: true, uniqueness: true
  has_secure_password
end

Great! Now that we’ve got our user model we are ready to write our test. Remember what we just spoke about? To know what we want to test for we want to look at our implementation first. If you had to explain in human language what our model does, you could say that:

it is valid when it has a name, email, and password
it is invalid without a name
it is invalid without an email
it is invalid without a password

Without realizing it, you already wrote half of our test. Let’s finish writing the test that covers the requirements we just described:

# spec/models/user_spec.rb
require 'rails_helper

RSpec.describe User, type: :model do
  it 'is valid with a name, email, and password' do
    user = User.new(
      name: 'Tanya McQuoid',
      email: 'tanya@thewhitelotus.com',
      password: 'yougotthis'
    )
    expect(user).to be_valid
  end

  it 'is invalid without a name' do
    user = User.new(name: nil)
    user.valid?
    expect(user.errors[:name]).to include("can't be blank")
  end

  it 'is invalid without an email' do
    user = User.new(email: nil)
    user.valid?
    expect(user.errors[:email]).to include("can't be blank")
  end

  it 'is invalid without a password' do
    user = User.new(password: nil)
    user.valid?
    expect(user.errors[:password]).to include("can't be blank")
  end

  it 'is invalid with a duplicate email address' do
    User.create!(
      name: 'Tanya McQuoid',
      email: 'tanya@thewhitelotus.com',
      password: 'yougotthis'
    )
    user = User.new(
      name: 'Shane',
      email: 'tanya@thewhitelotus.com',
      password: 'pineappleroom'
    )
    user.valid?
    expect(user.errors[:email]).to include('has already been taken')
  end
end

Let’s break down step by step what we just wrote.

'require 'rails_helper'
RSpec needs to know where your Rails app is and where to find its components. With 'require 'rails_helper' we are loading the Rails application environment, and require access to the rails app.

describe
describe outlines the general functionality of the class or feature you're testing. The describe method has a set of expectations, for example, what a model should look like.

it
With every line that starts with it a new, individual test case begins. it takes a string argument that describes what the test is testing.

If you want to temporarily exclude a test example for your test without deleting it, you can use xit instead of it .

User.create vs. User.new
In Ruby on Rails User.new and User.create are both methods that can be used to create a new instance of the User class. Though they are similar, they do work slightly differently. User.new creates a completely new instance of the User model, but does not save it to the database. To save it to the database, we need to run a separate user.save command. With User.create! you create a new user record and immediately save it to the database in one go.

Within the block it "is invalid with a duplicate email address" we are testing if the email already exists. First, we create a new user record and save it directly to the database with the User.create! command. The ! at the end of the method will help us by raising an error if the user can’t be saved.

Next, we use User.new to create a new instance of the User model with a different name and password, but with the same email. We don’t use User.create! here, because we don’t want to actually save the record. We are only interested in testing its validation.

expect
The expect method allows us to make assertions about the expected code behavior. For example, by writing, expect(user).to be_valid we are making the assertion that the user object is valid.

Additional things
When starting out with RSpec, there were things that confused me, and that I couldn’t find a lot of information about online. We didn’t use them in our code example earlier, but I think they are important to discuss. Let’s take a look at them together.

describe vs. context
In RSpec, context is a synonym for describe. The only difference between the two is that context is meant to indicate that the tests inside it are related to a specific context, while describe is more general. Some people prefer to use context when they're describing a specific scenario, while others use describe for everything. It's mostly a matter of personal preference.

subject
subject lets you declare a single test subject, that is reused throughout our tests. For example, we might write:

RSpec.describe User do
  subject { User.new(
    name: 'Tanya McQuoid', 
    email: 'tanya@thewhitelotus.com', 
    password: 'yougotthis') }

  it 'is valid with valid attributes' do
    expect(subject).to be_valid
  end

  it 'is invalid without a name' do
    subject.name = nil
    expect(subject).to_not be_valid
  end
end

In this example, we are using subject to create a new valid User object that will be used in our tests. We can then reference subject in our test assertions without having to create a new User object each time.

before and after
before and after are hooks that allow you to run your code before and after each example in your test. The before hook is typically used to set up data or variables that are required for your test examples to run.

RSpec.describe User do
  before do
    @user = User.create(
      name: "Armond", 
      email: "armond_themanager@thewhitelotus.com", 
      password: "password")
  end

  it "validates the presence of a name" do
    @user.name = nil
    expect(@user).to_not be_valid
  end

  it "validates the presence of an email" do
    @user.email = nil
    expect(@user).to_not be_valid
  end
end

The after hook is used to clean up (e.g. deleting database records or closing network connections) the data that was created during our test.

let and let!
let is an RSpec method that is lazily defined. Meaning that this method won't be assigned before it's called somewhere in the test. let memoizes the content within its block, which means it’s not going to change the context and it's only going to call and evaluate the context once.

let! is not lazily defined and thus once you define it, the method will be created immediately, even though it's not being called.

We are using let by default, but when you’re testing multiple things, and you need to update that test variable multiple times with different expectations, you can use let!. Then again, a counterargument is that the thing you’re testing is deserving of its own test case.

RSpec is a super powerful tool, but it can be overwhelming at first. It will take some time to learn how to use the framework but by practicing you can learn how to use it effectively. But once you get used to it, writing tests with Rspec will feel like second nature.

What are your experiences with RSpec? How did you learn to use it effectively? And what are your approaches to writing great specs with it?

How to think together; a way to better pair programming sessions

charliekroon — Fri, 03 Mar 2023 16:37:23 +0000

Software Engineering relies heavily on communication with others; teammates, product owners, designers, engineering managers, stakeholders. Yet so often we are trained to work and think alone. This is a shame because working together can lead to higher quality code, a better product, and — in the end — a happier end user.

Software Engineers can collaborate in many ways and forms. One of them is Pair Programming. Pair programming is a software development technique where two developers work together on one machine.

Though this sounds easy, it is not that simple. Pair programming involves a lot of communication and collaboration. It requires empathy and interpersonal skills and it can be difficult to manage a successful session. Pairing is an amazing tool, but it is a tool that we need to practice together before we can reap its benefits.

Let’s go over some ways to learn how to think together.

Set a clear goal and remember it
At the start of a pairing session, you need to discuss the scope of the session. What is it you want to achieve? When is that goal met? How much time do we want to spend? Make it clear for both of you what it is you want to get out of the session before you start.

Your way is not the only way
There are thousands of ways to look at a problem, implement code, or debug something. The key is that we must never think our way is the only correct way. Pairing is not a race where only one person can win. You both want to solve a problem, which is finishing the task you’re working on. You’re both on the same team. Take time to analyze your colleague’s solution before pushing yours onto them.

Be aware of the knowledge gap
One of my early pairing experiences was with a programmer who was much better than me. They bulldozed through the problem and seemed to have forgotten there was a huge knowledge gap between us. Seeing this much more experienced programmer taking up all the space made me feel intimidated and I got scared to speak up, ask questions, and share ideas.

Though it’s understandable that I shut down, it’s unnecessary. I learned later on that — when my pair has more experience on a topic — asking questions is beneficial for both of you. It can lead to fruitful discussions and better solutions. Even though your co-worker has more experience, explaining certain topics is just as valuable to them as it is to you.

When you’re the more experienced one in a pair, don’t assume that the other person can’t contribute. You might be wearing blinders when approaching a problem, and a different view can lead to a better solution.

Reflect
Pair programming can be mentally exhausting and draining. Reflect during the session to assess if the pace is manageable and sustainable. If it’s not, adjust accordingly.

When we learn how to explain ourselves, work well together, listen actively and treat each other with respect and kindness, we can get the most out of pair programming. It’s just a skill that we need to learn, that’s all.

A step-by-step guide on debugging

charliekroon — Fri, 23 Dec 2022 16:59:15 +0000

When I started working as a Software Engineer 2.5 years ago, bugs were intimidating to me. I did not know where or how to start debugging and it felt like an enormous task I would never be able to tackle alone.

I often wished for a step-by-step guide on how to approach the debugging process. I never found one, so I decided to create my own.

Step 1
Slow down and be methodical
When debugging, it’s of great importance that you work as methodically and cleanly as you possibly can. Change one thing at a time, write down the steps you’re taking, and note down your thoughts. By working as clean and controlled as possible, you avoid digging yourself into a hole of bugs, and it’s less likely that you’ll introduce a new bug by making an unnecessary change.

Step 2
Investigate
To solve a bug, you need to understand it. To understand the bug, you need to ask yourself a lot of questions, such as:

Is the code being called?
Am I missing a file?
Is this route correct?
What does that parameter do?
What is the value of that variable?
Is the function in the server, in the client, or, — when debugging a test — in the test?
Did I introduce the bug with my latest change, or was it there all along?
Is that function doing what I think it’s doing?
Am I working on the correct file?
Which function is returning that incorrect value?
What is the error message actually telling me?
Is this happening in my code or in the library that I am using?
Can I write a test to reproduce the bug?

Step 3
Trust, but verify
Oftentimes I make assumptions that I wholeheartedly believe and don’t even think of questioning. I tell myself things like: ‘I wrote the variable name correctly’, ‘the bug was introduced by the last change I made’ or ‘this function does X’. Hours go by until I figure out that that variable name had a typo, that the bug was always there, but my last change had brought it to the surface, or that the function was, in fact, not doing X. You can trust your assumptions, but verify them.

Step 4
Set a timer and ask for help
The difference between working in a team with other engineers, and working on your personal projects, is that there is no unlimited amount of time to spend on bugs. When you put your name on a ticket in the sprint, you basically say: ‘hey, I take responsibility for this issue. I’ll make sure it’s finished.’ Taking that responsibility doesn’t mean that you need to do everything alone. It means you’ll finish the issue and make it ready to be shipped to production in a timely manner. Sometimes that means that you need the expertise from someone else.

A way to find the balance between asking immediately for help and trying to fix an issue alone for days is to set a timer for an hour. If the bug is still not fixed by then, you can message your coworkers.

Here is a template of the message you can send:

This is what I am trying to do
I did … and I expected … to happen, but instead … happened
I have tried …, … and … to fix it, but …
I think the reason why this is happening is that…
This seems to be possible/impossible, because …

Step 5
Take a break
Investigating a bug requires a lot of focus. The longer you work on a bug, the more likely it is that you’re missing things. Take a break, go outside, cook, clean the kitchen, take a shower, work out, hang out with your friends, take a nap, watch The Office. When you come back to your bug, chances are that everything is a lot clearer.

There is always a logical reason behind a bug. Sure, some bugs take a bit more time to figure out, but nothing is ever unexplainable and thus solvable. The nastier the bug is, the better of an engineer you’ll become, I promise.