JSX preserve mode: `make` is not a valid component name

[cknitt]

Consider a module Test.res with the following code:

let context = React.createContext(0)

module ContextProvider = {
  let make = React.Context.provider(context)
}

@react.component
let make = (~children) => {
  <ContextProvider value=42> {children} </ContextProvider>
}

Without JSX preserve mode enabled, the compiler output is (correct):

function Test(props) {
  return JsxRuntime.jsx(make, {
    value: 42,
    children: props.children
  });
}

With JSX preserve mode:

function Test(props) {
  return <make value={42}>
  {props.children}
  </make>;
}

However, make is not a valid React component name as it is not uppercase.

[nojaf]

Hmm, the current React create context approach feels like a departure from the norm. It seems more like a workaround than a suitable solution.

React.createContext(0) should create a module with Provider and Consumer, but React.Context.provider returns a component definition.

To better fit into the existing component flow, it could be structured like this:

let context = React.createContext(0)

module ContextProvider = {
  @react.componentWithProps("Context")
  let make = props =>
    // Use React.jsxs or React.jsxKeyed accordingly
    React.jsx(context->React.Context.Provider, props)
}

module Foo = {
  @react.component
  let make = (~children) => {
    <ContextProvider value=42> {children} </ContextProvider>
  }
}

I'm not sure if this is worth fixing. I believe it should be addressed at its root; the functionality of createContext should be different, in my opinion.

[nojaf]

Something along these lines would fit the current flow better:

module MakeContext = (
  T: {
    type value
    let value: value
  },
) => {
  %%private(let context = React.createContext(T.value))

  module Consumer = {
    @send
    external consumer: (
      React.Context.t<T.value>,
      JsxDOM.domProps,
    ) => React.element = "Consumer"

    let make = {
      let \"Consumer" = props => consumer(context, props)
      \"Consumer"
    }
  }

  module Producer = {
    @send
    external producer: (
      React.Context.t<T.value>,
      React.Context.props<T.value>,
    ) => React.element = "Producer"

    let make = {
      let \"Producer" = props => producer(context, props)
      \"Producer"
    }
  }
}

module MyContext = MakeContext({
  type value = int
  let value = 0
})

module Bar = {
  @react.component
  let make = (~children) => {
    <MyContext.Producer value=42> {children} </MyContext.Producer>
  }
}

[cknitt]

Hmm, the current React create context approach feels like a departure from the norm. It seems more like a workaround than a suitable solution.

React.createContext(0) should create a module with Provider and Consumer, but React.Context.provider returns a component definition.

That may be a better/more idiomatic API. Also note this change in React 19 BTW: https://react.dev/blog/2024/12/05/react-19#context-as-a-provider

However, even with different context bindings, couldn't there be other similar situations where one ends up with <make ... />?

[cknitt]

E.g., simple case, when not using the PPX transform:

module X = {
  type props = {}
  let make = (_props: props) => React.null
}

@react.component
let make = () => <X />

compiling to

function make(_props) {
  return null;
}

let X = {
  make: make
};

function Test(props) {
  return <make/>;
}

let make$1 = Test;

Is emitting make instead of X.make here maybe an optimization that could somehow be disabled in this case (within JSX)? @cristianoc

[cknitt]

A workaround for the above problem is to always use @react.componentWithProps when not using @react.component.

But I still think we need a proper fix.

Another case where it occurs is when using React.memo following this pattern:

module A = {
  @react.component
  let make = (~a) => React.string(a)

  let make = React.memo(make)
}

@react.component
let make = () => <A a="test" />

producing

function Test(props) {
  return <make
    a={"test"}
  />;
}

Is emitting make instead of X.make here maybe an optimization that could somehow be disabled in this case (within JSX)? @cristianoc

@cristianoc Do you have an idea how we could prevent this?

[cristianoc]

A workaround for the above problem is to always use @react.componentWithProps when not using @react.component.

But I still think we need a proper fix.

Another case where it occurs is when using React.memo following this pattern:

module A = {
@react.component
let make = (~a) => React.string(a)

let make = React.memo(make)
}

@react.component
let make = () =>
producing

function Test(props) {
return <make
a={"test"}
/>;
}

Is emitting make instead of X.make here maybe an optimization that could somehow be disabled in this case (within JSX)? @cristianoc

@cristianoc Do you have an idea how we could prevent this?

Not sure

[cometkim]

The easiest fix is probably emitting an alias where the code uses jsx.

import { make } from "./Component.res.js"

var Component$1 = make;

// and further optimization
import { make as Component$1 } from "./Component.res.js"

[nojaf]

Any pointers on how to do that? It would be nice if we could indeed alias to something uppercase.