The reason-react library is already closely tied to the ReScript ecosystem as the syntax for JSX and for creating new components ships with the rest of ReScript. To better reflect this close relationship we are planning that the 1.0 release of reason-react will be under a new name: rescript-react.
Aside from the name change, there are a couple explicit goals in this breaking change: full support for aria and data attributes, better performance when working with lowercase JSX elements (like
<div />), support for exporting the props type of a component, and cleaning up many modules that have been deprecated since the last breaking change.
After some initial discussions it seems to make sense to break this into a couple steps:
This is a smaller change that mostly handles the actual name change. It will remove all deprecated/legacy modules and will rename all uses of ReasonReact. In order to upgrade, users will need to:
- Remove all uses of modules listed under the legacy folder in reason-react. This includes ReasonReact, ReasonReactCompat, ReactDOMRe, and more (you can see the modules in the /legacy folder of reason-react today).
- Remove reason-react from your project and add rescript-react
a. ReasonReactRouter -> RescriptReactRouter
b. ReasonReactErrorBoundary -> RescriptReactErrorBoundary
A larger change more centered on the ppx - adding support for
React.jsx/s, full support of aria spec and data- attributes in JSX, moving a lot of checks for valid DOM nodes from the type checker into the ppx to improve compilation speed, cleanup of key and ref handling, and a new feature to export the type of your props from a module with a component in it. In order to make this upgrade, you would need to:
- Bump jsx version in bsconfig from 3 to 4
a. Make sure you have react and react-dom >=17 as a npm dependency
- This could break existing code in a couple ways that need fixing:
a. You have a component made with @react.component and then you call it without JSX and while using a
keyin props. JSX 4 removes the key from every props list because key isn’t really a prop - it’s an external mechanism React uses to track relationships between elements. In this case you’ll need to move to the JSX call for that component and it should work fine.
b. Some aria props have been moved from an open string to a variant of all possible cases. If this is the case you might have an aria value like “mixed” which needs to be migrated to #mixed
- You might have different methods for attaching aria or data attributes to React elements. These can be deprecated in favor of attaching them directly in the jsx:
<div ariaHidden=true \"data-secret"="true" />
Does this approach make sense? Any thing that’s missing and needs to be addressed?