Explore how to implement the ergonomic dynamic import

[mununki]

Related #5593

• Emit the inlined js module path instead of import statement in the header

---

Thanks to JSX v4, now we can write the dynamic import for react component:

// LazyComp.res
@react.component
let make = (~x) => React.string(x)

// App.res
@val external import: 'a => Js.Promise.t<'a> = "import"
type option = {ssr?: bool}
@val external dynamic: (unit => Js.Promise.t<'a>, option) => 'a = "dynamic"

module L = {
  let make = dynamic(() => import(LazyComp.make), {ssr: false})
}

<L x="lazy" />

This example passes the type checker as we intended, but the import statement in js output should be emitted differently.

As-is:

import * as LazyComp from "./LazyComp.bs.js";

var make = dynamic((function (param) {
        return import(LazyComp.make);
      }), {
      ssr: false
    });

To-be:

// omit the import statement
var make = dynamic((function (param) {
        return import("./LazyComp.bs.js"); // <-- inlined
      }), {
      ssr: false
    });

[cristianoc]

Is this the (or a) idiomatic way to dynamically load a component?
return import("./LazyComp.bs.js")

[cristianoc]

Looking randomly at TS resources, here's an example:

async function renderWidget() {
  const container = document.getElementById("widget");
  if (container !== null) {
    const widget = await import("./widget");
    widget.render(container);
  }
}

renderWidget();

Looks like pretty much the same example should be expressible.
Which means, the magic would be in the treatment of import which would need to be provided by the compiler, e.g. Js.import or something.

[cristianoc]

I guess Js.import or however it's called, would take a value, under some restrictions, figure out where it is, and emit a dynamic import instruction.

[cristianoc]

@mattdamon108 just a high level brain dump here.
A couple of discrepancies so far:

• dynamic import is about modules/files, not values
• dynamic import conceptually only belongs in an async context

Making up random syntax etc, but this is how I would imagine the mechanism should instead behave at a high level:

let foo = async (x) => {
  switch x {
  | A =>
    module Lib = await LibA // dynamically load module LibA
    Lib.someFunction("aaa")
  | B =>
    module Lib = await LibB // dynamically load module LibB
    Lib.someFunction("bbb")
  }
}

[mununki]

dynamic import is about modules/files, not values

If we're going to implement import not only for react component but also for general purpose, yes it is correct that import is about modules and files not values.

dynamic import conceptually only belongs in an async context

Why should import only belong in an async context?

[mununki]

Is it valid?

let foo = () => {
  let m = LibA
  m
}

[mununki]

How about this without the constraint of being inside async context?

// in async context
let foo = async (x) => {
  switch x {
  | A =>
    module Lib = await @import LibA // dynamically load module LibA
    Lib.someFunction("aaa")
  | B =>
    module Lib = await @import LibB // dynamically load module LibB
    Lib.someFunction("bbb")
  }
}

// not in async
let foo = (x) => {
  switch x {
  | A =>
    let ma = @import LibA // dynamically load module LibA
    ma
  | B =>
    let mb = @import LibB // dynamically load module LibB
    mb
  }
}

[cristianoc]

First try to fix your initial example. The code does not extract make.
Then look at the result.

[mununki]

Yes, it doesn't extract make, because the module doesn't have an export default.

[mununki]

Do we have a feature to make an export default BTW?

@default let m = comp // something like?

[cristianoc]

Do we have a feature to make an export default BTW?

@default let m = comp // something like?

That's a separate question.
It's nice when you have it, but you can't assume.

It's "let default = ..."

[cristianoc]

Yes, it doesn't extract make, because the module doesn't have an export default.

Let's consider the case where make needs to be extracted, which is a common case at the moment.
Can you try to write a fix for the generated code for the initial example at the top of this issue, see how it looks like?

[cristianoc]

How about this without the constraint of being inside async context?

// in async context
let foo = async (x) => {
  switch x {
  | A =>
    module Lib = await @import LibA // dynamically load module LibA
    Lib.someFunction("aaa")
  | B =>
    module Lib = await @import LibB // dynamically load module LibB
    Lib.someFunction("bbb")
  }
}

// not in async
let foo = (x) => {
 switch x {
 | A =>
   let ma = @import LibA // dynamically load module LibA
   ma
 | B =>
   let mb = @import LibB // dynamically load module LibB
   mb
 }
}

The second example tries to assign a module to a value variable ma or mb. That's not part of the language. (One can look at first-class modules, though they are quite complex and need an explicit signature).
Also, not clear if it returns a promise or not. If it does not, then you just lost the ability to control when the module is loaded, from the point of view of the caller of foo.

[mununki]

Let's consider the case where make needs to be extracted, which is a common case at the moment. Can you try to write a fix for the generated code for the initial example at the top of this issue, see how it looks like?

Sure, I'll.
My intention was import(Foo.make) helps to infer the props type of react component. Now I realize that import(Foo.make) doesn't match the semantic against js import.

[cristianoc]

Let's consider the case where make needs to be extracted, which is a common case at the moment. Can you try to write a fix for the generated code for the initial example at the top of this issue, see how it looks like?

Sure, I'll. My intention was import(Foo.make) helps to infer the props type of react component. Now I realize that import(Foo.make) doesn't match the semantic against js import.

The point I'm trying to make is that if the generated code needs to extract make, then it needs to extract it from a promise, and presumably package it back into a promise.