JSX 4: component name when created without @react.component

[cknitt]

When using JSX 4, it is possible to create a component without @react.component by just creating a module with a props type and a function make: props => React.element. This can be useful in some cases, or even required due to nominal typing if we want to ensure that multiple components share the same props type.

However, if we create a component that way, its name will just be make. For example, when rendering the following component

module A = {
  type props = {}
  let make = (_: props) => React.string("A")
}

module B = {
  type props = {}
  let make = (_: props) => React.string("B")
}

type props = {}

let make = (_: props) =>
  <div>
    <A />
    <B />
  </div>

it looks like this in the React Dev Tools components inspector:

[mununki]

Good catch!
One of the main jobs of @react.component is making the react component function name starting with capitalized letter.

[cknitt]

Right, but how can we support the above use case where the user wants to specify the props type himself? Could we also just add @react.component to the make function, and the PPX would detect this as a different case (as there are no labeled arguments) and make sure that the component function name is set correctly, but do no additional magic?

[cristianoc]

This is still a bit up in the air. You can use the same thing that the ppx does now, and define a capitalized quoted id.

The current situation is that there isn't a nice language level mechanism to cover the complete picture, including the default export normally used by components, and capitalized name.

[cristianoc]

The default is the more delicate aspect, so perhaps worth looking at it in isolation. Making this up as we speak.

So at the language level one wants to have the notion of module with a default value, and this should map nicely to JS's notion of default export.
So at the language level, it could just be that a module has a value called default.
This would mean different things whether the module is an inner module or a file. In the case of inner module, it would be literally just a value called default. Represented in a way that does not make JS unhappy so some mangling of the name as currently done by the compiler.
In the case of a file, it would be whatever the current module (from bsconfig) notion of default export, and access mean. So what's generated could be accessed from JS, without any change.
In terms of JSX, the name make would be dropped in favour of default.

Some implicit convention, or explicit mechanism, could be used to give the name of the module to the default value.

[cristianoc]

Treating inner modules and files differently is a bit of a complication, when e.g. functors are used. One can explore several things.
One possibility is to also take on another issue: the fact that Foo.bar might or might not access a local module, depending on what's in scope.
If one were to separate local module access, from file access, then that would be a clean separation point where to reconcile things like treatment of default, as well as making dependencies more explicit and not dependent on what's in scope (opened modules).

Needless to say, this is very speculative and not for the short term for sure.

[cristianoc]

Combining with the exploration of dynamic import

// Counter.res has @react.component let default = ...

...
   module C = await import(Counter)
   <C .../>
...

[cknitt]

IMHO we should support the use case of the user specifying a (possibly shared) props type himself out of the box with the upcoming JSX 4 release.

Yes, the user could do something like this manually to get the right component function name, but this is quite cumbersome:

type sharedProps = {x: string}

module A = {
  type props = sharedProps

  let make = {
    let \"A" = ({x}) => React.string("A: " ++ x)
    \"A"
  }
}

Why can't we extend the PPX so that we can have

type sharedProps = {x: string}

module A = {
  type props = sharedProps

  @react.component
  let make = ({x}) => React.string("A: " ++ x)
}

and the PPX does just the function name thing in this case?

[cristianoc]

IMHO we should support the use case of the user specifying a (possibly shared) props type himself out of the box with the upcoming JSX 4 release.

Yes, the user could do something like this manually to get the right component function name, but this is quite cumbersome:

type sharedProps = {x: string}

module A = {
  type props = sharedProps

  let make = {
    let \"A" = ({x}) => React.string("A: " ++ x)
    \"A"
  }
}

Why can't we extend the PPX so that we can have

type sharedProps = {x: string}

module A = {
  type props = sharedProps

  @react.component
  let make = ({x}) => React.string("A: " ++ x)
}

and the PPX does just the function name thing in this case?

This is doable, probably requiring some additional annotation (e.g. an argument to @react.component).

[cristianoc]

Though I would not change the syntax, still (~x) => ...

[cknitt]

What I meant was that I can already write

module A = {
  type props = sharedProps
  let make = ({x}) => React.string("A: " ++ x)
}

now and it will work without any additional attribute, except for the incorrect function name. So I wanted to add an attribute (whether the existing @react.component or a new one) that just sets the function name to the module name. In this case there would be no labeled arguments.

You are proposing something like this instead, right?

module A = {
  @react.component(sharedProps)
  let make = (~x) => React.string("A: " ++ x)
}

where the @react.component would work as usual with the labeled args, but use the provided props type?

[mununki]

Using argument for @react.component to make quoted id for make function of react component is bit easy job. Or let’s say @react.componentName seperately.
But I want to explore what @cristianoc says about module. It can resolve the dynamic import for module either.

[mununki]

// @react.component
module A = {
  @react.component
  let make = (~x, ~y) => React.string(x ++ y)
}

// @react.componentName
module B = {
  type props = {x: string, y: string}
  @react.componentName
  let make = props => React.string(props.x ++ props.y)
}

// No attributes
module C = {
  type props = {x: string, y: string}
  let make = props => React.string(props.x ++ props.y)
  let make = {
    let \"C" = (props: props) => make(props)
    \"C"
  }
}

[cristianoc]

This variation might actually work.

The ReScript

// Foo.res
let default = 3

Could compile to this JS:

// Foo.js
let Foo = 3
export default Foo

So default would be represented at runtime with the name of the enclosing module. The same rule can apply to files and inner modules, so there's no inconsistency.

This should respect the rule of a single capitalised export where needed.

[cknitt]

Nice! But then we would need to change JSX to use default instead of make?

[cristianoc]

Yes a rename would be necessary. Can be done incrementally helped by config settings, in case this works out without issues.