Forem: Andrey Smolko

Dynamic Fluent Interface for API calls (Powered by JS Proxy)

Andrey Smolko — Sun, 29 Jun 2025 11:49:17 +0000

When working with REST APIs, having a clean, expressive client can greatly simplify how you write code. Imagine calling your API like this:

const api = createApi('localhost');

api.users.get().then(console.log);
api.posts.post({ title: 'Hello' }).then(console.log);

This syntax is not only clean but reads almost like a natural language. The secret behind this elegant interface? It’s all about dynamic property access powered by JavaScript’s Proxy object.

Resources like users and posts are not predefined properties of the api object.
HTTP methods like get and post are also dynamically resolved.

This means you don’t have to write boilerplate code to explicitly declare every resource or method. Instead, these identifiers are resolved at runtime!

The core enabler is Proxy

A Proxy lets you intercept fundamental operations on objects, such as property access or function calls, and define custom behaviors.

Here’s the minimal implementation of createApi:

const createApi = (domain, path = '') => {
  return new Proxy(() => {}, {
    get(target, key) {
      return createApi(domain, `${path}/${key.toString()}`);
    },
    apply(target, thisArg, args) {
      const i = path.lastIndexOf('/');
      const method = path.slice(i + 1).toUpperCase();
      const url =
        domain + (i === -1 ? '/' : path.slice(0, i));

      const options = {
        method,
        headers: {
          'Content-Type': 'application/json',
        },
      };

      if (['POST', 'PUT', 'PATCH', 'DELETE'].includes(method) && args[0]) {
        options.body = JSON.stringify(args[0]);
      }

      return fetch(url, options).then((res) => {
        if (!res.ok) {
          throw new Error(`HTTP error! status: ${res.status}`);
        }
        return res.json();
      });
    },
  });
};

const api = createApi('localhost');

api.users.get().then(console.log);
api.posts.post({ title: 'Hello' }).then(console.log);

How It Works: `get` and `apply` traps explained

The `get` Trap — Capturing Property Access

Every time you access a property on the proxy — like api.users or api.posts — the get trap intercepts that access.
Instead of returning a fixed value, it calls createApi recursively, appending the accessed property name (users, posts, or HTTP methods like get, post, etc.) to the URL path argument.
This recursive design enables infinitely deep property chains without needing to define them explicitly upfront.
The recursion ends when the proxy is invoked as a function (via the apply trap), which triggers the actual HTTP request.

The `apply` Trap — Handling Function Calls

When you finally call the proxy as a function — api.users.get() —the apply trap intercepts the call.
It extracts the HTTP method from the last part of the path (like get, post, etc.), builds the full URL, and executes the HTTP request using fetch.

By combining the get trap for dynamic property access, the apply trap for function invocation, and recursion for building URL paths, this approach enables the creation of a powerful, flexible, and elegant API client.

Note: In JavaScript, a trap is a special method defined in a Proxy handler object. These traps intercept fundamental operations—like property access, function calls, or property assignments—allowing you to customize how those operations behave.

This post was inspired by the API design found in elysiajs/eden.

Merge array-like objects by Array.prototype.concat()

Andrey Smolko — Thu, 27 Jun 2024 14:49:26 +0000

Let's dive into the Array.prototype.concat() method in JavaScript. This handy method helps you merge arrays, creating a new array with elements from the arrays you provide. Here's a quick example:

const arr0= [], arr1 = [1,2], arr2 = [3,4];
const resultArray = arr0.concat(arr1, arr2);
// [1,2,3,4]

Now, let's switch things up and try to concatenate some array-like objects:

const arr0 = [];
const arr1 = {0:1, 1:2, length:2};
const arr2 = {0:3, 1:4, length:2};
const resultArray = arr0.concat(arr1, arr2);
// [{...}, {...}]

When you use array-like objects, Array.prototype.concat() doesn't flatten them like it does with arrays. Instead, it treats each array-like object as a single element.

So, is there a way to force Array.prototype.concat() to flatten array-like objects too? Sounds like a challenge for the JavaScript geeks! Let's figure it out together.

Array.prototype.concat() description from ECMAScript specification:

Let's pay attention to step5.a. There is a boolean variable spreadable which defines how Array.prototype.concat() treats its arguments. If spreadable is false (step 5.c) then an argument is added in resulting array as it is without been flatten. But if spreadable is true (step 5.b) then the argument can be flattened!

Function IsConcatSpreadable defines value of spreadable variable:

If O is not an Object, return false.

Let spreadable be ? Get(O, @@isConcatSpreadable).

If spreadable is not undefined, return ToBoolean(spreadable).

Return ? IsArray(O).

In step 2 - @@isConcatSpreadable is just a specification name of build-in Symbol Symbol.isConcatSpreadable.
The function IsConcatSpreadable returns true in 2 two cases: either the object is an array or it has the property with the name Symbol.isConcatSpreadable and the property value is not falsy.

This looks exactly like what we need! Let's add Symbol.isConcatSpreadable in array-liked objects we tried to concatenate:

const arr0 = [];
const arr1 = {0:1, 1:2, length:2, [Symbol.isConcatSpreadable]:true};
const arr2 = {0:3, 1:4, length:2, [Symbol.isConcatSpreadable]:true};
const resultArray = arr0.concat(arr1, arr2);
// [1,2,3,4]

Solved! Now Array.prototype.concat() flattens our array-like objects just like it does with regular arrays.

P.S. Symbol.isConcatSpreadable is used exclusively by the Array.prototype.concat() method. No other build-in methods uses it.

Fun with Array.prototype.fill()

Andrey Smolko — Tue, 25 Jun 2024 18:49:19 +0000

Recently, I came across the following code snippet:

const arr = new Array(2).fill([])
arr[0].push(1)
arr[0] === arr[1] // true or false?

The correct answer is true.
Both elements at indexes 0 and 1 contain the same mutable value - empty array which was passed as an argument the the method.
See the description from the ECMAScript specification:

Array.prototype.fill() expects in its first parameter an already defined value and then just set the same value as "number"-keyed property values (step 11b).

This definitely sounds like a challenge for JS geeks. Is it possible to use Array.prototype.fill() in such a way that each element in the resulting array has its own empty array?
Something like that:

const arr = new Array(2).fill([])
arr[0].push(1)
arr[0] === arr[1] // false
arr[0].length //1
arr[1].length //0

To achieve this, I’d use the insight provided by step 11b from the specification:

b. Perform ? Set(O, Pk, value, true).

That statement is straightforward: it sets the value (value) of a specific property key (Pk) of an object (O). JavaScript has a feature that can intercept and redefine fundamental operations for that object. It's called a Proxy!

Let's use a Proxy object and redefine an array set operation to solve our challenge:

const handler = {
    set(obj, prop, value) {
    //assign a new "instance" of empty array to the properties
    obj[prop] = [...value]    
    return true
  },
}
// Proxy cracks the challenge!
const arr = [...new Proxy(Array(2), handler).fill([])];
arr[0].push(1)
arr[0] === arr[1] // false
arr[0].length //1
arr[1].length //0

Solved!

How to protect a JS array against truncation

Andrey Smolko — Mon, 29 Aug 2022 10:51:00 +0000

Disclaimer: There are several options how to truncate an array in JS but here I would like to talk only about one of them.

If you want to truncate an array in JS there is a trick with the length property:

const numbers = [1, 2, 3, 4, 5];

if (numbers.length > 3) {
  numbers.length = 3;
}

console.log(numbers); // [1, 2, 3]
console.log(numbers.length); // 3

Sometimes I like to set a small theoretical JS problems for myself to keep fit.
So let's do a small exercise together and try to find a solution how to protect an array and disable its mutation by length property manipulation.

1st solution:

A length property of an array by default has following attributes:

enumerable === false
configurable === false
writable === true

When a property attribute configurable is false just a few changes to a property is allowed. One of them is to change attribute writable to false.
A combination of attributes configurable===false and writable === false makes impossible to delete or modify a property by any possible ways.

const numbers = [1, 2, 3, 4, 5];
Object.defineProperty(numbers,'length',{writable:false})

if (numbers.length > 3) {
  numbers.length = 3;
}

console.log(numbers); // [1, 2, 3, 4, 5]
console.log(numbers.length); // 5

Object.defineProperty(numbers,'length',{value:3})
// Uncaught TypeError: Cannot redefine property: length

The goal is achieved! An array mutation by property length is disabled.

2st solution (kind of exotic):

Let's check what ES specification says about array length manipulation :

For each own property key P of A that is an array index, whose numeric value is greater than or equal to newLen, in descending numeric index order, do:

To put it simply, a truncation of an array starts from a tail of an array (in descending numeric index order). In our first code snippet element 5 will be deleted first and then element 4.

Now it is time to remember that in JS an array is an object (exotic one but still an object) where an index is a key of a property and an element is a value of a property.
So when an array is truncated it means that array's properties whose keys greater or equal than a new length are deleted.

Let deleteSucceeded be ! A.[[Delete]](P).

Here A is an array, [[Delete]] is an abstract method to delete property from an object, P is a property key.

So let's combine together.
In our example with numbers array a property with key === 4 would de deleted first. But there is a way to prevent deletion of a property from an object - set attribute configurable to false!

Experiment:

const numbers = [1, 2, 3, 4, 5];
Object.defineProperty(numbers,'4',{configurable:false})

if (numbers.length > 3) {
  numbers.length = 3;
}

console.log(numbers); // [1, 2, 3, 4, 5]
console.log(numbers.length); // 5

The array is not mutated!
According the specification (see step 17) an array truncation due to length property reduction stops when a first unsuccessful property deletion is met.
So if we protect from deleting just last array element then we achieve our goal - prevent array mutation.

P.S. [[Delete]] abstract method which is used to defined array truncation is also used to define logic of delete operator. So when you reduce length of an array you literally delete properties from it. As a side effect, pop() method also will be disabled for such array.

P.S.S. I have never used that in my work and hope never will=) But I enjoy feeling that I understand a little bit how internal gears of JS are designed.

Strive for a minimum required state in a React component

Andrey Smolko — Sat, 27 Aug 2022 12:51:00 +0000

Keep a component state as minimal as possible and avoid unnecessary state synchronization .

🚫 Before refactoring - b is a redundant state which should be sync:

export default function App() {
  const [a, setA] = useState(1);
  const [b, setB] = useState(1);

  function updateA(x) {
    setA(x);
  };

  function updateB() {
    setB(1 + a);
  };

  useEffect(() => {
    updateB()
  },[a])


  return (
    <div>
      <button onClick={() => updateA(a+1)}>Click</button>
        <p>a: {a}</p>
        <p>b: {b}</p>
    </div>
)
};

✅ After refactoring - a is a minimum sufficient state and just derive b from it:

export default function App() {
  const [a, setA] = useState(1);

  function updateA(x) {
    setA(x);
  };

  function updateB() {
    return a+1
  };

  return (
    <div>
      <button onClick={() => updateA(a+1)}>Click</button>
      <p>a: {a}</p>
      <p>b: {updateB()}</p>
    </div>
  )
};

Does JS function's 'this' have a default value?

Andrey Smolko — Tue, 09 Aug 2022 09:11:00 +0000

Disclaimer

There are 1000000 articles about this in JS. I think it is perfectly fine to add one more.

Second parameter of Array.prototype.map

Recently I have checked the MDN page about .map() method of the array prototype and met one paragraph witch hooked my attention:

where thisArg is a second parameter of .map() method (1)

The second sentence says - "Otherwise, the value undefined will be used as its this value." So, let's do a quick test and pass inside .map() only a callback:

[1,2,3].map(function(){console.log(this)})
// globalObject
// globalObject
// globalObject

It seems confusing as this value is a global object and not undefined when a callback is executing. Actually it is expected as the callback is executed in non-strict mode. Why then the phrase says undefined?

Nevertheless, the phrase makes sense, especially, if we pay attention to the line - "The this value ultimately observable by callbackFn".

So, what "ultimately observable" does mean?

Default value of function's this

Let's create a simplest function ever and try to call it by .apply() method. The .apply() method allows us to set this value explicitly and let's set this as undefined

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

f.apply(undefined)
// globalObject

So, it is possible to conclude that function f ultimately observes globalObject value in this and not undefined value we explicitly pass. In my opinion we may compare such behaviour with default function parameters:

function f(a=globalObject){
    console.log(a)
}

f();

Spec time!

Now it is time to open the ES specification just to be sure that we do not miss any cases.

I really would like to make your life easier, so there is an abstract operation OrdinaryCallBindThis which is responsible for default this value. There are several steps but 2 of them are main:

Let's pay attention to 2 variables on the pic:

thisArgument - is a passed value in a function;
thisValue - is an ultimately observable value by a function;

Step 5 says that if our function is called in strict mode then thisValue becomes thisArgument and default value for this is not applicable.

function f (){
   'use strict'
   console.log(this)
}

f.apply(undefined)
// undefined

Step 6 says that if our function is called in non-strict mode and thisArgument equals to undefined or null then thisValue (actual value of this inside function) is globalObject (globalEnv.[[GlobalThisValue]] on the pic is just a global object).

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

f.apply(undefined)
f.apply(null)
// globalObject
// globalObject

So null value is also substitute with globalObject default value.

Also it is worth to have a look at 6.b which is also valid for non-strict mode. There is call of toObject() operation which creates wrapper objects (String, Number, etc) for primitive values of thisArgument:

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

f.apply('')
// String {''}

Therefore function's this value is always an object type for non-strict mode.

Conclusion

Each time you call a function in JS you pass a this value in it. Even if you call a function like f(); you still implicitly pass undefined value. A strict mode function accepts any this value without any modifications. A non-strict function substitutes undefined and null values with global object and also transform all primitive values in objects.

Feel free to use that conclusion to win a heart of your next interviewer.

P.S.
There is one my old post about this value in a setTimeout callback. In a browser callback's this is always window and it does not depend on strict/non-strict mode. The reason is that setTimeout method passes window object not undefined as this when executes a callback. Non-strict default substitution just does not work as thisArgument is neither undefined nor null.

(1) - Array.prototype.map() method has a second optional parameter:

// Callback function
map(callbackFn)
map(callbackFn, thisArg)

that second parameter may be used instead of .bind() method for a callback function.

Wrap a JS function transparently

Andrey Smolko — Tue, 02 Aug 2022 12:51:00 +0000

A wrapper function (aka a high order function) is a great way to augment a behavior of your other functions while still maintaining a separation of those concerns.

That pattern is widespread in JS/TS world and I consider myself a rather experiences user of it. However, sometime ago I came across a code snippet which demonstrated me that one detail is missed in my self-written wrapper functions.

The code snippet:

function bindActionCreator<A extends AnyAction = AnyAction>(
  actionCreator: ActionCreator<A>,
  dispatch: Dispatch
) {
  return function (this: any, ...args: any[]) {
    return dispatch(actionCreator.apply(this, args))
  }
}

This wrapper function is from Redux library but we may analyze it out of the library context.

So bindActionCreator takes 2 functions as arguments and returns a function which contains a composition of 2 input functions in the body. This is a good example of a utility wrapper function. But there is one place that hooked my attention. Honestly, if I need to create a similar function I would write just actionCreator(args) without apply(...) method call. So, let's find out why the function call via apply method is used in the code snippet.

Let's consider a simple function:

function f(name, email){
   return {name, email, this:this}
}

There is just one thing to pay attention, the function f returns object which keeps this value of the function call.

Let's write a simple wrapper function which actually does not add any logic but just returns a new function which contains function f call inside:

function wrap(f) {
    return function (...args){
      return f(...args)
    };
}

Now let's use the wrapper function:

const wrappedF = wrap(f);
f(1,1) // {name: 1, email: 2, this: Window}
wrappedF(1,1) // {name: 1, email: 2, this: Window}

It seems that both calls are equivalent or transparent.

But, let's call the functions like that:

f.apply({a:1}, [1,1]) // {name: 1, email: 2, this: {a:1}}
wrappedF.apply({a:1}, [1,1]) // {name: 1, email: 2, this: Window}

Now results of the calls are not equivalent. Returned objects have different values for this key.

Our wrapper function creates a distortion due to dynamic nature of this object (1). This object only depends on how a function is called and can not be accessed or found via a scope chain. So wrappedF and f functions have the same input arguments but different this objects.

Our initial function wrap can not transfer own this value (which e.g. we can set explicitly via apply method) inside function f. But there is a very simple way to modernize initial wrapper function:

function wrap(f) {
    return function (...args){
      return f.apply(this, args)
    };
}
const wrappedF = wrap(f)
f.apply({a:1}, [1,1]) // {name: 1, email: 2, this: {a:1}}
wrappedF.apply({a:1}, [1,1]) // {name: 1, email: 2, this: {a:1}}

Now our function wrap is transparent. It explicitly passes own this value in function f. Arguments and this are equivalent for the original and the wrapped version.

(1) - dynamic nature of this is true only for non-arrow functions. An arrow function does not have own this value but gets it from a closure (static nature). In case if function f is defined as an arrow function, this value of such function is defined in moment of a creation and already does not depend on how function f is called.

P.S
In my practice I have never met a case where I really need to have a transparent wrapped function, but still it is useful to keep in mind that this can reach and punish you in any time=)
Bless static scope!

The hidden scope of a named function expression

Andrey Smolko — Tue, 25 Jan 2022 12:49:39 +0000

There are several syntaxes to create a function in JavaScript. One of them is called function expression:

const f = function() {}

It is also possible to add a name inside function expression and such syntax is well known as named function expression:

const f = function internal(){}

If a function is created like that then variable internal is available inside the function scope and is not available in the global scope:

const f = function internal(){
console.log(internal)
}
f(); // f internal(){...}
internal; // Reference error internal is not defined

Ok cool, it is basic and looks pretty straightforward. But...

Where exactly is variable internal defined?

First idea - function scope

Let's say that variable internal is defined in the function scope. It is a decent guess as we have just checked that the variable is accessible only inside the function scope and is not accessible in the global one. But what if we create a constant and name it internal inside the function body:

const f = function internal(){
const internal = 100;
console.log(internal)
}
f();
// 100 in console

The code does not throw any errors and it seems that we have just created a constant with the name internal in the scope which already had variable internal (from function name) successfully. But the issue is that JS does not allow to use const statement with an identifier which has already been used in var/let/const statement earlier in the code. So there are two ways to avoid that issue.

The first way is to assume that there is a special mechanism inside a function scope which controls creation and access to a variable instantiated from a function expression name (false).
The second - to use something elegant and already existing (true).

Second idea - intermediate scope

Actually there is only one way to get full and detailed information about JS internals. It is the ECMAScript Language Specification. Definitely it is not an easy reading and it requires some experience, but believe me, it is worth investing your time in it.

But before checking a description of a named function expression in the spec let's refresh one famous JS term - closure (yeap, again)

So closure is a function with a scope where the function is created. Actually every function in JS is a closure.

const b = 20
const f = function (){
const a = 10;
a;
b;
}
f()

When function f is created it "learns" the surrounding scope. When function f is called a local function scope is created and then chained to the outer scope the function remembered during its creation:

A variable identifier resolution starts from a local function scope (const a). If a variable is not found in the local scope (const b), the resolution is delegated to the outer scope (global scope in the example). That is how the scopes are chained to each other. Cool, easy!

Let's jump back to a named function expression. There is a section describing creation of a named function expression.

There are key steps:

FunctionExpression : function BindingIdentifier ( FormalParameters ) { FunctionBody }

2. Set name to StringValue of BindingIdentifier.
3. Let outerEnv be the running execution context's LexicalEnvironment.
4. Let funcEnv be NewDeclarativeEnvironment(outerEnv).
5. Perform funcEnv.CreateImmutableBinding(name, false).

8. Let closure be OrdinaryFunctionCreate(...).

11. Perform funcEnv.InitializeBinding(name, closure).
12. Return closure.

The main idea is to create an additional intermediate scope in a closure for keeping only one variable with a function name!

The following code example:

const b = 20
const f = function internal(){
const a = 10;
a;
internal;
b;
}
f()

may be presented like that:

So this is an answer to our initial question: "Where exactly is variable internal defined?"

The variable internal is not available in the global scope and at the same time it does not block creation of a variable with the same name inside a function scope because the internal lives in its own scope between the global and the function scope. Win-win!

Final part

Ok, now we know that variable internal has its own scope but is it constant or variable? May we reassign a different value to it? Let's try something like that:

const f = function internal(){
internal = 100;
console.log(internal)
}
f()

The identifier internal still contains a function and there are no errors. This is actually interesting and I admit that such a logic is quite unique.

According the spec, variable internal in our example is created via CreateImmutableBinding abstract method.

That method is used to create constants but also has a boolean flag as a second argument. If that flag is false then a different value cannot be assigned to the identifier. However, such an assignment does not throw an error. In case of a constant statement that flag is true and a reassignment throws TypeError.

Function with duplicate parameters. Your turn, JS!

Andrey Smolko — Tue, 18 Aug 2020 14:09:59 +0000

Assertion: We are in parallel universe where all weird code snippets may exist and be used.

Let's imagine the simplest function declaration with 2 parameters... but both parameters have the same name:

function f(a,a){
  console.log(a)
}

What reaction would you expect from JS?

Probably there are 2 options:
1) throw some error (we are lucky if it's not runtime error);
2) create valid function f

Of course we may just run the code and check but it is too simple.
Instead, I propose to find the origin of truth and open ES specification 📕📗📘

Inside the ES spec

As in the snippet we try to create a function, so go to Function Definitions section in the spec. Inside we may find the following:

FunctionDeclaration : function BindingIdentifier ( FormalParameters ) { FunctionBody }
FunctionExpression : function BindingIdentifieropt ( FormalParameters ) { FunctionBody }

If the source code matching this production is strict code, the Early Error rules for StrictFormalParameters : FormalParameters are applied.

It means if you try to create a function as function declaration or function expression in "strict mode" some additional Early Error(errors on code parsing stage) rule is applied:

StrictFormalParameters : FormalParameters

It is a Syntax Error if BoundNames of FormalParameters contains any duplicate elements.

In that context BoundNames are just parameter names.

So the spec says that if you try to create a function as function declaration or function expression in "strict mode" and use the same name for function parameters then JS returns Syntax Error!

function f(a,a){
  'use strict'
  console.log(a)
}

Just copy and paste the above snippet in your browser console and check the error:

Uncaught SyntaxError: Duplicate parameter name not allowed in this context

Rather obviously, right?

Ok cool, but what about `non-strict mode`?

In non-strict mode mentioned Early Error rules is not applied to the function declaration or function expression and JS just creates a valid function which you may call later without any errors:

function f(a,a){
  console.log(a)
}

f(0,100)
// 100 in console

JS freedom is one love!

Ok cool, but what about arrow function definition?

Let's check the arrow function parameters syntax in the spec:

ArrowFormalParameters :
( StrictFormalParameters )

It means that duplicate parameters Early Error rule is always applied to arrow function definition even if 'strict mode' is not defined explicitly.

Instead of conclusion:

Function declaration and function expression with duplicate parameters in 'strict mode' throw Syntax Error;
Function declaration and function expression with duplicate parameters in 'non-strict mode' create a valid function;
Arrow function definition with duplicate parameters always throws Syntax Error;
Keep calm and read specs :) 📕📗📘

P.S

The ES6 spec contains Annex C - list of the strict mode restriction and exceptions. There is a point about our topic in that list as well.

How does setTimeout invoke a callback function in a browser?

Andrey Smolko — Sun, 03 May 2020 11:36:54 +0000

Assertion: JavaScript is executed in a browser (but not in a web worker).

Everyone in JavaScript world knows the window.setTimeout method, but let’s do a quick refresh.

One of the valid variants for this method has the following syntax (further in the text I will omit object window. part and leave only setTimeout):

setTimeout(function[, delay, param1, param2, …])

The method contains one required parameter which should be a function also known as callback.

Also, there are several optional parameters (inside [] bracket in above code snippet). First optional parameter is a delay in ms after which time callback will be invoked. Second and subsequent optional parameters will be passed as arguments in the callback function.

Example:

const add = function(a,b){
  console.log(a+b)
};

setTimeout(add,1000,1,2);

// 3 (in a second)

Simple! But what about infamous this keyword?

As we know this inside non-arrow functions is defined dynamically (this depends on how we call a function). But in the example above we do not invoke callback function ourselves. Here I mean that we do not type add() (function name add with parenthesis ()). Instead we pass the function add as an argument to setTimeout and then setTimeout calls it. Actually from our code we do not know how setTimeout invokes the callback because we do not create setTimeout. It is predefined by a platform (in our case it is a browser).

Let’s first have a look at another example:

const add = function(a,b){
  console.log(a+b,this)
};

const hoc = function(f,a,b){
  f(a,b)
};

hoc(add,1,2);

// 3,window (in non-strict mode)
// 3,undefined (in strict mode)

In this example, function add is a callback function which is passed as an argument to hoc function. But now we create function hoc and write invocation of callback inside hoc ourselves (we type parenthesis ()). So everything works as we expect. Function add is called as a ‘normal’ function and this is defined as either window in non-strict mode or as undefined in strict mode.

Let’s go back to setTimeout. May we say that setTimeout invokes a callback function and set this in the same manner as we have just seen? “Yes” will be a wrong answer.

It feels like a perfect time to have a look inside a specification 📕

setTimeout method is NOT part of JS spec (ECMA-262) but a part of HTML5 spec and it turns out that the method has it’s own rule to invoke a passed callback.

The rule looks like that:

Invoke the Function. Use the third and subsequent method arguments (if any) as the arguments for invoking the Function. Use method context proxy as the callback this value.

Sounds professional, but what is method context proxy? No worries, in a browser (but not on a worker) method context proxy is just the window object.

Thus after a delay a setTimeout callback is invoked with explicitly given this value. It is a acceptable to think that the callback is invoked like that:

function setTimeout(callback, delay, param3, param4, ...){
  // timer is count up passed delay and then
  callback.call(window, param3, param4, ...)
}

It may be concluded that setTimeout does not consider the mode (strict or non-strict) our code is run in but sets this as window during callback invocation.

Example (super strict mode):

'use strict'

const add = function(a,b){ 
  'use strict'
  console.log(a+b, this)
};

setTimeout(add,1000,1,2);

// 3, window (in a second)

Instead of conclusion:

setTimeout is not part of JavaScript spec and is defined by a platform;
setTimeout does not consider the mode type (strict or non-strict). It invokes non-arrow function callback and sets this to the window object in a browser (but not in a web worker);
setInterval has the same rule for this in callback;
In case a callback is an arrow function or a bound function, this is defined as expected — in a static way;
Keep calm and read specs :) 📕📗📘

Forem: Andrey Smolko

Dynamic Fluent Interface for API calls (Powered by JS Proxy)

The core enabler is Proxy

How It Works: get and apply traps explained

The get Trap — Capturing Property Access

The apply Trap — Handling Function Calls

Merge array-like objects by Array.prototype.concat()

Fun with Array.prototype.fill()

How to protect a JS array against truncation

Strive for a minimum required state in a React component

Does JS function's 'this' have a default value?

Disclaimer

Second parameter of Array.prototype.map

Default value of function's this

Spec time!

Conclusion

Wrap a JS function transparently

The hidden scope of a named function expression

First idea - function scope

Second idea - intermediate scope

Final part

Function with duplicate parameters. Your turn, JS!

Inside the ES spec

Ok cool, but what about non-strict mode?

Ok cool, but what about arrow function definition?

Instead of conclusion:

P.S

How does setTimeout invoke a callback function in a browser?

Instead of conclusion:

How It Works: `get` and `apply` traps explained

The `get` Trap — Capturing Property Access

The `apply` Trap — Handling Function Calls

Ok cool, but what about `non-strict mode`?