First I want to remind you what was Prototype Pollution. In JavaScript, we use Prototype for OOP. Yes, we use “Class” syntax but under the hood, it transpile to “Prototype”.

Let me show you a little example:

I’ve defined an empty object whose name is obj1. After that, I changed the original toString method of it. But it will not change toString method only for obj1 . It will affect all objects toString method.

Let’s create another object and check for toString method:

As you can see, even if the obj2 object is newly created, it has our mutated method.

We’ve talked about how attackers use these tactics to hack our code in a previous article. So let’s try to write real real-life example.

I already created a repo and if you want to try these examples, you can reach it from the link below:

GitHub - CaglayanYanikoglu/defensive-coding

So in this repo, we have authz.js and attacks folder. I want to give brief information about what authz.js does.

Let’s dive into the code above. We have one parent function makeAuthzManager . In that function, we have internals object with secrets. But the important function is authorizedFetch . This function takes requests as params and adds tokens to headers. It’s a basic function. In the attacks folder, we will try to attack and get to tokens without permission. We have 4 example attacks and I will try to explain attacks and how to defend them.

Attack 1:

In the first attack, attacker override reduce function. Now whenever the reduce function is called, attacker’s reduce function will work. In authz.js, just check the line 41:

const authorizedRequests = requests.reduce((acc, request, index) => {

As you can see, we use the reduce function for requests, but the attacker has changed it. Our code is vulnerable to these attacks.

So how we prevent this attack?

When we call requests.reduce, we are using attacker “reduce” function. Because he/she changed from object proto function. We have to use the clean reduce function.

To do that, we have to call Array.prototype.reduce function.

Now we removed requests.reduce and we called the reduce function from the original array prototype. So we prevented the first attack. Yayyy!!

Attack 2:

In the second attack, the attacker change set method for Authorization in the headers object. Now our headers object has been mutated.

const { url, headers, method } = request;
headers.Authorization = "Bearer " + internals.secrets[index];

When we set our secret token in the code above, the attacker reaches our secret token. Because when we set headers.Authorization, it will call attacker’s mutated set function.

So how we prevent this attack, again?

Actually, the answer is easy. When we use headers, we will create our own object and set the “Authorization” attribute. The second attack is dismissed too 🎉🎉.

Attack 3:

This attack is a more sneaky one. The attacker, define to Object.prototype new secrets set method. In our code when we create a new object and try to set secrets, the attacker will receive our props. The attacker created a new stolen variable and put a new variable in the set method.

const internals = {};

internals.guessLimit = 2;
internals.secrets = [];

setSecrets: (secrets) => {
  internals.secrets = secrets;
}

So if you check our authz.js code above, when we create internals object, it has already mutated the set method for secrets. So when we set secrets, the attacker gets our secrets.

What is the defense solution here?

When an attacker changes the object prototype, whenever we create a new object, it will be mutated. So we have to create an object without a prototype.

  const internals = Object.create(null);

If we use Object.create(null) a method with a null parameter, it says: Create a new object without prototype. Because Object.create() method takes the parameter as a new prototype object. If we give null, it won’t be any harmful or mutated prototype. Because there will be no prototype at all. Btw, it’s not a good idea to do that but I will explain in Part 3 :)

Attack 4:

Let’s assume the attacker is a clever and experienced one. And he/she could think that we will prevent the attack 3 with Object.create() method.

What a wonderful attack, right? The attacker will mutate Object.create() method. In attack 3, we created a new object with Object.create and give null as a parameter right. In this way, we secured the clear prototype. But now, an attacker overrides Object.create method and if the parameter does not exist, it gives an empty object.

return create(proto || {}, props);

Look at this code above. Take the proto and if not exist, using || to give an empty object. With that move, now attack 3 is enabled again.

So how do we defend this crazy talented hacker, right?

We will use create method from directly the original Object. Now if use this Create method, we will ensure, it is not mutated.

I guess that’s all from this article. I know it’s a very complicated topic. I tried to explain all the details. I would like to talk about this topic very much. I’m also learning :)

So, how can we secure our code?

I know, you all asking, how can we write all this code on our own? Because there are a lot of vulnerable codes, and we can not prevent all of them.

I will talk about good solutions in Part 3. I hope you enjoyed while reading this.

So, I guess that’s all from me for this week. For more advanced JavaScript and React articles, feel free to follow me. You are welcome to write your responses, I always read and answer them. :)

CaglayanYanikoglu - Overview

Linkedin

Twitter

Stackademic

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord
• Visit our other platforms: In Plain English | CoFeed | Venture

Write Secure Code in JavaScript: Prototype Pollution Part 2 was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

In these articles, I will talk about:

• What is Prototype in JavaScript? (Summary)
• What is Prototype Pollution?
• How do NPM packages turn malicious?
• Examples of attacks & and how to defend them.

What is Prototype in JavaScript?

• The prototype is a fundamental concept in JavaScript that enables object-oriented programming.
• In JavaScript, every object has a prototype, which serves as a blueprint or template for the object.

So we are using Classes in Javascript for object-oriented programming, right? Actually no. We are using Class syntax but under the hood, JavaScript uses “Prototype” for object-oriented. Classes are not the same as other OOP languages. Yea, it’s a kinda confusing thing but, in JavaScript, everything is coming from an object.

While JavaScript has introduced the class syntax to make it more familiar and convenient for developers coming from languages with classical inheritance, JavaScript itself uses prototypal inheritance.

When you try to access a property or method on an object, JavaScript first looks for it in the object itself. If it’s not found, it continues searching in the prototype chain.

Prototype chain: If a property or method is not found in the object, JavaScript looks up the chain until it finds the corresponding property or method or reaches the end of the chain (null).

• Constructors are used to create objects and define their initial properties.
• Objects created by a constructor have a prototype property that points to the constructor’s prototype object.
• Each function in JavaScript has a special property called prototype.
• The prototype object is used as the prototype for objects created by the constructor.

As you can see in the screenshot above, “person1" has a name property. But also it has [[Prototype]] object and this object has sayHello function.

Briefly, in JavaScript, everything is, indeed, centered around objects. I hope what I have explained has shed some light for you. Because this topic is one of the most difficult ones to understand.

What is Prototype Pollution?

So we talked about Prototype, but what is Prototype Pollution? How can be harmful right?

JavaScript Prototype Pollution is a security vulnerability that occurs when an attacker manipulates the prototype of an object to introduce malicious properties or methods. I will talk about how they attack it and how to defend against them in Part 2.

• JavaScript allows the modification of an object’s prototype dynamically during runtime.
• Attackers can extend or modify the prototype chain of objects to introduce malicious properties or methods.
• By polluting the prototype, an attacker can affect all instances of objects derived from that prototype.
• This pollution can impact the behavior of functions and methods that rely on the prototype chain for property and method lookup.
• Often, the targets of prototype pollution attacks are libraries and frameworks that dynamically process user input or third-party data. For example: NPM packages.
• Attackers exploit vulnerabilities in the parsing and handling of data, leading to pollution of prototype objects.

In the screenshot above, we changed the toString method. After we call toString method, our (attacker) method will override original toString method.

Prototype pollution can lead to unexpected behavior, data leakage, or unauthorized access. It is a serious security concern, as it can be exploited to compromise the integrity and confidentiality of an application.

Understanding and mitigating prototype pollution is essential for building secure JavaScript applications, especially when dealing with user input or third-party data. Regular code reviews and adherence to security best practices are crucial in preventing such vulnerabilities.

In this part, I tried to explain Prototype and Prototype Pollution as much as I could. In the second part, I will talk about how NPM packages turn malicious, examples of attacks, and defend them. Wait for the second part :)

So, I guess that’s all from me for this week. For more advanced JavaScript and React articles, feel free to follow me. You are welcome to write your responses, I always read and answer them. :)

CaglayanYanikoglu - Overview

Linkedin

Twitter

Stackademic

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn, and YouTube.
• Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.

Write Secure Code in JavaScript: Prototype Pollution Part 1 was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Usually, I use the “Grouping by file type” pattern in my projects. Because I like to commonize my functions a lot. But as I mentioned in my previous writing, if the project is big, a “Feature-based” pattern would be better.

In the screenshot above, you can see, I separated files by their type. I will not talk about folder details because I’ve already written in a previous article.

What are the tips for folder and file structures in React?

1- ) “shared” folder for common things

We have a components folder right, every project has this. In this folder, we hold page components in their name.

For example, you have 3 main pages in your application and you created their pages and their related components. For sure, on every page, there will be specific components for only that page. After you implement these components, you will need “Button”, “Modal”, etc components. These components will be used for multiple pages.

I always create a “shared” folder to put common components into that folder. You can see common components in the screenshot below:

2-) “index.js” for every component, page, etc…

In this pattern, we create “index.js” for every component and page. I love this pattern but what are the benefits?

In the application, if we want to import a Button component, we should call it like this:

import Button from "./components/shared/Button/Button.js";

It’s very bad looking though. “Button/Button.js”. Let’s create index.js.

Basically, we import the Button component and export it from index.js. We don’t have to write “Button/index.js”. Because it already looks for index.js.

import Button from "./components/shared/Button";

Now it seems more clear.

There’s also, an easy and more fancy way to import and export components as seen in the screenshot above :).

3-) Import files to one file and export from it

For example: In “shared” components, I’ve also created index.js. I import all components from “shared/index.js” like the below screenshot.

But why?

For example, in some components, I need the “Modal”, “Button” and “Dropdown” components. My code will be like this:

import Button from "./shared/Button";
import Modal from "./shared/Modal";
import Dropdown from "./shared/Dropdown";

It will cause a lot of lines and complexity will go crazy. When I export all these components from shared/index.js, this code transforms into this:

import { Button, Dropdown, Modal } from "./shared";

It’s great, right? Usually in one component, there are a lot of internal and external imports. And if we do not use this method, we can not follow which file comes from where.

4-) Get rid of relative path hell

import Modal from '../../../../../../components/Shared/Modal';

Most likely, you called some file with a similar relative path like above. When we want to import a file from somewhere on another main path, we have to go main path then we have to call it. It’s very confusing and bad-looking, right? And if we change the file place, we have to fix all routes.

Create jsconfig.json in your main folder. Then add this below code.

{
  "compilerOptions": {
    "baseUrl": "src"
  },
  "include": [
    "src"
  ],
  "exclude": [
    "node_modules",
    "build"
  ]
}

After that, you can call files with absolute path. For example:

import Modal from 'components/Shared/Modal';

5-) Keep components length short

Last but not least, I always try to keep my component in maximum line height. This is for me “200” lines for advanced components. I always separate big components into small parts.

So, I guess that’s all from me for this week. For more advanced JavaScript and React articles, feel free to follow me. You are welcome to write your responses, I always read and answer them. :)

CaglayanYanikoglu - Overview

Linkedin

Twitter

Stackademic

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn, and YouTube.
• Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.

React Folder/File Structure Patterns and Tips: Part 2 was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today I will talk about my favorite folder structures and tips. When I wrote my first React application, I remember all the time I was looking for how the structure should be. So I know a lot of new programmers are confused about that. I will try to tell the best practices that I learned. I will divide this topic into two parts. The first one will be about folder structures and the second will be about best practices.

Introducing DifferAI

Before my recommendations, Is there a recommended way to structure React projects?

React Documentation answers this question:

React doesn’t have opinions on how you put files into folders. That said there are a few common approaches popular in the ecosystem you may want to consider.

Yes, maybe you have already seen that. So what are these popular approaches?

• Grouping by features or routes
• Grouping by file type
• Atomic Design

We can extend this list but I will explain only three of these.

1- Grouping by features or routes (Feature-Based Pattern)

The Feature-Based Pattern is like organizing your code in a React app by grouping similar things together. Each group has all the stuff needed for a specific job in the app, like building blocks, tools, and other necessary things.

Imagine these groups as separate boxes that you can add, remove, or change without messing up the rest of the app. This way, you can also use the same stuff in different parts of the app to save time and effort.

I will create a simple folder structure with feature-based.

In the above screenshot, I’ve created four main folders.

• src/app: It’s a main application folder.
• src/features: We hold all features in that folder. Each feature has its own components, services, tests, .etc in this folder.
• src/shared: In the application, we will have a lot of common components, services, etc. We will keep these common files in the shared folder.
• public: This is for static files like images, icons, etc.

If you have a big application, or if you think the application will grow too much, you can consider using a feature-based folder structure. In this pattern, we can separate our features and it will be a very clear folder structure.

Advantages

The best thing about this setup is that it’s really easy to add or change the code. Because the code is divided into different parts (features), you can easily add new parts or improve the ones already there. This split also makes the codebase simpler, as some files can be considered private, which helps you understand the code better.

Another good thing is that the code outside the features section is usually straightforward to grasp. Most of the important stuff is neatly packed inside the features section. This makes it simpler to understand and work with the code.

Disadvantages

The main downside of this setup is that it can get a bit complicated. If you’re working on a big application, this added complexity isn’t a big problem, because it actually makes the whole project less complicated. However, if your app is small and only has a few parts/pages, this system might end up being too much. Many of the folders might not even be used, or they might only have a few files. Because of this, I suggest using this folder structure mainly for bigger and more advanced projects that really need this extra separation.

2- Grouping by file type

This is my favorite folder structure for small-medium-size projects. We create folders for each type in the src folder. Every folder could have a common folder that contains shared utilities.

In this pattern, we avoid too many nestings, unlike feature-based patterns. But if we have a lot of features in the project it can be a complex structure.

Advantages

• Easy to Find: You can quickly locate files because they’re organized by their purpose.
• Less Messy: When your app gets bigger, this keeps things tidy and helps prevent confusion.
• Readability: Others can understand your code better when it’s organized logically.
• Reusable Code: You can easily reuse common pieces of code in different parts of your app. Which is my reason for using this pattern.

Disadvantages

• Lots of Folders: It can get overwhelming with many folders, making it harder to find things.
• Learning Curve: New team members might take time to learn where everything is.
• More Updates: Changing file locations or names can cause problems with how files are connected.
• Some Complexity: Sometimes, files might belong to more than one category, which can be tricky.

3- Atomic Design

I believe you heard about Atomic Design in your life at some point. Atomic Design is a methodology for creating design systems and organizing code in a way that promotes reusability, scalability, and maintainability. It’s a hierarchical approach that breaks down user interfaces into smaller, reusable components.

In Atomic Design, components are organized into five distinct levels based on their complexity and reusability. These levels are:

1. Atoms: Atoms are the smallest building blocks of your UI. They represent individual HTML elements like buttons, input fields, labels, and more. Atoms are highly reusable and have minimal dependencies.
2. Molecules: Molecules are combinations of atoms. They represent simple UI components that have a specific functionality. For example, a search bar might be a molecule composed of an input atom and a button atom.
3. Organisms: Organisms are more complex UI components that combine multiple molecules and/or atoms to form a functional unit. An example could be a header component that includes a logo (atom), navigation (molecule), and a search bar (molecule).
4. Templates: Templates are higher-level structures that provide a layout for arranging organisms and molecules on a page. They define the overall structure of a page without containing the actual content.
5. Pages: Pages are instances where you populate templates with actual content and data. They represent the final product that users interact with.

Conclusion

My advice is to choose your familiar file structure. Just try to avoid too many nestings. If you have deep directory nesting, the project can be bad DX(Developer Experience).

React says don’t overthink it. Don’t spend more than five minutes to choose file structure. This is React documentation’s advice. As the project grows larger, you can mix these patterns and that would be not a problem.

For second part of this article:

React Folder/File Structure Patterns and Tips: Part 2

So, I guess that’s all from me for this week. For more advanced JavaScript and React articles, feel free to follow me. :)

CaglayanYanikoglu - Overview

Linkedin

Twitter

👉 Also learn about these 11 useful React tips and tricks to boost your app’s performance:

11 Useful React.js Hack Every Developer Should Know

Stackademic 🎓

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord
• Visit our other platforms: In Plain English | CoFeed | Differ
• More content at Stackademic.com

React Folder/File Structure Patterns and Tips: Part 1 was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello everyone. Welcome to #SundayTechMusings. Today, I will write about a really important aspect of React that will broaden your understanding of React Mount and the key property. Last week, while working on a project, I encountered a significant issue in React. The problem was small, but I couldn’t figure out how to fix it, and it was quite frustrating. However, after investigating the issue and trying different approaches, I discovered an incredible solution.

What was the issue?

Here is some simple code to illustrate the problem.

Imagine we have an app with an Input component that holds a state value for the input type. When we click a button, the input type will toggle between “name” and “email.”

Here’s the code for the Input component:

Take a look at the above code and try to identify what’s wrong. As you can see, there are no mistakes in these simple components.

Let’s demonstrate the problem with a GIF.

As you can see, when we click the button to change the type, although the Input component changes, the input value remains the same. This is not the behavior we desire.

So, why does React act like that?

The reason is that in the code, we have the same Input component in the same place. When we change the type, React still considers it as the same component, which is true to some extent.

React renders the component, but it doesn’t remount it. React does this to avoid unnecessary remounting. We need to inform React that it’s a different component.

What are the solutions?

As mentioned above, we need to remount this component and notify React that it’s an entirely different component.

The first solution is to change the order and placement of the components.

Now, if you review the updated code above, you’ll notice that we have div and main wrappers. Therefore, React will recognize them as different components and remount them. The problem is resolved.

Cool, right? However, we had to introduce additional HTML elements, which is not an ideal solution. It could potentially break styles, and it adds unnecessary complexity to the code.

The second solution is amazing: adding a key prop to the Input component. I can already hear some of you saying, “What the heck?” 😄

By simply adding a key prop to the Input component, we tell React that it’s a new and distinct component. We are all familiar with adding keys to list elements, right? In a similar way, by assigning keys to these components, React can efficiently identify and manage their state.

In some cases, components may be conditionally rendered or created dynamically. By providing a key to these components, you can help React differentiate between different instances of the same component and optimize re-rendering. This can be particularly useful when you want to preserve the state of specific components across re-renders.

That’s all from me for this week. For more advanced JavaScript and React articles, feel free to follow me. :)

If you find this content helpful and would like to show your support, you can buy me a beer🍺😊
Buy Beer🍺

CaglayanYanikoglu - Overview

Linkedin

Twitter

Most Senior React Devs Don’t Know How To Fix This / Keys in React was originally published in Jotform Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello everyone. In this week's #SundayTechMusings, I will talk about my favorite JavaScript topic: async operations. I’m very excited about it actually :). This article will be the fifth installment of the “A Journey to the Center of JavaScript” series 🚀.

You can catch up on the previous four articles here:

• A Journey to the Center of JavaScript
• A Journey to the Center of JavaScript — Episode 2: Hoisting
• A Journey to the Center of JavaScript — Episode 3: Closure
• A Journey to the Center of JavaScript, Part 4: IIFE

I want to start with a little advice. When most junior developers try to learn web programming they make the same mistakes. They focus on learning React, Vue, or some other popular libraries even if they don’t know the basic cores concepts of JavaScript. I always advise my students to learn the logic of the code. Otherwise, they can just take some code parts from websites like Stackoverflow and if the code works they don’t search anymore.

Today I will talk about the logic of JavaScript and how JavaScript handles async operations with a single thread.

What is async?

I want to give a real-life example to explain async operations. Let’s say, you go to Starbucks to get a coffee. After you order, the next person doesn’t have to wait for your coffee to be ready to order theirs. While one barista is getting your coffee ready, another is still taking the orders. This is the basic description of async operations: Doing multiple jobs at the same time.

I’ve mentioned before that JavaScript is a single-threaded language, meaning it can do one job at one time. So how does JavaScript handle multiple tasks in one thread? Because it often needs to perform tasks that take time, such as making network requests, reading from a file, or waiting for user input.

Before answering that, I would like to give async examples in JavaScript.

What are the async processes in JavaScript?

• API calls
• Promises
• SetTimeout function
• DOM manipulation
• Reading from file

In the above operations, JavaScript does not wait for an answer. You have to tell JavaScript that it’s an async process. You can do that with the promises or async await keywords.

If you execute the code below you will see console output in this order:

• first
• third
• second

That’s because setTimeout function will execute this code after a minimum of two seconds. I said minimum because it will wait for the other functions to execute. That was easy. What about if we put a 0 second delay?

What will be the output?

You may think a 0 second delay won’t change anything and the console output would be “first, second, third.” Or some of you may think it depends on execution time and it changes randomly each time.

The right answer is actually always the same as above.

• first
• third
• second

At this point, we must understand how the JavaScript engine works.

Event loop

Some people confuse the event loop with events in HTML. But actually, an event loop is a different fundamental concept. Basically, an event loop helps JavaScript handle these tasks efficiently.

The event loop works by constantly checking two main sources: the call stack and the event queue. The call stack keeps track of the functions being executed at any given moment, while the event queue holds tasks or events that are waiting to be processed.

When the function is called, it is stored in the call stack. After the function is executed, it is removed from the call stack. Here’s a simplified step-by-step overview of how the event loop works:

1. The JavaScript engine starts executing code from top to bottom, adding function calls to the call stack as it encounters them.
2. If a function encounters an asynchronous task (e.g., a network request or a timer), it delegates the task to the browser’s Web APIs or other runtime environments, which handle the task in the background.
3. While the task is being processed, the JavaScript engine continues executing the remaining code without waiting for the task to complete. This is the non-blocking nature of JavaScript.
4. Once the task is completed, it’s placed in the event queue as an event.
5. The event loop continuously checks if the call stack is empty and if the event queue has any pending events. If the call stack is empty and there are events in the queue, the event loop takes the first event and pushes its associated callback function onto the call stack.
6. The callback function is then executed, and if it contains any further asynchronous tasks, the process is repeated from step 2.
7. This cycle continues indefinitely, with the event loop constantly checking the call stack and event queue and moving tasks from the event queue to the call stack as they become available.

You can check this image and this GIF to understand how event loop works:

In the above GIF, you can see how JavaScript handles all tasks with a single thread.

By using this mechanism, the event loop allows JavaScript to handle asynchronous operations efficiently while ensuring that the user interface remains responsive. It prevents blocking or freezing of the user interface by ensuring that long-running tasks are executed in the background and their results are processed when the call stack is empty.

It’s important to note that JavaScript itself doesn’t directly control the event loop. The event loop implementation varies depending on the runtime environment in which JavaScript is running, such as web browsers or Node.js.

To sum up

JavaScript handles all these async tasks with an event loop. As I mentioned above if you know the logic behind the code, you can build much better, more optimized structures.

That’s it for this week's #SundayTechMusings. If you want to get more content on advanced JavaScript and React, you can follow me and subscribe to get emails.

If you find this content helpful and would like to show your support, you can buy me a beer🍺😊
Buy Beer🍺

CaglayanYanikoglu - Overview

Twitter

Linkedin

A Journey to the Center of JavaScript, Episode 5: Async Js & Event Loop was originally published in Jotform Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Check out the previous three articles in this series below.

• A Journey to the Center of JavaScript
• A Journey to the Center of JavaScript — Episode 2: Hoisting
• A Journey to the Center of JavaScript — Episode 3: Closure

IIFE (immediately invoked function expression)

IIFE is a function that is defined and executed immediately in the same line of code. The main purpose of an IIFE is to create new scope in your code, which can help to avoid naming conflicts and keep your code more organized.

In the example above, we define an anonymous function and immediately invoke it with parentheses at the end. The function will execute right away without calling from anywhere.

Why should we use IIFE, and what are the benefits?

One of the benefits of using an IIFE is that it can help to prevent global namespace pollution. In other words, we cannot reach function variables or functions outside IIFE. This can be crucial in some scenarios, like working with large codebases with many developers.

Also, it reduces the risk of naming conflicts and can make it easier to reason about your code.

A real-world example

Let’s say you’re developing a web application with your team. That application has a filter feature in which users can filter a large dataset by various names, dates, categories, etc.

To avoid polluting the global namespace with the filter-related variables and functions, you can wrap the entire filter logic in an IIFE. IIFE creates a new scope for the filter-related code, which keeps it separate from other parts of the application.

In this above example, the data variable and three filter functions are defined inside the IIFE. As I mentioned, these variables and functions in IIFE are not accessible from outside the IIFE, which helps to prevent naming conflicts with other parts of the application.

To sum up

Using an IIFE helps to keep the filter-related code organized and separate from other parts of the application, which can make it easier to maintain and debug.

Watch for more articles about advanced JavaScript and React in #SundayTechMusings. And for more content like this, you can follow me on GitHub, Twitter, or LinkedIn to catch more on these topics.

See you for the next #SundayTechMusings.

CaglayanYanikoglu - Overview

If you find this content helpful and would like to show your support, you can buy me a beer🍺😊
Buy Beer🍺

A Journey to the Center of JavaScript, Part 4: IIFE was originally published in Jotform Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello, everyone. In the third installment of A Journey to the Center of JavaScript, we continue with closures. We started with primitive and reference value types in the first article. My second article was about hoisting. You can start with these articles if you haven’t read them. I hope you enjoy this week’s #SundayTechMusings :).

The third post in this series is about closures. Today I will give an example from one of my daily routines at Jotform because it’s very instructive.

But before we talk about closures, I want to give brief information about lexical scoping.

Lexical Scoping

Lexical scoping is a fundamental concept in JavaScript that helps determine how variables and functions are accessed in different parts of your code. In simple terms, lexical scoping refers to the way JavaScript code defines the scope of a variable or function based on its location within the code’s block structure.

To understand lexical scoping, it’s important to first understand what a scope is. In JavaScript, a scope is a set of variables, functions, and objects that are accessible in a particular part of the code. A scope can be either global or local. Global scope refers to variables or functions that are accessible throughout your entire codebase, while local scope refers to variables or functions that are accessible only within a particular block of code. This is an important part to understand the difference between var and const, let.

Now, let’s look at how lexical scoping works. In JavaScript, when a function is defined, it captures the scope in which it is defined. This means that the function can access any variables or functions that were defined in the same scope, as well as any variables or functions defined in any outer scopes.

In the above example, the console output will be “Caglayan.” As I mentioned, you can reach outer variables from inner functions.

Scoping with let and const

Mdn Says:

Traditionally (before ES6), JavaScript only had two kinds of scopes: function scope and global scope. Variables declared with var are either function-scoped or global-scoped, depending on whether they are declared within a function or outside a function. This can be tricky, because blocks with curly braces do not create scopes.

My sincere advice is not to use var as I mentioned in my post on hoisting.

In the above code, you may think that it will throw an error. But it won’t. It will give a name value depending on the if condition. Because unlike const and let ,varstatements create global variables.

This time, it will throw an error because the let variable is declared in function scopes. We cannot reach that from outer scopes.

What is a closure?

A closure is a feature in JavaScript that allows a function to access variables and parameters from its outer (enclosing) function, even after the outer function has returned. In other words, a closure is a function that has access to variables and parameters from its parent function, even after the parent function has completed execution. If you are familiar with event loop in JavaScript, after function execution, the function is removed from the call stack. (If you’re not familiar with this topic, it’s OK. I will cover it in a future article.)

To create a closure in JavaScript, you need to define a function inside another function. The inner function has access to variables in the outer function’s scope, even after the outer function has returned.

In this example, outerFunction takes a parameter x and returns innerFunction. innerFunction takes a parameter y and returns the sum of x and y.

When we call outerFunction(5), it returns innerFunction, which we store in the addFive variable. When we then call addFive(3), it adds 3 to the x value passed to outerFunction, which is 5, and returns the sum 8.

The key point to understand here is that innerFunction has access to the x parameter of outerFunction, even though outerFunction has completed execution and x is no longer in scope.

Closures are useful in many scenarios, such as in creating private variables and methods in object-oriented programming, or in managing state in functional programming. However, they can also cause memory leaks if not used carefully, as the outer function’s variables and parameters are not garbage-collected even after the function has completed execution.

A real-life example of a closure

Now that we’ve defined closure, I want to share the example of one that I mentioned in the beginning.

If you worked with backend search in your application, you know the debounce function. If you don’t, take a look at my debounce article.

In debounce function we should keep the timeout variable. We should keep the timeout variable in the outer function because every time we call this function, it must stay the same. So this is why we use closures. If we do not use closures, every time we create a new setTimeout function, it won’t work correctly.

To sum up

The closure is very useful. It’s also covered in many interviews for front-end positions, so you should understand the logic of it.

This was the third article of my “Journey to the Center of JavaScript” series. Follow me for more posts on advanced JavaScript and React. See you in the next #SundayTechMusings.

CaglayanYanikoglu - Overview

Twitter

Linkedin

If you find this content helpful and would like to show your support, you can buy me a beer🍺😊
Buy Beer🍺

A Journey to the Center of JavaScript — Episode 3: Closure was originally published in Jotform Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

This topic is actually related to performance. For some background on techniques for optimizing performance, check out my Performance Optimization Techniques on this topic.

A lot of people think “return null” and “return false” are the same. While they’re very similar, there are some differences related to how React works.

When developing with React, it’s common to use conditional rendering to display different components based on certain conditions. In some cases, you may want to explicitly indicate that a component should not render. This is where null and false come in. While both of these values prevent the rendering of a component, there are important differences between them.

Returning null

When a component returns null, it tells React not to render anything in the DOM for that component. This can be useful when you want to conditionally render a component based on a certain state, but don't want anything to be displayed when that state is not met. For example:

In the above example, if the name prop is not provided, the component returns null, which prevents the <h1> element from being rendered. If the name prop is provided, the component renders the <h1> element with the greeting. This is the classic way of doing this.

Returning false

When a component returns false, it tells React not to render anything in the DOM for that component, just like null. However, there is an important difference: returning false also prevents the component from updating in the future. This is because React interprets false as a signal to “unmount” the component, which means removing it from the DOM entirely.

Here’s an example of a component that returns false:

In this example, if the onClick prop is not provided, the component returns false, which prevents the <button> element from being rendered. If the onClick prop is provided, the component renders the <button> element with the specified click handler.

It’s important to note that returning false can have unintended consequences, such as preventing the component from updating when it should. For this reason, it’s generally safer to use null when you want to prevent rendering without affecting future updates.

Returning false from a component’s render method is only useful when the component doesn’t have any side effects, such as updating state or triggering API requests. If a component has side effects and returns false, those side effects will still happen, which can lead to unexpected behavior.

react/ReactElementValidator.js at main · facebook/react

If you check the above code in the React library, you will see a “null” check. For a better understanding of how React works, check out this code.

To sum up

In summary, returning null and returning false both prevent a component from rendering anything in the DOM, but there are important differences between them. null is a simple way to conditionally render a component without affecting future updates, while false signals to React to unmount the component and can cause unintended consequences. It’s important to choose the right option for your specific use case.

For more on advanced React and JavaScript, check out my other posts and subscribe to email updates.

If you find this content helpful and would like to show your support, you can buy me a beer🍺😊
Buy Beer🍺

See you next week at #SundayTechMusings

CaglayanYanikoglu - Overview

Linkedin

Twitter (TR)

Understanding “return null” vs “return false” in React was originally published in Jotform Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

In React, we usually hold our data in states. When data changes, React will render the new data on the screen for us.

So the state is like a kind of storage. setState or useState are functions to change state values. Let’s look at the useState hook using the function component.

useState is one of the most-used hooks.

In the above code, I wrote one basic component. We have count value that we store in the state. The useState function’s parameter is the default state value. In our code count value will be 0 at the beginning.

Every time we click the button, we increase the count value by 1. So setCount function arg is the new state value for the count. This code works without any problem. So let’s change setCount a little bit.

The above code works the same as before. So what’s the difference between setCount functions? This time, we’ve used the callback function in setCount.

Why do we need a callback in setState?

In the case of the function argument, it can be useful to use a callback function with setState to ensure that the state update is performed correctly. This is because setState may update the state asynchronously, and if you need to perform some action that depends on the state being updated immediately after calling setState, you cannot rely on the state to have been updated yet.

Here’s a simple example:

In the above code, we update the count state asynchronously in increaseCountAsync. If we don’t use a callback in setState (in our case setCount), it will give unreliable results.

As you can see in the above GIF, when the increaseCountAsync function was called, the count value was 2. After clicking several times on the “Increase Count” button, the count value is 11. But when increaseCountAsync executed the setCount function, the count value was still 2 which is wrong. The new value should be 12 but it is 3.

In asynchronous situations like this, we should use a callback in our setState function to ensure the state value is updated.

So let’s fix the problem.

Bu adding the callback function in lines 7 and 12, we ensure the state value is updated.

As you can see we fixed the problem. So it’s crucial to use a callback when you update the state asynchronously.

That’s it for this week’s #SundayTechMusings is over :) See you next week.

Happy hacking! :)

If you find this content helpful and would like to show your support, you can buy me a beer🍺😊
Buy Beer🍺

CaglayanYanikoglu - Overview

My Twitter: https://twitter.com/caglayanDev
My Linkedin: https://www.linkedin.com/in/%C3%A7a%C4%9Flayan-yan%C4%B1ko%C4%9Flu-a6b42b13b/

Use the setState callback in React wisely was originally published in Jotform Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.