Forem: Abdullah Al Numan

[Boost]

Abdullah Al Numan — Fri, 25 Jul 2025 00:04:56 +0000

Top Coding Agents: What's your take ?

Abdullah Al Numan ・ Jul 24

Variadic Currying in JavaScript

Abdullah Al Numan — Thu, 17 Jul 2025 14:00:48 +0000

Variadic Currying in JavaScript

This post is about variadic currying in JavaScript. It is the fifth part of the series titled Curry Functions in JavaScript.

In this post, we first look at the confusion around currying in JavaScript, especially with respect to polyadic partial application. We find out that we're not really doing currying in the real sense that it is implemented in Haskell, rather in a much limited capacity.

In the later part, we delve into variadic currying in a stricter sense with an example that returns unary accumulators.

Variadic Partial Application

In the previous article titled Auto-currying in JavaScript, we focused on the unarity of curried functions, because that's what a curried function ought to be.

We defined two versions of the curry() function. The first one maintains unarity of the accumulator function at every level of the recursive stack.

In the second definition of curry() though, with the spread ...args arguments, we are introducing polyadic partial application to the first call of the curried function:

function curry(f) {
  return function curried(...args) {
    if (args.length >= f.length) return f(...args);
    return accumulator;

    function accumulator(a) {
      return curried(...args, a);
    };
  };
};

This is a good starting point to deviate from actual currying. So, now we can take an arbitrary number of arguments for our first call to the curried function:

function createMessage(greeting, name, message) {
  return `${greeting}, ${name}! ${message}`;
};

const curriedCreateMessage = curry(createMessage);

// First accumulator is a variadic function
console.log(curriedCreateMessage('Hi')('Haskell')('Whadup?')); // Hi, Haskell! Whadup?
console.log(curriedCreateMessage('Hi', 'Haskell', 'Whadup?'));  // Hi, Haskell! Whadup?
console.log(curriedCreateMessage('Hi', 'Haskell', 'Whadup?', 'Say something', `Let's talk.`));
// Hi, Haskell! Whadup?

// Subsequent accumulators are unary
console.log(curriedCreateMessage('Hi')('Haskell', 'Whadup?', 'Say something', `Let's talk.`));
// [Function: accumulator]
console.log(curriedCreateMessage('Hi')('Haskell')('Whadup?', 'Say something', `Let's talk.`));
// Hi, Haskell! Whadup?

Notice, we have opened only the first accumulator to accept any number of arguments. Subsequent calls maintain unarity of the accumulator with accumulator(a) accepting only one argument.

We can deviate more and allow the accumulator to be polyadic with ...a:

function curry(f) {
  return function curried(...args) {
    if (args.length >= f.length) return f(...args);
    return accumulator;

    function accumulator(...a) {
      return curried(...args, ...a)
    };
  };
};

Doing so allows accumulator(...a) to be variadic at every level of the recursive stack. So, now we can take multiple arguments in the subsequent calls as well:

console.log(curriedCreateMessage('Hi')('Haskell', 'Whadup?', 'Say something', `Let's talk.`));
// Hi, Haskell! Whadup?
console.log(curriedCreateMessage('Hi', 'Haskell')('Whadup?', 'Say something', `Let's talk.`));
// Hi, Haskell! Whadup?

Notice, the additional arguments are gracefully ignored by JavaScript.

So basically, what we've done is allow the accumulator to take multiple arguments per call. It can be unary, as well as polyadic. We've lost the essence of currying.

But now our curry() function is much more powerful. We can pass any number of arguments to an accumulator, as long as that is returned. And it is common to implement this with native JavaScript Function.prototype methods.

Using `Function.prototype` Methods

We can re-write the curry() function with Function.prototype.apply, and with Function.prototype.bind:

// with Function.protoype.apply
function curry(f) {
  return function curried(...args) {
    if (args.length >= f.length) return f(...args);
    return accumulator;

    function accumulator(...a) {
      return curried.apply(this, [...args, ...a]);
    };
  };
};

// with Function.prototype.bind
function curryBound(f) {
  return function curried(...args) {
    if (args.length < f.length) return curried.bind(null, ...args);
    return f(...args);
  };
};

Refactoring curry() with Function.prototype.apply is not radically different in terms of the logic. We're just passing in the arguments args and a as part of an array instead of a list.

However, with Function.prototype.bind, we are returning a bound function that binds incoming arguments recursively to a copy of itself till we are able to receive all required arguments. So, inside curryBound(), the curried() function at a current execution context is a bound copy of the curried() function called one level below it in the recursive stack with the arguments passed there.

To be semantically more accurate, we should rename curryBound() to be partialize() and curried() to be bound():

function partialize(f) {
  return function bound(...args) {
    if (args.length < f.length) return bound.bind(null, ...args);
    return f(...args);
  };
};

This is because, Function.prototype.bind applied here allows a variadic and more powerful partial application than unary currying. Really, this is nothing more than native JavaScript partial application with context binding and recursion.

The Stunner
Ok, so what about invoking our original function, f(), when we have all arguments available ?

f(...args);

We're just calling a polyadic function with all its required arguments. Is it currying ? To me, with f(...args); we just embraced back what we wanted to avoid by accepting single arguments at a time. That is, we have not found a way around to call our original function, f(), with single arguments sequentially.

In Haskell, currying does not involve calling the multary function with all arguments passed in collectively. In JavaScript, we are eventually calling it with all arguments together - and with the possibility of accepting additional ones. We're fooling around.

What we're actually doing is, generating a series of variadic accumulators returned in sequence - with good intentions, inspired by currying to begin with. This is probably what currying should idiomatically mean in the sphere of JavaScript.

Variadic Currying with Termination

In a stricter sense, if we want to implement runtime currying transformation in JavaScript - at best - we can go as far as returning unary accumulators. Contrary to this, as we have seen above, variadic multary accumulators are also commonly returned.

However, we can go ahead and implement variadic currying by returning unary accumulators as well. This can be a case if our f() is variadic itself. Below, we have modified our createMessage() function to produce a message for a given arbitrary number of text strings.

function createMessage(...texts) {
  return texts.reduce((combinedText, currentText) => combinedText + currentText, '');
};

Terminator
Here, we want to curry createMessage() with unary accumulators. And we can keep receiving as many arguments we want, without stopping.

So, in order to produce a result from a curried variadic function, we have to decide on an arity for f() at some point. After we fix an arity of our desire for f() by passing in those arguments one at a time, we can terminate the accumulator.

The idea is to terminate the accumulator when we receive an empty (undefined) argument and invoke f() with the available arguments. So, the empty parens, () acts as the terminator in this case.

For a curried function, vCurriedCreateMessage(), returned from vCurry() by passing in createMessage(), let's say we want to terminate the accumulator after 5 arguments. And we want to invoke f() after that. It will look something like this:

const vCurriedCreateMessage = vCurry(createMessage);
const messageHaskell = vCurriedCreateMessage('Hi Haskell,')(`I hope you're doing good!`)(`We're discussing currying here. Do you wanna join in?`)('See you soon!')('Bye.');

messageHaskell();

The Plan

Implementing vCurry() follows a slightly different logic, mostly due to the fact that we have to terminate the accumulator on demand with an empty argument, i.e. having a value of undefined. And since sometimes a variadic function can potentially take infinite number of arguments, it can lead to infinite currying. We'll talk about infinite currying in an upcoming article, but for such cases f.length doesn't play an important role in the currying logic. Instead, length of the incoming arguments is the main point of focus.

If we have an incoming argument, we keep accumulating. When we receive none, we terminate and invoke f() with accumulated arguments:

function vCurry(f) {
  function curried(args) {
    return function accumulator(a) {
      if (args.length === 0 || a) return curried([...args, a]);
      return f(...args);
    };
  };

  return curried([]);
};

So, now currying createMessage() and invoking the curried function with 5 arguments and then invoking returned function with () (empty argument) will produce the message string:

const vCurriedCreateMessage = vCurry(createMessage);
const messageHaskellShorter = vCurriedCreateMessage('Hi Haskell,\n', `You can't see this.`)(`I hope you're doing good!\n`)(`We're discussing currying here. Do you wanna join in?`, 'Bye');
const messageHaskell = vCurriedCreateMessage('Hi Haskell,\n')(`I hope you're doing good!\n`)(`We're discussing currying here. Do you wanna join in?\n`)('See you soon!\n')('Bye.');
const messageHaskellLonger = messageHaskell('\nAbdullah Numan');


console.log(messageHaskellShorter()); // Additional arguments ignored: `You can't see this.`, 'Bye'
/*
Hi Haskell,
I hope you're doing good!
We're discussing currying here. Do you wanna join in?
*/

console.log(messageHaskell());
/*
Hi Haskell,
I hope you're doing good!
We're discussing currying here. Do you wanna join in?
See you soon!
Bye.
*/

console.log(messageHaskellLonger()); // Extended from messageHaskell()
/*
Hi Haskell,
I hope you're doing good!
We're discussing currying here. Do you wanna join in?
See you soon!
Bye.
Abdullah Numan
*/

Notice the messageHaskellLonger function. The curried function can be extended basing on that of a smaller arity to any arbitrary arity, before it gets terminated.

Notice also that since we focused on unary implementation of variadic currying, the accumulators ignore the second arguments passed.

Currying a variadic function is quite different from currying functions with fixed arity in terms of the logic, especially with respect to how termination is achieved by passing an empty argument. Without termination, it can take infinite number of arguments. In the next article, we'll see an example of infinitely curried function that does not require termination at all.

Summary

In this post, we found out that deviating from unary currying in JavaScript leads to variadic partial application, which turns out to be more powerful. We also saw how currying an existing variadic function follows a different logic than those with fixed arity with a unary implementation.

Strapi with Refine Part I: An Introduction to Refine's Strapi v4 Connector

Abdullah Al Numan — Fri, 26 Jan 2024 23:55:06 +0000

Introduction

Refine is a React based meta framework used to quickly build data intensive web applications. It comes with an extensible headless core and with the help of supplementary packages offers integrations with a myriad of frontend and backend technologies.

Refine supports integration with a Strapi CMS by means of a data provider package that facilitates communication with the Strapi endpoints. A data provider in Refine acts as a two-way adapter that gets installed on top of the headless core. Currently, Refine has data providers for Strapi version 4 REST API, as well as Strapi GraphQL APIs.

This post provides an introduction to integrating a Strapi backend API to a Refine frontend app with Refine's Strapi v4 adapter. It discusses in siginificant depth Refine's ecosystem of data hooks and components, and where they are posited in Refine's architecture. It also explains the use of Refine's collection of Ant Design supported data hooks and components in quickly building React based CRUD applications.

Overview

We begin with a discussion on Refine's React context and hooks based architecture, some underlying concepts and the libraries at play for performing and managing data heavy tasks in Refine. We aim to get a fair understanding of what a data provider in Refine is and where it fits in Refine's cascade of React contexts accessible via hooks.

In the later part of the post, we demonstrate how to initialize a Refine app named Strapi Refine Blog with Strapi v4 data connector. We examine in some depth the methods in Refine's Strapi v4 data provider object that enables CRUD operations on a Strapi backend API.

The backend API for Strapi Refine Blog is already created and hosted on the Strapi Cloud here. Towards the end, we show how to use its Strapi API credentials inside the Refine app in order to connect to its endpoints.

Refine Architecture

Refine's architecture lays different app concerns into cascades of React contexts which are passed their respective provider objects. It separates authentication, authorization, data fetching and state management, notification, real time pub/sub, audit logging and internationalization into distinct cascading layers.

Refine Has an Extensible Headless Core

Refine has a headless core. The core encapsulates the app's context layers which operate with the help of providers and hooks. Being headless, Refine's core offers surface for seamless integration with various backend API services and UI libraries.

Providers in Refine

A provider object in Refine contains methods that address the concerns on a particular layer. It acts as a bridge between the core and the API surface of the library it integrates with.

For instance, Refine accepts a data provider object with methods for connecting to and fetching data with a backend API service. Similarly, it has providers with methods for authentication, authorization, and other concerns of the app.

Refine Data Rrovider

Server side data fetching and associated tasks make up Refine's data layer. And a data provider object with methods for handling CRUD (create, read, update and delete actions) are passed to its context so that they can be accessed down the cascade from inside the app's pages and components. The data provider methods of a particular API service provider (for instance, Strapi REST) are defined tailored according to their own data fetching API surface.

The provider object is passed to its context via the <Refine /> component, which forms the core of a Refine app:

<Refine
    // ... other props
    dataProvider={dataProvider}
>

Refine Data Provider Shape

Refine needs a specific set of data provider methods for dealing with CRUD actions in the data layer. The dataProvider object should have the following methods:

import { DataProvider } from "@refinedev/core";

const dataProvider: DataProvider = {

  // required methods
  getList: ({ resource, pagination, sorters, filters, meta }) => Promise,
  create: ({ resource, variables, meta }) => Promise,
  update: ({ resource, id, variables, meta }) => Promise,
  deleteOne: ({ resource, id, variables, meta }) => Promise,
  getOne: ({ resource, id, meta }) => Promise,
  getApiUrl: () => "",

  // optional methods
  getMany?: ({ resource, ids, meta }) => Promise,
  createMany?: ({ resource, variables, meta }) => Promise,
  deleteMany?: ({ resource, ids, variables, meta }) => Promise,
  updateMany?: ({ resource, ids, variables, meta }) => Promise,
  custom?: ({ url, method, filters, sorters, payload, query, headers, meta }) => Promise,
};

As you can refer, it is mandatory to define the getOne, getList, create, update and deleteOne methods that are essential to CRUD applications. We are able to get the API url with the getApiUrl method.

The "many" versions are optional. And we are able to add a custom method in the case we need to handle things differently at some point.

Uncontrained Backend API Integration

Refine's headless architecture not only decouples the core from a UI design system and implementation, it also distances itself from strictly binding to certain data providers. This lets us pass any data provider of our choice that conforms to the above shape. For the demo app used in this post, we'll be passing the Strapi v4 data provider and as we'll elaborate in a later section, Strapi v4 is a REST API connector that lets a Refine app connect to Strapi REST endpoints.

Hooks in Refine

Provider methods for a layer in Refine are accessed from pages and components via a standard set of core hooks that correspond to these methods.

For example, the data provider object above -- identified as dataProvider -- has a create method that helps perform a create action on a resource hosted at an API endpoint. And dataProvider.create can be accessed from a component down the Refine cascade via the useCreate Refine core hook.

Core Hooks vs Higher Level Hooks

Refine's headless core comes with a set of core hooks for each layer. These core or low level hooks are decoupled from any particular UI library and can be extended with support for popular design systems and frameworks (e.g. Ant Design) with the help of adapter packages built by Refine and the community. Extension packages offer higher level hooks that integrate and are enhanced with the functionalities of UI components particular to the design system.

Refinedev Ant Design Support Package

For example, the useCreate() core data hook is used inside the useForm() high level hook by Refine's adapter for Ant Design in the Refinedev Ant Design package. The enhanced useForm() hook is tailored to be used with an Ant Design <Form /> component.

The Ant Design support package contains other high level data hooks for quickly building sophisticated components such as tables, lists, forms, data charts, etc. The full API reference can be found here.

Refine Under the Hood

Refine employs React Query in its data hooks to handle data fetching, caching, state management and error handling.

For forms, it relies on React Hook Form with its Refinedev React Hook Form adapter package to manage form logic and error handling. For rendering tables, it uses Tanstack React Table via the Refinedev React Table support package.

With this fair bit of understanding about how Refine works, we can now go about initializing a Refine app that will be geared to connect with a Strapi CMS.

Setting Up Strapi 4 Data Provider in a Refine App

In this section, we go through the steps for initializing a Refine app with Strapi v4 data provider. Refine lets us choose a data provider at project initialization. So, we are going to opt for Strapi 4 REST adapter from a range of other backend integration options.

Pre-requisites

Environment

Node.js and npm: You should have Node.js and npm installed in your system. We recommend Node versions > 18.

Knowledge

React with TypeScript: Refine is written in TypeScript and by default creates a React app with supported TS types. So, we assume you already have enough experience building React apps with TypeScript.
Strapi 4: We also assume you have a fair understanding and some experience building a Strapi 4 backend API.
Ant Design: This app uses Ant Design support for Refine. We expect you are familiar with Ant Design React ecosystem, particularly the components and layouts related to CRUD operations, such as <Form /> and buttons.

Initializing a Strapi Backed Frontend App with Refine

Let's now go ahead and create the Refine app. Follow the steps below:

Open a Terminal and run the npm create command for creating Refine apps. We are naming our app strapi-refine-blog:

npm create refine-app@latest strapi-refine-blog

This will open the Refine CLI shell where you'll be presented with options to interactively choose a tooling system and integration packages we want in the app.

Make sure you have chosen the following in the end:

 ✔ Downloaded remote source successfully.
 ✔ Choose a project template · refine-vite
 ✔ What would you like to name your project?: · strapi-refine-blog
 ✔ Choose your backend service to connect: · data-provider-strapi-v4
 ✔ Do you want to use a UI Framework?: · antd
 ✔ Do you want to add example pages?: · no
 ✔ Do you need i18n (Internationalization) support?: · no
 ✔ Choose a package manager: · npm

Notice that we have selected Strapi v4 as our data provider. And for UI components, we have Ant Design. We also made sure we didn't include example pages. This is because we would like to begin building the pages from scratch.

Code Inspection

Refine initialization scaffolds an application with a directory structure like below:

Please feel free to navigate around and try to make sense of what's going on. The main action happens inside the <Refine /> component rendered in src/App.tsx.

Our choice of Strapi v4 data provider placed Refine's connector for Strapi 4 among Node modules under the node_modules directory in node_modules/@refinedev/strapi-v4/src/index.ts. It also produced a src/constants.ts file that stores API credentials provided by a Strapi backend.

In the sections ahead, we examine what the Strapi v4 package brings us with regards to connecting to resources on Strapi endpoints and performing actions on them. We also replace default credentials in the constants.ts file with that of our Strapi Refine Blog backend.

Refine's Strapi v4 Data Provider: A Sneak Peek

Refine's Strapi v4 package gives us the following dataProvider function inside @refinedev/strapi-v4:

import { DataProvider as IDataProvider, HttpError } from "@refinedev/core";
import { AxiosInstance } from "axios";
import { stringify } from "qs";
import {
    axiosInstance,
    generateFilter,
    generateSort,
    normalizeData,
    transformHttpError,
} from "./utils";

export const DataProvider = (
    apiUrl: string,
    httpClient: AxiosInstance = axiosInstance,
): Required =&gt; ({
    getList: async ({ resource, pagination, filters, sorters, meta }) =&gt; {
        const url = `${apiUrl}/${resource}`;

        const {
            current = 1,
            pageSize = 10,
            mode = "server",
        } = pagination ?? {};

        const locale = meta?.locale;
        const fields = meta?.fields;
        const populate = meta?.populate;
        const publicationState = meta?.publicationState;

        const querySorters = generateSort(sorters);
        const queryFilters = generateFilter(filters);

        const query = {
            ...(mode === "server"
                ? {
                      "pagination[page]": current,
                      "pagination[pageSize]": pageSize,
                  }
                : {}),
            locale,
            publicationState,
            fields,
            populate,
            sort: querySorters.length &gt; 0 ? querySorters.join(",") : undefined,
        };

        const { data } = await httpClient.get(
            `${url}?${stringify(query, {
                encodeValuesOnly: true,
            })}&amp;${queryFilters}`,
        );

        return {
            data: normalizeData(data),
            // added to support pagination on client side when using endpoints that provide only data (see https://github.com/refinedev/refine/issues/2028)
            total: data.meta?.pagination?.total || normalizeData(data)?.length,
        };
    },

    getMany: async ({ resource, ids, meta }) =&gt; {
        const url = `${apiUrl}/${resource}`;

        const locale = meta?.locale;
        const fields = meta?.fields;
        const populate = meta?.populate;
        const publicationState = meta?.publicationState;

        const queryFilters = generateFilter([
            {
                field: "id",
                operator: "in",
                value: ids,
            },
        ]);

        const query = {
            locale,
            fields,
            populate,
            publicationState,
            "pagination[pageSize]": ids.length,
        };

        const { data } = await httpClient.get(
            `${url}?${stringify(query, {
                encodeValuesOnly: true,
            })}&amp;${queryFilters}`,
        );

        return {
            data: normalizeData(data),
        };
    },

    create: async ({ resource, variables }) =&gt; {
        const url = `${apiUrl}/${resource}`;

        let dataVariables: any = { data: variables };

        if (resource === "users") {
            dataVariables = variables;
        }

        try {
            const { data } = await httpClient.post(url, dataVariables);
            return {
                data,
            };
        } catch (error) {
            const httpError = transformHttpError(error);

            throw httpError;
        }
    },

    update: async ({ resource, id, variables }) =&gt; {
        const url = `${apiUrl}/${resource}/${id}`;

        let dataVariables: any = { data: variables };

        if (resource === "users") {
            dataVariables = variables;
        }

        try {
            const { data } = await httpClient.put(url, dataVariables);
            return {
                data,
            };
        } catch (error) {
            const httpError = transformHttpError(error);

            throw httpError;
        }
    },

    updateMany: async ({ resource, ids, variables }) =&gt; {
        const errors: HttpError[] = [];

        const response = await Promise.all(
            ids.map(async (id) =&gt; {
                const url = `${apiUrl}/${resource}/${id}`;

                let dataVariables: any = { data: variables };

                if (resource === "users") {
                    dataVariables = variables;
                }

                try {
                    const { data } = await httpClient.put(url, dataVariables);
                    return data;
                } catch (error) {
                    const httpError = transformHttpError(error);

                    errors.push(httpError);
                }
            }),
        );

        if (errors.length &gt; 0) {
            throw errors;
        }

        return { data: response };
    },

    createMany: async ({ resource, variables }) =&gt; {
        const errors: HttpError[] = [];

        const response = await Promise.all(
            variables.map(async (param) =&gt; {
                try {
                    const { data } = await httpClient.post(
                        `${apiUrl}/${resource}`,
                        {
                            data: param,
                        },
                    );
                    return data;
                } catch (error) {
                    const httpError = transformHttpError(error);

                    errors.push(httpError);
                }
            }),
        );

        if (errors.length &gt; 0) {
            throw errors;
        }

        return { data: response };
    },

    getOne: async ({ resource, id, meta }) =&gt; {
        const locale = meta?.locale;
        const fields = meta?.fields;
        const populate = meta?.populate;

        const query = {
            locale,
            fields,
            populate,
        };

        const url = `${apiUrl}/${resource}/${id}?${stringify(query, {
            encode: false,
        })}`;

        const { data } = await httpClient.get(url);

        return {
            data: normalizeData(data),
        };
    },

    deleteOne: async ({ resource, id }) =&gt; {
        const url = `${apiUrl}/${resource}/${id}`;

        const { data } = await httpClient.delete(url);

        return {
            data,
        };
    },

    deleteMany: async ({ resource, ids }) =&gt; {
        const response = await Promise.all(
            ids.map(async (id) =&gt; {
                const { data } = await httpClient.delete(
                    `${apiUrl}/${resource}/${id}`,
                );
                return data;
            }),
        );
        return { data: response };
    },

    getApiUrl: () =&gt; {
        return apiUrl;
    },

    custom: async ({
        url,
        method,
        filters,
        sorters,
        payload,
        query,
        headers,
    }) =&gt; {
        let requestUrl = `${url}?`;

        if (sorters) {
            const sortQuery = generateSort(sorters);
            if (sortQuery.length &gt; 0) {
                requestUrl = `${requestUrl}&amp;${stringify({
                    sort: sortQuery.join(","),
                })}`;
            }
        }

        if (filters) {
            const filterQuery = generateFilter(filters);
            requestUrl = `${requestUrl}&amp;${filterQuery}`;
        }

        if (query) {
            requestUrl = `${requestUrl}&amp;${stringify(query)}`;
        }

        let axiosResponse;
        switch (method) {
            case "put":
            case "post":
            case "patch":
                axiosResponse = await httpClient[method](url, payload, {
                    headers,
                });
                break;
            case "delete":
                axiosResponse = await httpClient.delete(url, {
                    data: payload,
                    headers: headers,
                });
                break;
            default:
                axiosResponse = await httpClient.get(requestUrl, { headers });
                break;
        }

        const { data } = axiosResponse;

        return Promise.resolve({ data });
    },
});

If you examine the above snippet closely, you can notice that the Strapi v4 data provider uses an Axios instance, axiosInstance, as API client to connect to a Strapi backend. It gives us a dataProvider function that accepts apiUrl and the Axios httpClient to produce the data provider object for Strapi.

This data provider object is generic to any Strapi 4 REST API. It has all the methods needed to perform CRUD actions on a typical Strapi 4 REST API.

Application specific details particular to our backend such as resource and query related configurations like pagination, filters, sorters, id, etc. are being accepted as parameters to these methods. For example, the getList method accepts resource, pagination, filters, sorters and meta which are needed by React Query for caching, state management and request handling. They have to be passed when invoking dataProvider.getList via a corresponding data hook, like useList().

This way, Refine's core and higher level hooks help configure CRUD actions when they are performed from inside a UI component.

How to Connect Strapi REST API to a Refine App

With the above Strapi v4 data provider availed to the app, we can now go about connecting it to our backend API.

The Strapi Backend

For this demo, we are going to connect to Strapi Refine Blog -- a Strapi Cloud hosted simple blog app that comes already configured with necessary permissions and API credentials.

Here's a quick run down of the main points:

The blog contains two resources: posts and categories.
Both resources allow the following actions: create, find, findOne, update and delete to a public role.
Necessary permissions are set from the Strapi Admin panel for public role to be able to access these resources and perform the above actions.
An API token has been generated and stored for use by HTTPS clients.

Adding Strapi API Credentials to a Refine App

Let's update the constants inside src/constants.ts with the below API credentials for Strapi Refine Blog:

export const API_URL = "https://joyful-frog-8daba895c7.strapiapp.com";
export const TOKEN_KEY = "ab2c5697a17afa8c4dadfa2d89995e137a3cb5db05812d007e827aa5a9bc6b88f7d1c6b7d6261a0a2338350a42c0a6f8b5d1b54242122b59c88b81770f50bbafeb6b2598e90f552eff9379fab31ef8c7d454606c05450114607c7a46bf5728a7d04a4d1ceb0c6fd988d6ce7f55c33c6dba3b8e24b11956e394f2660dcf367004";

Ideally, you'd want them stored as environment variables. However, we'll forego this step for the purpose of this simple demo.

Run the Refine Dev Server

Alright, with the Refine app now set to connect with a Strapi backend, we can go ahead and run the app with the following npm command:

npm run dev

This spins up the Refine application server at http://localhost:5173. When we open a browser and visit the app, we should be greeted with the Refine Welcome page:

Summary

In this post, we got familiar with Refine's context and hooks based architecture and learned about how data providers, corresponding hooks and data fetching/rendering libraries work together in a Refine app.

After initializing a Refine app geared to interact with a Strapi 4 backend, we inspected the scaffolded code to gain useful insight into how Refine's Strapi 4 backend adapter helps connect to a Strapi REST API and enables CRUD operations with a set of methods defined to implement CRUD actions. We also updated the Refine app with credentials for our Strapi Refine Blog CMS that is hosted on Strapi Cloud.

In Strapi with Refine Part II: How to Add CRUD Pages to a Strapi Backed Refine App, we reveal how to build the resource pages for all CRUD actions with Ant Design supported Refine hooks and components.

Auto-currying in JavaScript

Abdullah Al Numan — Tue, 02 Aug 2022 05:58:00 +0000

Auto-currying in JavaScript

In this post, we explore auto-currying in JavaScript.

This is the fourth article in the series titled Curry Functions in JavaScript. It follows the previous article named Currying Existing Functions with JavaScript, where we mentioned that curried functions can be of various complexities, such as auto-curried unary functions, variadic ones, infinitely curried functions, etc.

This post will cover auto-currying with a purely unary implementation.

Auto-currying, what the Heck ?

Auto-currying is an advanced currying implementation technique. It is an in-built feature in Haskell, where a multary function has to be curried by the compiler, because all functions are unary to begin with. So, a multary function always gets auto-curried in Haskell.

In JavaScript, though, functions are not restricted to be unary. We're currying stuff for the heck of it, because it's exciting and fun. We don't have auto-currying in JavaScript, because we literally don't need it. And just for the record, we might not call currying in JavaScript "currying" in the actual sense. By the mid of the next article, we'll find out we're just fooling around.

We want to implement currying ourselves. Obviously, it won't be auto-currying in the sense that our functions should be curried automatically by the compiler; rather that we are making the transformation with our own code by moving it to runtime. That is, instead of manually defining a currying function for each passed-in multary function, we are automating the task of transformation for that function with a wrapper and a couple of helpers.

We can do this by making use of plain JavaScript function composition along with recursion. And in the later posts we will see that we can achieve the same transformation with native JavaScript methods like Function.prototype.call, Function.prototype.apply, Function.prototype.bind as well.

Automating the Currying Process

In the previous post, Currying Existing Functions with JavaScript, we saw that we used a wrapper function that acts as an accumulator of arguments by leveraging nested closures. The accumulator function plays the central role in currying. We need one in every currying transformation.

However, in auto-currying we don't use a nested functions system. Instead, we use recursion. We track the number of arguments passed, compare it to the multary function's arity, and use the comparison to decide whether we should keep accepting more arguments by returning the accumulator recursively. Once we have enough arguments, we terminate the accumulator and return a call to the to-be-curried function.

The Plan
The key idea is to allow accepting only one argument at a time - as unarity is the essence of currying. Then we go ahead and store the arguments in an array, whose copy should be always accessible from the current execution context of the recursive stack.

Example

In the following example, we define the accumulator to accept only one argument at a time:

function curry(f) {
  function curried(args) {
    if (args.length >= f.length) return f(...args);
    return accumulator;

    function accumulator(a) {
      return curried([...args, a]);
    };
  };

  return curried([]);
};

Notice that we are declaring accumulator() inside the curried() helper function to give it access to the args array so that an updated args can be passed on to successive recursive calls.

Notice also that we are using args in the parameter of curry() as an array and not as a list spread from the array: ...args. And we pass an empty array to the first call on curried().

And now, we want to curry our createMessage() function with curry() at runtime and use it:

function createMessage(greeting, name, message) {
  return `${greeting}, ${name}! ${message}`;
};

const curriedCreateMessage = curry(createMessage);

console.log(curriedCreateMessage('Hi')('Haskell')('Whadup?')); // Hi, Haskell! Whadup?
console.log(curriedCreateMessage('Hi', 'Hello')('Haskell', 'Hasikell')('Whadup?', `What's up`));
// Hi, Haskell! Whadup?

Notice the second log above ignores additional arguments and returns the same Hi, Haskell! Whadup? string as the first, despite being passed two arguments at each call.

We could have written the curry() function like this:

function curry(f) {
  return function curried(...args) {
    if (args.length >= f.length) return f(...args);
    return accumulator;

    function accumulator(a) {
      return curried(...args, a);
    };
  };
};

But there is a problem with this for returning all-out unary functions. We'll come to that in the next article on variadic currying. But what's the problem?

Feel free to share your thoughts in the comments.

Currying Existing Functions with JavaScript

Abdullah Al Numan — Sun, 31 Jul 2022 05:20:00 +0000

This post is about transforming an already defined polyadic function into a curried function.

This is the third post in a series on curried functions titled Curry Functions in JavaScript. This follows the previous post named Basic Curried Functions in JavaScript.

Basic vs Advanced Currying

Basic curried functions are different from more advanced ones because basic currying doesn't involve taking a function as an argument, whereas more advanced ones do. Basic curried functions are defined from scratch, whereas advanced currying involves using an already existing multary function.

From a higher level, currying is more of an approach of transforming an otherwise uncurried function to return a series of unary functions - regardless of whether it is hardcoded by the author or transformed at runtime.

We will consider several advanced cases differing in their complexity levels: first one involving a wrapper function defined manually from ground up, but basing it on the passed, to-be-curried function.

In the upcoming posts, we will also cover auto-currying, variadic currying, infinite currying and currying to a fixed arity.

This article covers currying existing functions manually.

Currying Existing Functions Manually

In this example, we'll use the createMessage() function we wrote in the previous post named Basic Curried Functions in JavaScript.

Let's say, we have the function that returns the message string in hand:

function createMessage(greeting, name, message) {
  return `${greeting}, ${name}! ${message}`;
};

Instead of writing a curried function from scratch for the above function, like this:

function createMessage(greeting) {
  return function(name) {
    return function(message) {
      return `${greeting}, ${name}! ${message}`;
    };
  };
};

we can use the existing multary function by passing it to a wrapper function and then build the wrapper function on top of it:

function curryATernaryFunction(f) {
  return function(greeting) {
    return function(name) {
      return function(message) {
        return f(greeting, name, message);
      };
    };
  };
};

Then calling the wrapper function with createMessage will give us the curried function. We can use it for our purposes afterwards:

const curriedCreateMessage = curryATernaryFunction(createMessage);
console.log(curriedCreateMessage('Hi')('Haskell')('Whadup?'));
// Hi, Haskell! Whadup?

I named the above function curryATernaryFunction because I wanted to play with it a bit. We can actually curry other ternary functions (those that take three arguments) with it:

function addThreeThings(one, two, three) {
  return one + two + three;
};

console.log(curryATernaryFunction(addThreeThings)('Hi')('Haskell')('Whadup?'));
// HiHaskellWhadup?
console.log(curryATernaryFunction(addThreeThings)(1)(2)(3)); // 6

How it works:
The wrapper function is called an accumulator. Its purpose is to store all the passed in arguments and make them available to the multary function. It uses nested closures (the returned functions at each level of nesting along with their lexical environments) to accumulate all the arguments for the final returned function.

The way it works is, every time a returned function is invoked and it takes its given argument, the argument is held at its immediately nested function's lexical scope - which makes it available to deeper ones via their scope chain. So, our core function's execution context is able to access all the arguments.

Basic Curried Functions in JavaScript

Abdullah Al Numan — Fri, 29 Jul 2022 11:50:00 +0000

In this post, we will dive into curried functions with JavaScript, with an example of a basic curried function.

In the previous post named Curry Functions in JavaScript, we discussed what arity, unary and curried functions are, and how they are related. We'll use these concepts in this article and the upcoming ones.

Basic Example

In the example below, we define a createMessage() unary function that returns a series of nested unary functions.

function createMessage(greeting) {
  return function(name) {
    return function(message) {
      return `${greeting}, ${name}! ${message}`;
    };
  };
};

The outer function takes one argument and returns the first nested function, which when invoked with an argument will return its nested function, an so on.

Notice, the return value of our interest is in the final return statement, which we could have achieved with a multi-argument function:

function createMessage(greeting, name, message) {
  return `${greeting}, ${name}! ${message}`;
}

Currying made it into a series of returned unary functions. We can now call createMessage() with one argument at a time, sequentially:

console.log(createMessage('Hi')('Haskell')(`What's up?`));
// Hi, Haskell! What's up?

Partials

Curried functions make it very convenient to generate partial functions:

const greet = createMessage('Hello');
const goodMorning = createMessage('Good Morning');

const greetHaskell = greet('Haskell');
const greetAbdullah = greet('Abdullah');
const wishHaskell = goodMorning('Haskell');

Note here that, we are not returning the final return statement, not as yet.

console.log(greet);
/*
Returns
f (name) {
  return function(message) {
    return `${greeting}, ${name}! ${message}`;
  };
 }
*/

console.log(greetHaskell);
/*
Returns 
f (message) {
    return `${greeting}, ${name}! ${message}`;
  }
*/

We have to call each returned function, one by one, sequentially - until we provide all the arguments.

const askHaskell = greetHaskell('Where are you now?');
console.log(askHaskell);
// Hello, Haskell! Where are you now?

Curry with Arrow Functions

Arrow functions make it very easy to write curried functions. The above function can be written in one line:

const createMessage = greet => name => message => `${greet}, ${name}! ${message}`;

const messageHaskell = createMessage('Hi')('Haskell')('How are you?');
console.log(messageHaskell); // Hi, Haskell! How are you?

In the next article, Currying Existing Functions with JavaScript, we'll start exploring more advanced cases that involve transforming an already defined function into a curried function.

Curry Functions in JavaScript

Abdullah Al Numan — Fri, 29 Jul 2022 11:34:00 +0000

This is a series of articles on currying functions in JavaScript. It consists of an introductory post (this one) and several follow ups that delve into basic and advanced currying with JavaScript.

In the next post, named Basic Curried Functions in JavaScript, we'll see an example of a basic curried function. And in the follow up posts, we'll gradually cover more advanced techniques for currying existing functions.

Before that, first, we'll consider a few underlying terminologies.

Arity

The arity of a function is the number of arguments a function expects at invocation.

Unary Functions

Unary functions are functions that take only one argument, i.e. their arity is one. They are very common in Haskell, where a function can only be unary.

Curried Functions

The simplest form of a curried function is a unary function that returns another unary function. The returned function can also return another unary function. Returning nested unary functions continues in sequence to achieve the results of a multi-argument function. This gives us the ability to call the function with one argument at a time, sequentially.

// Regular multi-argument function
const createMessage = (greeting, name, message) => {
  return `${greeting}, ${name}! ${message}`);
};

// A curried function helping achieve the same thing
const createMessage = greeting => name => message => `${greeting}, ${name}! ${message}`);

// So now we can do this:
createMessage('Hello')('World')('Whadup?');

In Haskell, this is the technique used to deliver functions that effectively accept multiple arguments, but one at a time. The word "curry" comes from Haskell Curry.

Higher Order Functions

Curried functions are also Higher Order Functions, or HOFs -- as they always return other functions, and also commonly take in the to-be-curried function.

Variadic Curried Functions

A variadic curried function is a more sophisticated curried function that is able to take variable number of arguments per call. Each returned function may take a single argument, or more than one argument. Basically, we can also do this:

createMessage('Hello', 'World')('Whadup?');
// or
createMessage('Hello')('World', 'Whadup?');

In JavaScript, what's the difference between a variable that is: null, undefined and undeclared?

Abdullah Al Numan — Thu, 21 Jul 2022 12:40:00 +0000

In JavaScript, it is common to declare and initialize a variable at the same time. It is also commonplace to declare a variable, leave it uninitialized, and then assign it at a later point. Any undeclared variable evaluated in the code, throws ReferenceError.

null and undefined are JS primitives and they differ from each other in terms of their types and what values they represent. Undeclared, however, is plain English, not a JavaScript keyword.

Differences

There are a number of differences between variables that are null and undefined:

A null value's type is object, whereas an undefined variable is of undefined type.
null represents the presence of a value, but an intentional absence of an object (therefore, of type object), while an undefined variable points to absence of any value.
null has to be assigned to a variable. In contrast, undefined is set automatically at declaration, and can also be assigned explicitly.

Undeclared variables are different from null and undefined in the way how JavaScript treats an undeclared variable. An undeclared variable throws a ReferenceError, but its type is actually undefined.

console.log(x); // Uncaught ReferenceError: x is not defined
console.log(typeof x); // undefined

Notice how typeof x doesn't throw an error, because x is not being evaluated here.

Checking for them

Falsiness
null and undefined represent ~~negative~~ an absence of some value types. So, they are termed as falsy, as opposed to a truthy value.

In order to decide whether a variable is either null or undefined, we have to get a falsy value. In other words, not a truthy one. Generally, a variable is tested for truthiness, and if it fails, its falsy, i.e. either null or undefined.

let x;
if (x) {
  console.log(`Hi, this is ${x}.`);
} else {
  console.log(x); // undefined
};

x = null;
if (x) {
  console.log(`Hi, this is ${x}.`);
} else {
  console.log(`Now I'm ${x}`); // Now I'm null.
};

In order to decide between null and undefined states of a variable we have to test it with the strict equality operator ===:

let x;
if (x === undefined) {
  console.log(`Hi, this is ${x}.`); // Hi, this is undefined.
} else {
  console.log(x); 
};

x = null;
if (x === null) {
  console.log(`Hi, this is ${x}.`); // Hi, this is null.
} else {
  console.log(x); 
};

This is because the standard equality operator, ==, is ambiguous in deciding between the two. It returns true for any of these two values.

let x;
if (x == null) {
  console.log(`Hi, this is ${x}.`); // Hi, this is undefined.
} else {
  console.log(x); 
};

x = null;
if (x == undefined) {
  console.log(`Hi, this is ${x}.`); // Hi, this is null.
} else {
  console.log(x); 
};

Notice, how x == null returns true for x = undefined and x == undefined returns true for x = null. It's out of mind.

Undeclared
Undeclared variables in the global scope can be checked without throwing a ReferenceError with :

if ( 'x' in window) {
  console.log('Hi'); 
} else {
 console.log(`Hi, x doesn't live here.`); // Hi, x doesn't live here.
};

References

Explain why the following doesn't work as an IIFE: "function foo(){ }();". What needs to be changed to properly make it an IIFE?

Abdullah Al Numan — Thu, 21 Jul 2022 06:46:00 +0000

This code returns a token error:

function foo(){ }(); // Error: Unexpected token ')'

Parens

If we place an expression inside the second parens (the grouping operator, which expects an expression to be evaluated), the error goes away.

function foo(){ }(1);

So, we know the token error is due to the second parens, which did not have any expression to evaluate.

But... it still doesn't work as an IIFE.

Breakdown

Let's change foo() to log a greeting. As you can see, nothing gets logged to the console.

function foo(){ console.log('Hello from foo!') }(1); // Nothing logged to the console

This is because foo() is never invoked.

In fact, we are wrong in expecting foo() to be invoked like this:

function foo(){ console.log('Hello from foo!') }();

Because, the second parens does not stand for invoking foo() here. And that is because the function declaration left to it, function foo(){ }, is not an expression. It's just a definition.

The parser sees the code above as:

function foo(){ console.log('Hello from foo!') };
();

Fix

In order to make the second parens (immediately) invoke foo(), we need to make the function declaration evaluate to a function expression first. And guess what, we do it with another parens.

(function foo(){ console.log('Hello from foo!') });

We can then go ahead and apply the invocation parens:

(function foo(){ console.log('Hello from foo!') }(); // "Hello from foo!"

Another fix would be to wrap the entire code in an overarching parens. This will also make it work as an IIFE:

(function foo(){ console.log('Hello from foo!') }()); // "Hello from foo!"

Here, everything, including the last parens is considered part of one expression and so foo() gets invoked.

References

Interview Question: Explain how `this` works in JavaScript [in 3 mins].

Abdullah Al Numan — Wed, 20 Jul 2022 09:50:56 +0000

In JavaScript, this is a property of the execution context in which a function is executed.

The explanation for how this gets evaluated is very elaborate, and it is covered case by case in this MDN article comprehensively.

The value of a function's this is determined mostly by how the function is being called in the call site, rather than how the function is defined: things like whether strict mode is enabled or not, whether the function is defined and called standalone or not, whether we are calling the function as a method of an object or if we are extracting a reference of an object method and then calling it somewhere else, etc.

Execution Context

A function's execution context is the environment in which the function is executed at runtime. It includes, the variable scope, function arguments and the value of this object.

`this`

If we need a function which acts on the properties of an object we want to use, its this ought to be that object. In other words, our function's target object has to be made available to the execution context at runtime, so that we are able to access it with this.

In normal mode, this is always an object. undefined and null values are autoboxed to the global object (the window object in the browser). In strict mode, however, it can be undefined or null, as there is no autoboxing of this in strict mode.

function testThis() {
  return this;
};
console.log(testThis()); // [object Window]

function testThisInStrictMode() {
  'use strict'
  return this;
};
console.log(testThis()); // undefined

In Objects

If we have an object with a method that uses this and we call the method on the object, the object is automatically assigned to the method's this.

const person = {
  name: 'Abd',
  age: 42,
  sayHi: function() {
    return `Hi, this is ${this.name}`;
  },
};

console.log(person.sayHi()); // "Hi, this is Abd"

The same applies to instances of custom objects created using constructor functions, as well as classes.

// constructor function example
function Person() {
  this.name = 'Abd';
  this.age = 42;
  this.sayHi = function() {
    return `Hi, this is ${this.name}`;
  };
};
const person = new Person();
console.log(person.sayHi()); // "Hi, this is Abd"

// class example
class Person {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  };

  sayHi() {
    return `Hi, this is ${this.name}`;
  };
};

const person = new Person('Abd', 42);
console.log(person.sayHi()); // "Hi, this is Abd"

Function References

Probably the most highlight-able case about this in JavaScript arises when we want to extract a reference of a method from an object and then call it from elsewhere.

For example, if we store the sayHi() method of the person object (from any of the examples above) in a variable and then invoke it later on, we will not have any object set for the method to act on. We are effectively detaching the object from the referenced function, so this for this function at runtime will be either the global object or undefined depending on whether in normal mode or strict mode.

`use strict`
const sayHiAbd = person.sayHi; // Note that person.sayHi is NOT being invoked here
console.log(sayHiAbd()); // Error: Cannot read property 'name' of undefined

In this scenario, sayHiAbd() is like a standalone function defined as follows:

function sayHiAbd() {
  return `Hi, this is ${this.name}`;
};

In such cases, we have to call the function using .call() or .apply() in order to set the this object explicitly at the call site.

console.log(sayHiAbd.call({name: 'Abd', age: 42})); // "Hi, this is Abd"

Binding Permanently

If we want to permanently bind an object to the function, we have to create a new function with .bind(), which attaches the object to the new function.

const alwaysSayHiAbd = sayHiAbd.bind({name: 'Abd', age: 42});
console.log(alwaysSayHiAbd()); // "Hi, this is Abd"

Arrow Syntax

The arrow syntax permanently binds the enclosing lexical context of the function definition to its execution context. So, the call site context never meddles with arrow functions.

In the object literal person example above, if we modify our sayHi() function to return an arrow function that returns the greeting string, the returned (arrow) function's this gets bound to its enclosing lexical context, which is the person object itself. Storing a reference to it and calling it always points its this to person.

const person = {
  name: 'Abd',
  age: 42,
  sayHi: function() {
    return () => `Hi, this is ${this.name}`;
  },
};
const sayHiAbd = person.sayHi();
console.log(sayHiAbd()); // "Hi, this is Abd"

References

What is NaN in JavaScript? What is its type? How can you reliably test if a value is equal to NaN?

Abdullah Al Numan — Mon, 18 Jul 2022 08:57:16 +0000

In JavaScript, NaN is a property of the global Object. In other words, it is a variable available in the Global scope.

It stands for Not-A-Number but interestingly, its type is number.

console.log(typeOf NaN); // "number"

It is used to denote an object that is not or does not compute to a number, in a context when number operations are applied on that object.

Another interesting fact about NaN is, it never equals to itself. So NaN == NaN or NaN === NaN is always false.

console.log(NaN == NaN); // false
console.log(NaN === NaN); // false

Testing for NaN

Since a NaN is never equal to another NaN, a self-comparison of a value makes it the most reliable way to test if the value is NaN.

function isThisNaN(value) { return value !== value };

isThisNaN(1); // false
isThisNaN(NaN); // true
isThisNaN(Number.NaN); // true
isThisNaN('NaN'); // false

Other ways to test if an object is NaN are using the isNaN() global method and Number.isNaN().

console.log(isNaN('hi')); //true
console.log(isNaN('4'); // false

In the two examples above, isNaN() waits for type coercion on the string before it makes the comparison. In the first case with 'hi', the string is coerced to number, which then evaluates to NaN because it doesn't return a number. In the second case with '4', it gets evaluated to a number so it is not a NaN. So using isNaN() is not very reliable to test for NaN

In contrast, Number.isNaN() tests the current value:

console.log(Number.isNaN('hi')); // false
console.log(Number.isNaN('4')); // false (this time because 
                                // it's a string in the
                                // context of a Number method)

Type coercion is not present with Number.isNaN(). Instead, it compares the string directly. In the code above, both 'hi' and '4' are strings and therefore not NaN in the context of a Number method. This makes Number.isNaN() more reliable than isNaN() while testing for NaN values.

References

What is the significance, and what are the benefits, of including 'use strict' at the beginning of a JavaScript source file?

Abdullah Al Numan — Mon, 18 Jul 2022 05:08:18 +0000

In JavaScript, the use strict statement allows us to choose strict mode to write and execute our code.

Normal JS is very beginner friendly.

It tolerate syntax errors by remaining silent about them - which can result in unnoticed bugs.
It does a lot of heavy lifting for mapping variables with their identifiers by checking the scope chain for each name - which costs time and memory.
It makes life easier by treating the parameter values set at function definition to be the same as the values passed to the function at invocation as items of the arguments object - which can sometimes render actual passed in values unimportant.
It autoboxes the this value of a function and exposes the Function.prototype.caller and Function.prototype.arguments APIs that gives access to the caller function and arguments object respectively. All of these three poses security concerns.

Strict Mode

Strict mode addresses these issues and brings about changes to give developers more control over their code. The changes can be classified into four categories. Below we briefly discuss some of them in each category. For detailed explanation and code examples, please refer to this excellent MDN article

1. Changes related to mistakes arising from syntax and type conversion

Mistakes related to syntax and type conversion throw errors, instead of silently ignoring them. There are several of them.
For example,

mistyped variables throw ReferenceError.
Assignment to a non-writable global (like undefined or NaN) throw a TypeError.

Please refer to this section of the MDN Strict Mode article for more examples.

2. Changes related to variable usage

Variable name mapping is optimized by prohibiting the use of with.
eval can introduce new variables in it's own enclosed scope only, not in the surrounding / global scope.
Deleting declared variables is not allowed.

3. Changes related to `eval` and `arguments` object

eval and arguments object are made easier to work with. They are treated like other pre-assigned language keywords and cannot be used to name variables and functions.
arguments object of a function is set only when the function is invoked. So setting a value for an argument in the function definition does not update the arguments object and updating an item in the arguments object with arguments[i] = 'Something, not necessarily a string' does not change the value of the corresponding parameter variable.

4. Changes related to security

Written code is made more secure by preventing autoboxing of this. undefined and null values of this do not autobox to the Global object.
Function.prototype.caller and Function.protoype.arguments throw TypeError, so this prevents traversing the call stack - making strict mode code more secure.

References

Forem: Abdullah Al Numan

[Boost]

Top Coding Agents: What's your take ?

Abdullah Al Numan ・ Jul 24

Variadic Currying in JavaScript

Variadic Currying in JavaScript

Variadic Partial Application

Using Function.prototype Methods

Variadic Currying with Termination

Summary

Strapi with Refine Part I: An Introduction to Refine's Strapi v4 Connector

Introduction

Overview

Refine Architecture

Refine Has an Extensible Headless Core

Providers in Refine

Refine Data Rrovider

Refine Data Provider Shape

Hooks in Refine

Core Hooks vs Higher Level Hooks

Refinedev Ant Design Support Package

Refine Under the Hood

Setting Up Strapi 4 Data Provider in a Refine App

Pre-requisites

Initializing a Strapi Backed Frontend App with Refine

Code Inspection

Refine's Strapi v4 Data Provider: A Sneak Peek

How to Connect Strapi REST API to a Refine App

The Strapi Backend

Adding Strapi API Credentials to a Refine App

Run the Refine Dev Server

Summary

Auto-currying in JavaScript

Auto-currying in JavaScript

Auto-currying, what the Heck ?

Automating the Currying Process

Example

Currying Existing Functions with JavaScript

Basic vs Advanced Currying

Currying Existing Functions Manually

Basic Curried Functions in JavaScript

Basic Example

Partials

Curry with Arrow Functions

Curry Functions in JavaScript

Arity

Unary Functions

Curried Functions

Higher Order Functions

Variadic Curried Functions

In JavaScript, what's the difference between a variable that is: null, undefined and undeclared?

Differences

Checking for them

Explain why the following doesn't work as an IIFE: "function foo(){ }();". What needs to be changed to properly make it an IIFE?

Parens

Breakdown

Fix

Interview Question: Explain how `this` works in JavaScript [in 3 mins].

Execution Context

this

In Objects

Function References

Binding Permanently

Arrow Syntax

What is NaN in JavaScript? What is its type? How can you reliably test if a value is equal to NaN?

Testing for NaN

What is the significance, and what are the benefits, of including 'use strict' at the beginning of a JavaScript source file?

Strict Mode

1. Changes related to mistakes arising from syntax and type conversion

2. Changes related to variable usage

3. Changes related to eval and arguments object

4. Changes related to security

Using `Function.prototype` Methods

`this`

3. Changes related to `eval` and `arguments` object