DEV Community: Sage

Mastering JavaScript Proxy and Reflect API (Without the Headache)

Sage — Sat, 21 Sep 2024 13:32:34 +0000

Introduction
What’s the Deal with JavaScript Proxy?
- Real-life Example: Tracking Object Changes (The Simple Way)
When You’d Want to Use a Proxy
- Data Validation Done Right
- Building Reactive Objects (Yeah, Vue Does This)
- Lazy Objects: Only Create What You Need
Okay, But What About Reflect
How Proxy and Reflect are the Perfect Duo
- Real-life Example: Logging with Style
Why You’ll Love Proxy & Reflect
Wrapping It Up

Introduction 👋

Let’s talk about two of probably the most underrated (and underused) features of JavaScript: Proxy and Reflect. I get it — you’ve probably heard of them, maybe even Googled them once or twice, but they seem a little extra, right?

But here’s the thing: these tools can unlock a whole new level of control over your objects, and they’re not as hard to use as you might think. By the end of this post, you’ll know exactly how they work, why they’re awesome, and how to add them to your toolbox for practical, real-world scenarios.

Let’s dive in!

What’s the Deal with JavaScript Proxy?

A Proxy in JavaScript is like the ultimate middleman. It lets you intercept and customize how you interact with objects. You can control what happens when someone tries to access, modify, or delete a property. And the best part? It’s super easy to use.

Think of it this way: you’ve got an object — say, a user profile — and you want to make sure anyone messing with that object doesn’t do anything weird (like setting their age to “gibberish”). With a Proxy, you can jump in and take control.

Here’s the basic syntax:

let proxy = new Proxy(target, handler);

target: The original object (the one we’re wrapping).
handler: An object with functions (called traps) that intercept operations like reading, writing, or deleting properties.

Real-life Example: Tracking Object Changes (The Simple Way)

Let’s say you’re building a collaborative editing app, and you want to know every time someone updates the document. Easy enough with a Proxy:

const documentModel = { title: "Draft", content: "Hello World" };

const handler = {
  set(target, prop, value) {
    console.log(`Property ${prop} is changing from ${target[prop]} to ${value}`);
    target[prop] = value;
    return true;
  }
};

const documentProxy = new Proxy(documentModel, handler);

documentProxy.title = "Final Draft"; // Logs: Property title is changing from Draft to Final Draft

Every time the document changes, you get a nice little log showing exactly what happened. No surprises here.

When You’d Want to Use a Proxy

So, when should you actually use a Proxy? Great question. Here are some scenarios where it really shines:

Data Validation Done Right

You can use Proxies to enforce data validation rules. No more invalid data sneaking into your app and causing headaches later.

const person = { name: "", age: 0 };

const handler = {
  set(target, prop, value) {
    if (prop === "age" && typeof value !== "number") {
      throw new TypeError("Age must be a number");
    }
    target[prop] = value;
    return true;
  }
};

const personProxy = new Proxy(person, handler);
personProxy.age = 30; // All good
personProxy.age = "thirty"; // Throws an error

Now you’ve got some nice validation that can be extended, and you didn’t have to write a ton of boilerplate code. Nice!

Building Reactive Objects (Yeah, Vue Does This)

If you’ve ever worked with Vue, you’ve already seen Proxies in action. Vue uses Proxies to make data reactive, automatically updating the UI when data changes.

You can use a Proxy to watch objects for changes and react in real-time — perfect for building your own reactive systems or dashboards.

Lazy Objects: Only Create What You Need

You can use a Proxy to defer the creation of expensive objects until they’re actually needed. This is called lazy initialization. Instead of loading all your data up front, you only grab what’s required, when it’s required.

Okay, But What About Reflect?

The Reflect API is like Proxy’s best buddy. While Proxy lets you intercept operations, Reflect gives you tools to work with those operations in a more standardized way. It lets you handle object operations (like setting or getting properties) more cleanly and predictably.

Here’s how you can use Reflect to work with default object behaviors:

const user = { name: "Alice", age: 25 };

console.log(Reflect.get(user, "name")); // Alice
Reflect.set(user, "age", 30); // Sets age to 30

Why bother with Reflect? It makes code easier to read and more consistent. You can use it with Proxies to handle default behavior when you don’t want to do anything custom.

How Proxy and Reflect are the Perfect Duo

Let’s put Proxy and Reflect together. If you want to add some logging but still handle object operations normally, Reflect is your friend. Here’s an example where we log when properties are accessed or changed but delegate the actual work to Reflect:

const product = { name: "Laptop", price: 1000 };

const handler = {
  set(target, prop, value) {
    console.log(`Setting ${prop} to ${value}`);
    return Reflect.set(target, prop, value);
  },
  get(target, prop) {
    console.log(`Getting ${prop}`);
    return Reflect.get(target, prop);
  }
};

const productProxy = new Proxy(product, handler);
productProxy.price = 1200; // Logs: Setting price to 1200
console.log(productProxy.price); // Logs: Getting price, Output: 1200

The best part? We can customize the behavior (logging), but Reflect handles the actual logic of setting and getting properties. This keeps things simple and predictable.

Why You’ll Love Proxy & Reflect

Here’s why these tools are awesome:

Flexibility: You can control how objects behave, whether you’re adding validation, logging, or lazy loading.
Powerful Abstractions: With Proxies, you can hide complex logic and make it feel like magic. Combine that with Reflect, and you’ve got control and safety.
Cleaner Code: Instead of hacking around edge cases or writing tons of conditionals, Proxies allow you to intercept behavior in a clean and reusable way.
Better DX (Developer Experience): Less boilerplate, fewer surprises, more control. What’s not to love?

Wrapping It Up

And there you have it! Proxies and Reflect may seem a little intimidating at first, but once you get the hang of them, they can dramatically improve your code. Whether you’re validating data, tracking object changes, or just wanting more control over how objects behave, these tools are here to make your life easier.

So go ahead, give them a try! You might just find yourself reaching for Proxy and Reflect in your next project.

How to deploy a nestjs back-end from a mono repo on fly.io

Sage — Sun, 28 Apr 2024 12:41:44 +0000

I recently had to deploy an API backend from a monorepo on fly.io and this is a documentation of the steps.
The project uses turborepo with npm managed workspace. The monorepo had the below structure

Fly.io has a generous free tier that is perfect for small projects like MVPs. New users get a $5 credit which gives up to 3 shared-cpu-1x 256mb VMs and 3GB persistent volume storage. This served my purposes especially during development. Let's dive in.

Step 1: Create an Account on fly.io & Install Fly CLI

To begin visit fly.io to create an account. Next install flyctl a command line tool for creating and deploying fly apps.
macOS



brew install flyctl

Windows



pwsh -Command "iwr https://fly.io/install.ps1 -useb | iex"

You may have to run the command on windows with powershell instead of pwsh if you run into errors. Full instructions can be found here. After installation authenticate the CLI using:



fly auth login

Step 2: Create A Dockerfile

Flyctl automatically detects a Dockerfile in the app root directory, it builds an image from it and deploys containers from the image.
Create a Dockerfile in the nestjs app's root directory and paste in the following content.



# Line 1
FROM node:20-alpine as builder
# Line 2
ENV NODE_ENV build
# Line 3
WORKDIR /api
# Line 4
COPY package*.json ./
# Line 5
RUN npm install
# Line 6
COPY . .
# Line 7
RUN npm run build \
    && npm prune --production

# Line 8
FROM node:20-alpine
# Line 9
ENV NODE_ENV production
# Line 10
WORKDIR /api
# Line 11
COPY --from=builder  /api/package*.json ./
COPY --from=builder  /api/node_modules/ ./node_modules/
COPY --from=builder  /api/dist/ ./dist/
# Line 12
CMD ["node", "dist/src/main.js"]

This dockerfile uses a multi stage build, which is a docker build process that lets you build an image in multiple stages. Each build stage has output(files) from which one can copy only what is needed to the next build stage. This removes unnecessary files like development dependencies from the final output which helps to reduce the overall size of the resulting image.

In the builder stage(Line 1), from Lines 4-7, we copy package.json file to the image, run the install script, copy over the generated files and build the nest app.

In the next stage of the build (beginning on line 8), in Line 11 we copy package.json and lock files, node modules folder and dist folder(output of 'npm run build') to the image and on line 12 we finally specify the start command.

Step 3: Create & Configure a fly app

We need to create and configure a fly app from our nestjs application. Run the command below from your nestjs app root directory to create, configure, and (for most apps) deploy a new fly application. In my case the root was monorepo_root/apps/api.



fly launch

This command generates a fly.toml file with default configuration that can be edited using a web interface.

Note: Fly expects the app to listen on port 8080 by default, so tweak the default configuration when prompted to do so and set the listening port to 8080.

Note: Also change the nest app to listen on the same port(8080) from main.ts/js as shown below

Step 4: Deploying the app

To deploy the app run the command below (from the root of your nest app).



fly deploy

This command detects our dockerfile, builds an image and deploys a container from it. If the build is successful, a url will be generated for you to access the app.

Step 5: Setting environment variables

To set runtime environment variables, use fly secrets set KEY=VALUE syntax to set sensitive variables that should not be included in the built docker image.
Example:

You can also import bulk values from your .env file by doing:
fly secrets import < .env

This then updates each Machine belonging to that Fly App with the new environment variables. This involves a restart of the Machine(s).

Congratulations🎊

How to secure your smart contracts: Reentrancy attacks

Sage — Tue, 18 Jan 2022 13:59:52 +0000

It is important to have security at the back of your mind when programming smart contracts, when you consider that money could be at stake.
Multiple exchanges, DAO's have been hacked and millions of dollars in crypto assets stolen due to vulnerabilities in smart contracts.

To better understand this attack, lets explore what "Reentrancy" is as well as fallback functions in solidity.

Reentrancy is a concept in programming that allows for example a function execution to be interrupted and then re-executed before the previous execution cycle is completed such that you have multiple concurrent executions of the same function. Reentrancy in itself is not a vulnerability, the attack lies in the way this feature is exploited in solidity.

Fallback functions in solidity are functions that are executed when a call is made to the contract and no other function in the contract can handle this call because the signature doesn't match , an example is plain ether transfer to a contract. When the ether is sent to the contract, the fallback function of the contract(if any is specified) will be called if there is no receive ether function. More info here.
So this attack is based on the fact that by making a call to an external contract(such as when transferring ether) we can trigger unsolicited and untrusted code in that external contract(it's fallback function). Let us review a practical example.

Vulnerable contract

 contract VulnerableBank {
    mapping (address => uint) private userBalances;

    function deposit() external payable {
        userBalances[msg.sender] += msg.value;
    }

    function withdrawBalance() public {
        require(amountToWithdraw <= userBalances[msg.sender]);
        uint amountToWithdraw = userBalances[msg.sender];
        // At this point the fallback of the external contract is 
        // called. It can also re-enter this contract and call 
        // withdrawBalance function again        
        payable(msg.sender).call{value: amountToWithdraw}("");
        // Updating user's balance
        userBalances[msg.sender] = 0;
    }

    function getBalance() public view returns(uint) {
        return address(this).balance;
    }

    function getUserBalance(address _user) public view returns(uint) {
        return userBalances[_user];
    }
}

The snippet above represents a vulnerable bank contract, that accepts deposits and withdrawals. Notice that the user's balance isn't updated till after the transfer. Let's exploit it..

contract Attacker {
    VulnerableBank _bank;

    constructor (address payable _vulnerableContractAddress) {
        _bank = VulnerableBank(_vulnerableContractAddress);
    }
    // Fallback function called when ether is transferred to this contract
    fallback() external payable {
        // When this contract receives ether, since there is no receive ether function this function is called
        // Here we can re-enter the calling contract's withdraw function again
        // before previous withdrawal was complete.
        _bank.withdrawBalance();
    }

    function deposit() public payable {
        _bank.deposit{value: msg.value}();
    }


    function robTheBank() public {
        // Make a deposit to ensure we have a balance
        this.deposit();
        // Initiate a withdrawal
        _bank.withdrawBalance();
    }

    function getBalance() public view returns(uint) {
        return address(this).balance;
    }


}

How have we exploited it? Let's find out.

The withdraw function of the vulnerable contract is called(attacker should have some balance in the vulnerable contract) & the address is checked to ensure it has some balance.
A transfer is made to the attacker's contract and the contract's(attacker) fallback function is executed.
In The fallback function we re-enter the withdraw function of the vulnerable contract while the previous call is not completed and another transfer is made.
This loop continues till the contract's treasury is empty of funds.

On June 17th 2016, The DAO was hacked and 3.6 million Ether ($50 Million) were stolen using this reentrancy attack.

Preventing Re-Entrancy Attacks.

One method of guarding against this attack is using the Checks-Effects-Interaction pattern. This means you should:

First make any required checks(checking who called the function, are the arguments in range, did they send enough Ether, does the person have tokens, etc.).
Next after necessary checks have all passed, make effects/changes to state variables(such as updating user balance etc,).
Finally make any interactions to external contracts, note that external contracts may also call other external contracts.

Another way to prevent this attack is to use reentrancy guards from libraries like OpenZeppelin. It provides function modifiers like nonReentrant that prevents a contract from calling itself, directly or indirectly.

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

// ...Other code here
    function withdrawBalance() public nonReentrant{
        // Make necessary Checks
        require(amountToWithdraw <= userBalances[msg.sender]);
        uint amountToWithdraw = userBalances[msg.sender];
        // Perform any changes/effects to state
        userBalances[msg.sender] = 0;
        // Make interaction with external contract        
        payable(msg.sender).call{value: amountToWithdraw}("");
     }

It is very important to follow best practices when programming smart contracts t prevent avoidable financial losses.

How to understand visibility in Solidity.

Sage — Sat, 01 Jan 2022 12:28:07 +0000

In solidity, visibility specifies how a function or state variable in a contract can be accessed by other contracts & external accounts.
There are four(4) levels of visibility in solidity, and they are - private, public, internal, external.

When writing solidity you specify the visibility after the type for state variables(or global variables) and between the function parameters and return types.

address public holder; // type - visibility - varaiableName
function getBalance() private view returns(uint)//parameters - visibillity-returns

PRIVATE

Variables and functions declared as private can only be accessed inside the contract in which they are created. This means that they cannot be accessed from other contracts including sub-contracts.

contract _Account {
    address _holder;

    constructor() payable {
        _holder = msg.sender;
    }

    function getHolder() private view returns (address) {
        return _holder;
    }
}

contract _Checking is _Account {
    function testGetHolder() public view returns (address) {
    return getHolder(); // DeclarationError: Undeclared identifier
}

When we try to access the private function "getHolder" from a child contract we get an error. It can only be accessed in the contract where it was created.

PUBLIC

When a function is declared as public in a contract, this means it can be accessed from within the contract, by contracts that inherit from it and by external accounts.

contract _Account {
    // Function is declared as public
    function checkBalance() public view returns (uint) {
        return address(this).balance;
    }
}

contract _Checking is _Account {
    function testCheckBalance() public view returns (address) {
        return checkBalance(); // We can access it from child contracts.
    }        
}

In this case the function is public so we can call this function from within child contracts, or external accounts.

INTERNAL

Internal visibility means the variable or function declared as internal can be accessed from within the contract and sub contracts only.

contract _Account {
    // Function is declared as internal
    function checkBalance() internal view returns (uint) {
        return address(this).balance;
    }
}

contract _Checking is _Account {
    function testCheckBalance() public view returns (uint) {
        return checkContractBalance(); // We can access it from a child contract!
    }
}

contract TestInternal {
    _Account newAccount = new _Account();
  function testcheckContractBalance() public view returns (uint) {
    return newAccount.checkContractBalance();// TypeError: Member "checkContractBalance" not found or not visible...
  }    
}

It is possible to access functions declared as internal from within the contract they are declared and from sub-contracts but we can't access them from external contracts. Internal visibility is the default visibility for state variables.

EXTERNAL

Functions declared as external are still a part of the contract but they cannot be called from within the contract without using this keyword. They however can be called from external accounts and contracts. State variables cannot be declared as external, it won't compile.

contract _Account {   
    constructor() payable {}

    function checkContractBalance() external view returns (uint) {
        return address(this).balance;
    }
    function testcheckContractBalance() public view returns (uint) {
        uint contractBalance = this.checkContractBalance();// Using this keyword compiles without error!
        return checkContractBalance();// DeclarationError: Undeclared identifier
    }    
}

We are able to access the external function checkContractBalance from within the contract using this keyword, but we get an error when we remove it.

It is important to note that regardless of the visibility, functions and variables are actually visible to everyone who cares to look, so it is meant to visibility from other contracts and external accounts.

How to use .bind() in javascript.

Sage — Sun, 07 Jun 2020 10:13:42 +0000

This is one part of a two part series on how to use bind(), call() and apply() in your javascript code.

How and where you call a function in javascript matters a lot, yeah a lot. One reason being that it defines what the value of 'this' will be in that function's execution context.

Javascript gives us the ability to decide what 'this' would point to each time the function is executed. What this means is that we can tell the javascript engine what object we want the method(function) to be called on, each time it's executed. Cool right! Let's proceed.

You may have heard of bind, call or apply methods, have you? Well their primary purpose is to help you decide what you want 'this' to point to while executing a function. bind is a method on the Function object(Function.prototype.bind), and is available by default as a method on functions you create since functions have the Function object as their prototype.

bind(this, args)

Whenever bind is called, it returns a 'new function', this function has it's 'this' value set to the object you provided when bind was called. This means each time this new function will be executed, the 'this' in the execution context that will be created, would always point at the object you passed in when calling bind.


    const user = {
      name: 'sage',
      balance: 1000
    };

     const getBalance = () => this.balance;

     console.log(getBalance()); // undefined

Since the function was called in global scope, its 'this' pointed to the global object(Window object in web browsers). And balance was not defined as a property on the global object so it returned undefined.

Now let's bind the function's 'this' to a different object and see how it goes.

    const newGetBalance = getBalance.bind(user);

    console.log(newGetBalance()); // 1000

So what this means is that each time you call the new function we got from the bind call(newGetBalance), a new execution context will be created, and in that execution context, the value of 'this' would always be the user object that we provided. That's flexible if you ask me.

bind also accepts other parameters, in addition to the parameters the function accepts by default. These new parameters to the bind call will precede the original ones the function accepts.

Understanding 'this' in javascript.

Sage — Sat, 06 Jun 2020 22:58:03 +0000

To better understand 'this' keyword in javascript, we need to have a mental model of how code execution happens in javascript.
Each time javascript code is executed, an 'Execution Context' is created by default. This is known as Global Execution Context.

Each time a function is executing, a new execution context is created for that function, This can be called Function Execution Context.

Think of execution context as a box, some container, and inside of it is information about the code that is currently executing and the environment around it. Information like, what variables are declared inside this executing code, what is the value of 'this', what is the global object, what other code surround this executing function. Are you with me? Okay.

Part of a function's execution context is a reference to the value of 'this'. What this means is that every execution context has a value for 'this' and this value is set by the javascript engine by default depending on how the function was called(More on this later) and it may be different each time the function is executing. So we can say 'this' is a property of the execution context.

'this' always points to an object in non-strict mode, and points to undefined in strict mode. It points to the object that is in charge of the currently executing function, that is the object the function was called on.

a)
function greet() {
  console.log(this); 

}

greet(); // Window {...} in a browser

b)
const boy = {
  name: 'Sage',
  greet() {
    console.log(this); 
  }
};

boy.greet(); // { name: 'Sage', ...}

As you can see from the snippet above, In javascript how and where you call a function is more important than where it was defined, one reason is that it determines the value of 'this' in that execution context.

In a) 'this' points to the global object because it's not executed on an object and is executed in the global scope.

function greet() {
  console.log(this); 

}

greet(); // Window {...} in a browser

In b) Since 'greet' method was called on an object, it's 'this' defaults to the object it's called on.

const boy = {
  name: 'Sage',
  greet() {
    console.log(this); 
  }
};

boy.greet(); // { name: 'Sage', ...}

Any method called on an object automatically has its 'this' set to that object by default.

Functions not called on an object have their 'this'* set by default to the global object (Window object in the browser). This behavior is similar for arrow functions.

To set a 'this' value explicitly, use the

javascript .bind()

method. It creates a new function that has it's 'this' bound to the object passed to it.

Also see this, How to use bind in javascript.