JSX Preserve Mode

[mununki]

I would like to initiate a discussion on a potential feature: Preserve Mode for JSX expressions. The Preserve Mode is a functionality that, when enabled, maintains the original formatting and structure of JSX expressions in the JavaScript output generated by the compiler.

As the ReScript ecosystem evolves, it is worth exploring whether introducing Preserve Mode for JSX expressions to the compiler would be beneficial for the community. This feature could potentially enhance the readability and maintainability of the compiled output containing JSX, making it easier for developers to work with and understand the generated code. Another significant advantage of Preserve Mode is the possibility of using ReScript with frameworks like Preact and SolidJS, expanding the reach and applicability of the language.

Please share your thoughts and experiences regarding the necessity and potential benefits of implementing Preserve Mode for JSX expressions in the ReScript compiler. Do you think it is a valuable addition, or are there any concerns or technical challenges that might arise from its implementation?

@react.component
let make = () => {
  let (user, setUser) = React.Uncurried.useState(_ => "mununki")

  <div>
    <p> {`${user} uses ReScript`->React.string} </p>
    <input value=user onChange={e => setUser(._ => (e->JsxEventC.Form.target)["value"])} />
  </div>
}

preserved JSX

function Preserve(props) {
  var match = React.useState(function (param) {
    return "mununki";
  });
  var setUser = match[1];
  var user = match[0];
  return (
    <div>
      <p> user + " uses ReScript" </p>
      <input
        value={user}
        onChange={function (e) {
          setUser(function (param) {
            return e.target.value;
          });
        }}
      />
    </div>
  );
}

[mununki]

Related: rescript-lang/syntax#539, rescript-lang/syntax#613

[cornedor]

Another significant advantage of Preserve Mode is the possibility of using ReScript with frameworks like Preact and SolidJS, expanding the reach and applicability of the language.

This would be very nice to have to build server side apps. The Bun JS runtime has built-in JSX support, and using libraries like https://github.com/nicojs/typed-html or https://github.com/kitajs/html you could render static HTML and serve it from the server without the need for more complicated SSR setups like Next.JS.

[zth]

@cornedor unrelated to this specific issue, but since you wrote this - I'm working on something like this, but without JSX preserve mode and just using ReScript's built in JSX support. Server side templating but with JSX and components like in React. Soon ready for alpha.

[Diogenesoftoronto]

I would love to see rescript be used with solidjs. If it's possible to get this done, I am willing to work on a PR if the maintainers are for it.

[texastoland]

Theoretically closed by #6565 (from announcement).

[mununki]

Theoretically closed by #6565 (from announcement).

I don't think it is. 😉 There will be cases where the generic transformation is not enough to solve.

[texastoland]

There will be cases where the generic transformation is not enough to solve.

Example would be helpful for others like me following 🙏🏼

[zth]

@texastoland for Solid the issue is that Solid ships their own Babel transform, that turns actual JSX into <template> tags. So while the generic JSX transform does allow us to bind to Solid h functions, those can't be transformed using their Babel transform, since that's looking for JSX specifically, and the JSX transform has already turned the ReScript JSX into actual function calls.

Hope that helps!

[cknitt]

Preserve mode seems to be required for React Compiler (as of today at least).
See reactwg/react-compiler#22.

[nojaf]

I'm a bit stumped on how this could be implemented. To get started, I’m going to jot down some thoughts and questions:

Assuming you want to preserve the JSX, I would expect the ppx transform not to activate. This means that new Pexp_jsx_element would need to be carried through the type-checking phase. During that phase, we would still need to validate that props and children have the correct types.

After type-checking, some additional processes occur (optimizations, lambdas), but I assume nothing significant would happen there. Finally, we would print the typed JSX node back to JSX text in the js_printer.

@cristianoc, would that be more or less what needs to happen?

[zth]

Is there a way to annotate what's produced by the JSX transform so that we can follow it all the way to what actually emits this code:

JsxRuntime.jsx("div", {
  className: "123"
})

And then match on that to produce JSX instead of the function call?

[nojaf]

That feels a bit messy, as you transformed items only to transform them back later. Yes, we could potentially add an additional attribute to mark the JSX transform; however, I'm not sure this is necessary. It might also capture some React semantics that we may want to keep more agnostic.

[cristianoc]

Whether the jsx transform can be moved to later phases in the compiler is a good question, I think.
Kind of a warm up question to what needs to be done for preserve mode anyway.
At least up to where type checking happens, there's no reason to perform the transform.
Branching after type checking makes sense, and I suspect might not require many changes to bring the jsx nodes all the way to the code generation.

[nojaf]

Latest attempt can be found over at #7387.
See output example.

[nojaf]

Hello,

During the ReScript Retreat, we achieved an initial (rough) version of preserving JSX code in the JavaScript output. This is not the final version we plan to ship in v12, and we welcome your feedback to determine its viability and identify any remaining gaps.

Installation

You will need the latest v12 version from the master branch of the compiler. Install it via the pkg.pr URL:

npm i https://pkg.pr.new/rescript-lang/rescript@362a1da

In your rescript.json:

{
  "suffix": ".res.jsx",
  "jsx": {
    "version": 4
  },
  "bsc-flags": [
    "-bs-jsx-preserve"
  ]
}

The suffix is optional; you can choose to use the .jsx extension or not based on your use case. The -bs-jsx-preserve flag will likely be moved to a dedicated setting under the jsx node.
⚠️ You need both jsx.version: 4 and -bs-jsx-preserve.

Known Limitations and Open Questions

We are aware of several limitations, and depending on your feedback, we will address them:

• The JSX output is not formatted neatly. Props are displayed on the same line, and children are not indented.
• Currently, all files share the same extension. Changing to .jsx might seem unusual if your file doesn’t contain any React components. In large projects, this may be mitigated by using preserve mode only for specific packages in the mono repo.
• There may still be some edge-case bugs in the JSX output; please report any you encounter!

React Compiler

I tried this in my own project and can confirm that the React compiler worked as expected.

Solid

This new feature should enable the use of Solid. We haven't tested this yet, so we would welcome a community sample!

[nojaf]

Hi folks,

There's still some UX work to be done here. Currently, the bsc-flag isn't the most user-friendly way to expose this new setting.

Initially, we considered adding a boolean to the jsx node for preservation:

"jsx": {
    "version": 4,
    "preserve": true
},

This approach works, but some tooling scenarios will require the *.jsx extension. You can configure "suffix" to address this, but it's an all-or-nothing configuration. Using that option can feel odd when a non-React-related file has the .jsx extension.

Should we address this? What do people think? Perhaps this isn’t a significant issue for most.

One possible solution could be to have something like this:

"jsx": {
  "preserve": ".jsx" // or any other suffix you prefer.
}

This would allow us to use that extension if we detect a JSX transform we want to preserve.

Please let us know your thoughts!

[cristianoc]

Hi folks,

There's still some UX work to be done here. Currently, the bsc-flag isn't the most user-friendly way to expose this new setting.

Initially, we considered adding a boolean to the jsx node for preservation:

"jsx": {
    "version": 4,
    "preserve": true
},

This approach works, but some tooling scenarios will require the *.jsx extension. You can configure "suffix" to address this, but it's an all-or-nothing configuration. Using that option can feel odd when a non-React-related file has the .jsx extension.

Should we address this? What do people think? Perhaps this isn’t a significant issue for most.

One possible solution could be to have something like this:

"jsx": {
  "preserve": ".jsx" // or any other suffix you prefer.
}

This would allow us to use that extension if we detect a JSX transform we want to preserve.

Please let us know your thoughts!

Could the compiler determine when preserve mode is active and used, on a file, and emit the .jsx extension for that file? Not sure what would be involved in that, and whether the suffix is determined much earlier than that at the moment (particularly when the said file is used by another one).

[nojaf]

Could the compiler determine when preserve mode is active and used

We could set some global-ish flag if we detected something in the jsx ppx transform.
The AST would certainly have this information, perhaps we store it in the *.ast file as well.
I'm not sure about the implications of other files.