DEV Community: yw662

What indeed is `this` in JavaScript

yw662 — Sun, 26 Feb 2023 11:42:13 +0000

Functions and their invocations

Before we talk about this let's talk about function invocations first.

A function, in general is a (...args: TArgs) => TReturn. The code inside a function are given access to a list of arguments (or parameters if you like), but those arguments are undecided before the function is invoked, that is why they are called "formal". They are kind of "imaginary". The code "imagine" there will be a list of real values to use, but that happens only when the function is invoked, and only for and during this specific invocation.

Arguments are finally bond to a "actual" value upon each invocation, and are different among different invocations.

But this is not in the list. How can a function access an argument/a parameter, when it is not in the list ?

Is `this` a capture ?

High level programming languages, like JavaScript, has an ability to "capture" identifiers (or usually, variables, if you like, or you may just call it "an item") from the current "lexical scope" and make those captures usable inside the function. This is indeed not that trivial as it seems. A function can capture an identifier if and only if it is inside the lexical scope of that identifier.

But, Is there an identifier called this to capture? Usually no. For "arrow expressions", yes this, if there is one, is a capture. But for functions that are not arrow expressions, no.

Then what is `this` indeed ?

If it is not a capture, it is an argument. It "has to" be an argument or it will never be bond to an actual value.

But it is not in the list. Usually arguments are explicitly defined in the list, not for the two "implicit arguments" in JavaScript. One of the two is this, and the other one is arguments. Arrow expressions have no implicit arguments therefore no this and arguments.

So, implicit argument, is an argument but passed implicitly.

But how you pass an argument implicitly ?

Each argument must be decided upon "invocation". Therefore, the implicit argument this is passed upon invocation. But you don't pass it via the list, you pass it by the "member expressions" (in ecma262) or "property accessors" (in MDN).

Member expressions include, the dot in a.b, the bracket pair in a[b], the new in new b(), the .# in a.#b, and super. These are pretty much what we would care about, since you would never worry about this in new.target, import.meta and template literal calls.

That is to say, if you call a function like a.b() or a[b](), a will be passed as this. If you call it like new b(), the object created by new will be passed. That is the basic rule of this.

The implicit argument arguments is passed as the whole actual argument list, including those without a formal argument bond. It is less useful today thanks to the super cool rest syntax.

Let's make it short: you pass this by "member expression". That's it. Although ecma262 is not describing it this way, it pretty much follows this logic. It is pretty much a lexical thing.

corner cases ?

If a function foo is called without using member expression, it is implicitly a globalThis.foo (if it is not strict mode), or the this argument is simply not passed, therefore it is undefined (in strict mode).
Or let's make it clear: why would you ever want to access this if you are not planning to pass it ?

If you are not calling a function directly, it is the direct caller to decide how it is called. eg. function.prototype.apply, function.prototype.call and function.prototype.bind. As well as Array.prototype.map and so on: if you are not the direct caller, ask its direct caller to pass this.

These are not really corner cases. One is to say "if it is not passed it is not passed", and the other is to say "if you are not the caller you are not the caller". It is just that the runtime gives those internal things some cheating power, so you are allowed to b.bind(a) even if b is not a member of a.

So,
you pass this by "member expression". That's it.

But why it seems so dynamic if it is indeed lexical ?

In statically typed OOP languages like C++, this is exactly an implicit argument. The "left hand side value of the member operator" (. or ->) is passed as an argument, and it depends on the calling convention (or ABI) how it is practically passed.

For rust, and surprisingly, lua, this is an explicit formal argument but an implicit or explicit actual argument, so you won't need the keyword. If you are passing it implicitly, it will be "the left hand side value of the member operator", or it will be what you put in the list.

Lua uses a special member operator : for this particular case, which means, "call the function with the left hand side value of operator : as the first argument". So a:b(...) means exactly a.b(a, ...). A smart and thoughtful design.

You should see how "dynamic" the this argument could be in lua even though it is such beautifully designed. It is the same case in JavaScript.

In statically typed languages, if a function is a member function (or "method" but it really is just a function), it will "always" be called with a "correctly" typed this. It is totally predictable. However, in dynamically typed languages like lua and JavaScript (and Python), you may pass whatever as this. It is lexical, but it is dynamically AND weakly typed.

For example you can never do a f = a.b; f() in C++, but you do it everyday in JavaScript. It is impossible to f = a.b.bind(c) in C++, but this is what JavaScript may do. You need to make it a "delegate" or "callable object" (objects with operator() overloaded) in C++, CSharp and Java but a "closure" is simply as useful as a general "callable object".

C++ treats "member function pointer" differently from a normal function pointer, obviously because there is an implicit this argument to pass, if you don't know what to pass as this you cannot call it. But in JavaScript ? a.b is a function and lets forget about passing this.

TypeScript has a "this argument type restriction" to make it less weak. It works when it works but you have to explicitly apply this restriction, otherwise it would just assume you are being a nice kid and not making troubles around.

But let's say making troubles is the JavaScript way. We enjoy the dynamic world and hopefully it can be a bit lexical and strong. That's JavaScript.

custom elements and streamed HTML: Make CSR Great Again

yw662 — Sun, 26 Feb 2023 04:57:29 +0000

This is a report for a recent experimental demonstrating project we are working on. However, the techniques used in the post is framework neutral.

Why are CSRs not great ?

Server side rendering, aka SSR, and static site generation, aka SSG, is now the standard de facto of web app practice. You basically ship a web page that "just works" to the browser, and the browser can just render it, without extra downloads and execution. That is just the "correct answer" for the browser side.

However the execution has to happen somewhere. In SSR, it happens on the server. If we take the server side execution time into consideration, the performance benefits of going SSR would not seem so promising. you cache it for later use so it won't run on every single request, but server resources are more precious, because you are not serving only one user. One single server side re-rendering execution may delay all concurrent clients, it can be, let's say, hundreds based on the server load.

In SSG, it happens when you build it. It is good if you are not rebuilding it again and again.

But somehow that is still better than CSR, even for quickly changing realtime data so SSG is completely out. The key point here is the total latency, of which the most significant factor is RTT.
SSR is guaranteed 1-RTT for first time and later, and the result can be cached. CSR is usually 2-RTT for first time, or even more, and will always re-render. SSG, with carefully designed caching strategy, is 1-RTT for first time and 0-RTT later since it is static, without re-renders.

Of course the benefit of going SSR or SSG is really not only about RTT, they are great in many aspects. I really love this article by Ryan on how great SSR is.

If it will anyway re-render, which is not necessarily a bad thing, is it possible to make a dynamic page (let's just assume the page may randomly change every single second) 1-RTT but CSR ?

Only if the data is sent along with the document, but not rendered. It is indeed somewhere in between CSR and SSR, but at least you are definitely not paying huge server side computational resources for that.

What custom elements / web components can do ?

It can be easily explained by a example:

<html lang="en">

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="shortcut icon" href="assets/favicon.svg" type="image/svg+xml">
  <script src="/components/streamReceiver.js" type="module" async></script>
  <style>
    stream-data {
      display: none
    }
  </style>
</head>

<body>
  <stream-receiver data="stream-data"></stream-receiver>
  <stream-data data-text="0">0</stream-data>
  <stream-data data-text="1">1</stream-data>
  <stream-data data-text="2">2</stream-data>
  <stream-data data-text="3">3</stream-data>
  <stream-data data-text="4">4</stream-data>
  <stream-data data-text="5">5</stream-data>
  <stream-data data-text="6">6</stream-data>
</body>

</html>

There is a custom element stream-receiver introduced in /components/streamReceiver.js with an attribute data="stream-data". The connectedCallback is implemented as such:

    constructor() {
      super()
      const dataTag = this.getAttribute('data')?.toUpperCase()
      if (!dataTag) throw new TypeError('no dataTag')
      this.dataTag = dataTag
      this.shadow = this.attachShadow({ mode: 'open' })
    }
    connectedCallback() {
      const data = document.querySelectorAll(this.dataTag)
      for (const element of data) {
        this.onData(element)
      }
    }

The server could just embed the data in side the data-text attribute of the stream-data element, and the component could access those data with element.dataset.text.

So, 1-RTT dynamic page, with CSR.

Wait, this is not great at all.

So now we have streamed HTML, and it works great with the code above, with just a little bit tweak of the component.

    constructor() {
      super()
      const dataTag = this.getAttribute('data')?.toUpperCase()
      if (!dataTag) throw new Error('go full CSR')
      this.dataTag = dataTag
      this.shadow = this.attachShadow({ mode: 'open' })

      const p = document.createElement('p')
      p.textContent = 'Make CSR great again'
      this.shadow.appendChild(p)
    }
    connectedCallback() {
      const onMutation: MutationCallback = record => {
        for (const mutation of record) {
          if (mutation.type === 'childList') {
            const dataList = mutation.addedNodes
            for (const data of dataList) {
              if (data instanceof HTMLElement && data.tagName === this.dataTag) {
                this.onData(data)
              }
            }
          }
        }
      }
      const observer = new MutationObserver(onMutation)
      observer.observe(document.body, { childList: true })
      const data = document.querySelectorAll(this.dataTag)
      for (const element of data) {
        this.onData(element)
      }
    }
  }

Now we use a MutationObserver to observe the children of document.body. Hopefully we should only see stream-data since all the real UI changes go inside the component.

Streamed HTML, but how ?

I said this post is framework neutral, but for this part the code is for cloudflare "edge runtime". It is trivial to rewrite it for other platforms. It is server side so it has to be on some platform.

export const onRequest: PagesFunction = async ctx => {
  const document = new Document({
    component: {
      tag: 'stream-receiver',
      src: '/components/streamReceiver.js'
    },
    lang: 'en',
    dataTag: 'stream-data',
    favicon: { href: 'assets/favicon.svg', type: 'image/svg+xml' }
  })
  ctx.waitUntil(writeDocument(document))
  return document.response
}

The entry point is simple. Let's move to how that Document looks like.

export class Document {
  static favicon(href: string, type: string) {
    return `<link rel="shortcut icon" href="${encodeURI(href)}" type="${type}">`
  }
  static scriptLine(src: string) {
    return `<script src="${src}" type="module" async></script>`
  }
  static componentLine(tag: string, dataTag: string) {
    return `<${tag} data=${dataTag}></${tag}>`
  }
  static styleLine(dataTag: string) {
    return `<style>${dataTag} {display: none}</style>`
  }
  static opening({ component, lang, favicon, dataTag }: {
    component: { tag: string, src: string },
    lang?: string
    favicon?: { href: string, type: string }
    dataTag: string
  }) {
    return '<!DOCTYPE html>' +
      (lang ? `<html lang="${this.escape(lang)}">` : '<html>') +
      '<meta charset="UTF-8">' +
      '<meta name="viewport" content="width=device-width, initial-scale=1.0">' +
      (favicon ? this.favicon(favicon.href, favicon.type) : '') +
      this.scriptLine(component.src) +
      this.styleLine(dataTag) +
      '</head><body>' +
      this.componentLine(component.tag, dataTag)
  }
}

Let's begin with some helper functions. We are just playing with strings here to assemble what should be sent immediately. This is what the opening function would return:

<html lang="en">

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="shortcut icon" href="assets/favicon.svg" type="image/svg+xml">
  <script src="/components/streamReceiver.js" type="module" async></script>
  <style>
    stream-data {
      display: none
    }
  </style>
</head>

<body>
  <stream-receiver data="stream-data"></stream-receiver>

And how we actually send it:

  readonly response: Response
  readonly dataTag: string
  private readonly writer: WritableStreamDefaultWriter<ArrayBuffer>
  private readonly encoder: TextEncoder
  private waitUntil?: Promise<void>

  private write(v: string) {
    this.waitUntil = (this.waitUntil || Promise.resolve()).then(
      () => this.writer.write(this.encoder.encode(v))
    )
    return this.waitUntil
  }

  constructor(options: {
    component: { tag: string, src: string },
    lang?: string
    favicon?: { href: string, type: string },
    dataTag: string
  }) {
    options.dataTag = options.dataTag
    this.dataTag = options.dataTag

    const { writable, readable } = new IdentityTransformStream()
    this.response = new Response(readable, {
      headers: { 'content-type': 'text/html' }
    })
    this.writer = writable.getWriter()
    this.encoder = new TextEncoder()
    this.write(Document.opening(options))
  }

A readable stream is used to create the response, and the writer can be used later to write the data.

Here is how the data is written:

const writeDocument = async (document: Document) => {
  for (let i = 0; i < 20; i++) {
    if (Math.random() > 0.5) await new Promise(cb => setTimeout(cb, 1000))
    document.write(`<stream-data data-text="${i}">${i.toString()}</stream-data>`)
  }
  document.close()
}

It is pretty much just writing the plain data, but it can be more complicated and provide structural data via the element itself, or it could just pass the json data to data-text. It it nothing like "rendering" though.

What's the good part of this technique ?

The opening lines reach the browser super fast. They are sent immediately upon request received. It leaves no overhead in terms of "TTFB". On a cloudflare pages deploy, browser starts to receive the document in 30ms, and the script in 60ms.
Nearly no computation on server side, compared with a full rendering. The average CPU time per request is 3ms.
JavaScript and data downloads happen in parallel.
The custom element runs on itself. It can render an interactive UI with or without the partially downloaded data before the document itself is complete: and the data would keep downloading during the execution.
Rendering is under full control of the component. Aggressive lazy loading can be easily applied and it can freely decide how the data is used with no overhead, based on client side conditions.
The download size of the document is smaller because plain json is usually smaller than the rendered html.
window.stop can abort the data download process.
The component script can be aggressively cached. The document itself can also be cached, but it is expected to update frequently.
The data is guaranteed fresh so JavaScript won't need another data request.
The document stream can be persistent so it can be reused to push updates.
Search engines can see the data without JavaScript. Or they can execute it and know how the page really looks like.

And what's the bad parts ?

It may not actually be a stream, especially if the user is behind a proxy. The server must be able to detect that, or it will be a disaster if the document is reused for updates.
It requires client side JavaScript support, as a normal custom element.
Always re-render on client side refreshes. It is not a good solution in terms of energy and client side resource efficiency, compared with SSG. But energy efficiency can be complicated.
window.stop is not very convenient.

Q&A

Why an empty custom element like that ?
- To support multiple custom elements on the same page.
- But yes it is trivial to put stream-data inside stream-receiver: remember to use a shadow root and prepare a default style in case the element is rendered before the custom element is ready. You are probably safe if you keep the receiver minimal.
So just inline the receiver ?
- It will block the rest of the stream (but is it really an issue ?). Good idea if it is really small.
Let's make the receiver universal.
- It depends on how you would define "universal". It is more practical to have multiple less universal versions to choose from.
That class Document seems not very useful.
- Feel free to enhance it. It is made minimal on purpose to show the idea.
Reuse the document connection for updates ?
- Not very practical on cloudflare, AWS, and probably most serverless platforms, but trivial on node.js or nginx.
- And if your favicon is a spinning circle.

How good is the shuffleArray from 7-killer-one-liners ?

yw662 — Mon, 14 Feb 2022 21:58:56 +0000

As many of us may like this post about 7-killer-one-liners, we all know that shuffling looks not very promising, compared with the "correct" way, Fisher-Yates and its variants.

const shuffleArray = (arr) => arr.sort(() => Math.random() - 0.5)

But, how bad can it be? Basically it depends on the sorting algorithm. It is usually some kind of intro-sort, with is usually some mixture of quick sort, insertion sort and heap sort. The randomness makes it hard to predict the result. So, let's do some experiments instead.

Firstly it is the shuffle function:

declare global {
  interface Array<T> {
    shuffle: () => T[]
  }
}

Array.prototype.shuffle = function <T>(this: T[]) {
  return this.sort(() => Math.random() - 0.5)
}

export {}

And now we can:

const experiment = (N: number, times?: number) => {
  times = times ?? N ** 2
  const original = [...Array(N).keys()]
  const samples = Array.from(Array(times), () => [...original].shuffle())
}

We now have so many shuffled samples, but how can we assess them ?

Here we gonna calculate the frequency each number may appear on each position.

const NumberPosition = (numbers: number[], samples: number[][]) => {
  return numbers.map(
    n => samples.map(sample => [n, sample.indexOf(n)] as const)
    // (n, k) => samples.map(sample => [sample[k], k] as const)
  ).flat(1)
}

const experiment = (N: number, times?: number) => {
  times = times ?? N ** 2
  const original = [...Array(N).keys()]
  const samples = Array.from(Array(times), () => [...original].shuffle())
  const pairs = NumberPosition(original, samples)
}

Both methods work. The former one seems more "understandable", and we don't care about performance at all.

Here we gonna count the pairs. We need a Map<[number, number], number> for that. But here is a problem:

const m = new Map<[number, number], number>()
m.set([0, 0], 1)
m.set([0, 0], 2)
console.log(m)

> Map(2) { [ 0, 0 ] => 1, [ 0, 0 ] => 2 }

To make things cool, we use a pool, which is a [number, number][][], to keep the reference unique.

  const map = new Map<readonly [number, number], number>()
  const pool = original.map(
    n => original.map((_, k) => [n, k] as const)
  )
  const keyOf = (pair: readonly [number, number]) =>
    pool[pair[0]][pair[1]]
  for (const pair of pairs) {
    const key = keyOf(pair)
    map.set(key, (map.get(key) ?? 0) + 1)
  }

All these as const are there for a reason.

Now we have the stats. We gonna sort it by counts.

  return Array.from(map.entries())
    .sort(([, a], [, b]) => b - a)

Now the whole script looks like:

declare global {
  interface Array<T> {
    shuffle: () => T[]
  }
}

Array.prototype.shuffle = function <T>(this: T[]) {
  return this.sort(() => Math.random() - 0.5)
}

const experiment = (N: number, times?: number) => {
  times = times ?? N ** 2
  const original = [...Array(N).keys()]
  const samples = Array.from(Array(times), () => [...original].shuffle())
  const pairs = original.map(
    n => samples.map(sample => [n, sample.indexOf(n)] as const)
    // (n, k) => samples.map(sample => [sample[k], k] as const)
  ).flat(1)

  const map = new Map<readonly [number, number], number>()
  const pool = original.map(n => original.map((_, k) => [n, k] as const))
  const keyOf = (pair: readonly [number, number]) => pool[pair[0]][pair[1]]
  for (const pair of pairs) {
    const key = keyOf(pair)
    map.set(key, (map.get(key) ?? 0) + 1)
  }
  return Array.from(map.entries()).sort(([, a], [, b]) => b - a)
}

export { }

So now let's try sth easy:

console.table(experiment(3, 65536))

and the result:

┌─────────┬──────────┬───────┐
│ (index) │    0     │   1   │
├─────────┼──────────┼───────┤
│    0    │ [ 1, 1 ] │ 45117 │
│    1    │ [ 2, 2 ] │ 32746 │
│    2    │ [ 0, 0 ] │ 28609 │
│    3    │ [ 0, 2 ] │ 24666 │
│    4    │ [ 2, 0 ] │ 24632 │
│    5    │ [ 1, 0 ] │ 12295 │
│    6    │ [ 0, 1 ] │ 12261 │
│    7    │ [ 2, 1 ] │ 8158  │
│    8    │ [ 1, 2 ] │ 8124  │
└─────────┴──────────┴───────┘

[1, 1] 45117 and [2, 2] 32746 vs [1, 2] 8124 and [2, 1] 8158, That means some elements are more likely to stay where they originally are: and it is 45117/65536, not a very good one.

Let's try a larger array. For larger ones, we care only about first few and last few records, so let's do a filter:

const endN = 4
console.table(
  experiment(40, 100000)
    .filter(
      (_, k, a) => k < endN || a.length - k < endN)
)

┌─────────┬────────────┬──────┐
│ (index) │     0      │  1   │
├─────────┼────────────┼──────┤
│    0    │  [ 0, 0 ]  │ 7031 │
│    1    │  [ 0, 1 ]  │ 6308 │
│    2    │ [ 30, 39 ] │ 4650 │
│    3    │  [ 3, 0 ]  │ 4624 │
│    4    │ [ 1, 37 ]  │ 772  │
│    5    │ [ 1, 38 ]  │ 579  │
│    6    │ [ 1, 39 ]  │ 378  │
└─────────┴────────────┴──────┘

10 times, but it is 0.07, seems better. And it means "there are a possibility of 0.07 that 0 stays on position 0".

Things are kept near where they were, typical insertion sort. This is how intro-sort looks like when N is low.

And a larger one, 1000. I have to do less iterations (down to 10000) or there will be no enough address space for node.js to use.

┌─────────┬──────────────┬────┐
│ (index) │      0       │ 1  │
├─────────┼──────────────┼────┤
│    0    │  [ 441, 0 ]  │ 55 │
│    1    │   [ 0, 4 ]   │ 53 │
│    2    │  [ 315, 1 ]  │ 52 │
│    3    │   [ 0, 3 ]   │ 52 │
│    4    │  [ 252, 2 ]  │ 49 │
│    5    │  [ 0, 10 ]   │ 48 │
│    6    │  [ 0, 13 ]   │ 48 │
│    7    │  [ 63, 4 ]   │ 47 │
│    8    │   [ 0, 9 ]   │ 47 │
│    9    │  [ 189, 3 ]  │ 46 │
│   10    │ [ 190, 999 ] │ 1  │
│   11    │ [ 134, 999 ] │ 1  │
│   12    │ [ 887, 999 ] │ 1  │
│   13    │ [ 946, 999 ] │ 1  │
│   14    │ [ 63, 999 ]  │ 1  │
│   15    │ [ 632, 999 ] │ 1  │
│   16    │ [ 883, 999 ] │ 1  │
│   17    │ [ 71, 999 ]  │ 1  │
│   18    │ [ 889, 999 ] │ 1  │
└─────────┴──────────────┴────┘

No much data but a stable one. 55/10000 is not a very big issue, but 55:1 is still bad.

At the end let's try a real Fisher-Yates and see how good it is:

Array.prototype.shuffle = function <T>(this: T[]) {
  for (let i = this.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [this[i], this[j]] = [this[j], this[i]]
  }
  return this
}

You can tell from above I don't like semis, but I have to keep this one :-).
and

┌─────────┬──────────┬──────┐
│ (index) │    0     │  1   │
├─────────┼──────────┼──────┤
│    0    │ [ 2, 0 ] │ 3370 │
│    1    │ [ 1, 2 ] │ 3369 │
│    2    │ [ 0, 2 ] │ 3360 │
│    3    │ [ 2, 1 ] │ 3359 │
│    4    │ [ 0, 1 ] │ 3344 │
│    5    │ [ 1, 0 ] │ 3334 │
│    6    │ [ 1, 1 ] │ 3297 │
│    7    │ [ 0, 0 ] │ 3296 │
│    8    │ [ 2, 2 ] │ 3271 │
└─────────┴──────────┴──────┘

Looks good.

and 40

┌─────────┬────────────┬──────┐
│ (index) │     0      │  1   │
├─────────┼────────────┼──────┤
│    0    │ [ 39, 11 ] │ 2638 │
│    1    │ [ 11, 11 ] │ 2636 │
│    2    │ [ 38, 34 ] │ 2634 │
│    3    │ [ 4, 36 ]  │ 2633 │
│    4    │ [ 20, 21 ] │ 2348 │
│    5    │ [ 27, 25 ] │ 2348 │
│    6    │ [ 32, 20 ] │ 2345 │
└─────────┴────────────┴──────┘

and 100

┌─────────┬────────────┬──────┐
│ (index) │     0      │  1   │
├─────────┼────────────┼──────┤
│    0    │ [ 74, 70 ] │ 2168 │
│    1    │ [ 55, 2 ]  │ 2167 │
│    2    │ [ 68, 74 ] │ 2164 │
│    3    │ [ 50, 20 ] │ 2157 │
│    4    │ [ 35, 54 ] │ 1830 │
│    5    │ [ 3, 92 ]  │ 1823 │
│    6    │ [ 27, 69 ] │ 1794 │
└─────────┴────────────┴──────┘

The GC becomes unhappy when I increase the size, due to the address space limitation, and I am unhappy to make the code GC friendly :), but this is enough.

A "function type covariance" trap in typescript

yw662 — Sat, 12 Feb 2022 20:06:38 +0000

In JavaScript and TypeScript, functions are generic, which means a:

type f = (...args: [number]) => unknown
// aka: (foo: number) => unknown

is automatically a

type f = (...args: [number, ...any[]]) => unknown

Reasonable. If a function uses only the first few arguments, it is no harm to provide more.

And here come "optional parameters" in TypeScript. No worry in JavaScript since there are no "non-optional parameters":

type g = (foo: number, bar?: number) => unknown

It is also a:

(foo: number) => unknown

Why not? the second parameter is optional, it can be used like that.

So now, a g is also an f.
But wait, remember we have the second form of f:

const H = (h: (foo: number, bar: string) => void) => {
  h(0, '')
}

const F = (f: (foo: number) => void) => {
  H(f)
}

const g = (foo: number, bar?: number) => {
  console.log(bar ?? 0 + foo + 1)
}

F(g)

TypeScript would gladly accept these code even in its most strict type checks, including strictFunctionTypes: a g is an f, we already know that, and an f is an h, we know that too. But is a g also an h ?

That is the question.

We have been using a lot of functional APIs. Array.prototype.map for example, accepts an executor (element, index?, array?) => any, which is practically an element => any.
But if the executor is from somewhere else in the later form, the "g is not h" can be a problem, a problem TypeScript unable to detect:

class Foo<T> {
  private foo: T[]
  ...
  function bar<U>(f: T => U) {
    return this.foo.map(f)
  }
  ...
}

Let's imagine what could happen here.