Skip to content

Wire to JSX PPX V4 and introduce Jsx* modules #5484

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Jul 21, 2022

Conversation

mununki
Copy link
Member

@mununki mununki commented Jun 27, 2022

Wire to JSX PPX V4

Companion PR in the syntax repo: rescript-lang/syntax#614

  • Add the new configuration in bsconfig.json
"react": {
  "jsx": 4,
  "mode": "react",
  "runtime": "automatic"
}
  • Add cli options to wire to the JSX PPX

Introduce Jsx* modules

  • WIP: Add Js.React for the new jsx transform binding Add Jsx module for the primitive types and bindings
    • Add JsxDOM with type domProps
    • Add JsxDOMStyle
    • Add JsxEvent

@mununki mununki changed the title JSX PPX V4 Wire to JSX PPX V4 Jun 27, 2022
match flo with
| "3" -> default := Some Jsx_v3
| "4" -> default := Some Jsx_v4
| _ -> Bsb_exception.errorf ~loc "Unsupported react-jsx %s" flo)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Unsupported jsx version"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed 81029b3

@mununki mununki mentioned this pull request Jun 29, 2022
13 tasks
@ryyppy
Copy link
Member

ryyppy commented Jun 29, 2022

Kinda related: is this the time where we could think about moving out of the react config namespace? I never liked that category name, since it didn't make sense from a config hierarchy perspective.

My ideal world would show something like

"jsx": {
  "version": 4,
  "jsxModule": "Jsx",
  "mode": "preserve"
  // etc
}

The original react namespace should stay for backwards compat of course, so this would require some errors when a user defined both configs.

@mununki
Copy link
Member Author

mununki commented Jun 29, 2022

Kinda related: is this the time where we could think about moving out of the react config namespace? I never liked that category name, since it didn't make sense from a config hierarchy perspective.

My ideal world would show something like

"jsx": {
  "version": 4,
  "jsxModule": "Jsx",
  "mode": "preserve"
  // etc
}

The original react namespace should stay for backwards compat of course, so this would require some errors when a user defined both configs.

It looks good to me. What are the values available for jsxModule anyway?

@mununki mununki closed this Jun 29, 2022
@mununki mununki reopened this Jun 29, 2022
@mununki
Copy link
Member Author

mununki commented Jun 29, 2022

I’m going to remove the Js.React module which was for the test flight of ppx v4.

@ryyppy
Copy link
Member

ryyppy commented Jun 30, 2022

It looks good to me. What are the values available for jsxModule anyway?

If technically possible, it should be any value.

As an example: jsxModule: "React" would require me to have a global React module available in my build.
Or it could be something completely different, like "MyCoolJsx".

@cometkim
Copy link
Member

Many JS frameworks other than React use JSX today.

Preact uses jsx pragma with "h" func: https://preactjs.com/guide/v8/getting-started/#global-pragma

Vue also uses "h": https://vuejs.org/guide/extras/render-function.html#JSX

Emotion uses "jsx": https://emotion.sh/docs/css-prop#jsx-pragma

Theme-UI guides user to customize "jsxImportSource" option: https://theme-ui.com/guides/jsx-pragma/

Btw in case of Emotion/Theme-UI, it allows additional dom props in the file, which is challenging in ReScript I guess

@mununki
Copy link
Member Author

mununki commented Jul 3, 2022

Kinda related: is this the time where we could think about moving out of the react config namespace? I never liked that category name, since it didn't make sense from a config hierarchy perspective.

My ideal world would show something like

"jsx": {
  "version": 4,
  "jsxModule": "Jsx",
  "mode": "preserve"
  // etc
}

The original react namespace should stay for backwards compat of course, so this would require some errors when a user defined both configs.

81029b3 I've changed the build schema for bsconfig as suggested.

"jsx": {
  "version": 4,
  "module": "react",
  "mode": "automatic", 
}

Actually, "module" has to be "react" only for now. "mode" is enum type which has classic, automatic. classic is for backward compatibility, automatic is for the new jsx transform for react. This configuration seems quite flexible to support other JSX libraries or frameworks in the future.

@cristianoc
Copy link
Collaborator

cristianoc commented Jul 3, 2022

How does one turn on V4? I guess using the new "jsx" config?
That seems good to me.

@cristianoc
Copy link
Collaborator

Why the name "module". Not a big deal but maybe there's a better name?
Framework or something familiar to the user.

@mununki
Copy link
Member Author

mununki commented Jul 3, 2022

How does one turn on V4? I guess using the new "jsx" config? That seems good to me.

Yes, "jsx" turns the V4 on.

@mununki
Copy link
Member Author

mununki commented Jul 3, 2022

Why the name "module". Not a big deal but maybe there's a better name? Framework or something familiar to the user.

That was from the "jsxModule" which was in Patrick's comment. It means the value of jsxModule is activated through the build system. Therefore it makes sense to me in a way that the "module" is activated. Sure, we can consider another better name for it.

(match (has_reason_react_jsx, reason_react_jsx) with
| false, _ | _, None -> ()
| _, Some Jsx_v3 -> Ext_buffer.add_string buf " -bs-jsx 3");
(match (has_reason_react_jsx, reason_react_jsx, jsx_version) with
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first value is never used.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, I'll remove it

@@ -30,6 +30,7 @@ let rewrite_signature (ast : Parsetree.signature) : Parsetree.signature =
let ast =
match !Js_config.jsx_version with
| 3 -> Reactjs_jsx_ppx_v3.rewrite_signature ast
| 4 -> Reactjs_jsx_ppx_v4.rewrite_signature !Js_config.jsx_mode ast
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style: perhaps use a labeled argument ~jsx_mode here as first argument to Reactjs_jsx_ppx_v4.rewrite_signature.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it!

@cristianoc
Copy link
Collaborator

Can you rebase this and point it to the latest syntax PR?
Difficult to test the syntax PR otherwise.

@mununki
Copy link
Member Author

mununki commented Jul 19, 2022

Rebased to master

@cristianoc
Copy link
Collaborator

cristianoc commented Jul 19, 2022

Looks like it's not pointing to the correct syntax commit. Or some code needs changing.

@cristianoc
Copy link
Collaborator

File "jscomp/frontend/ppx_entry.ml", line 38, characters 8-41:
Error: Unbound module Reactjs_jsx_ppx
Hint: Did you mean Reactjs_jsx_ppx_v3 or Reactjs_jsx_ppx_v4?

@cristianoc
Copy link
Collaborator

I guess for adding the syntax repo commit here, it's necessary that the syntax PR is done on a branch of the syntax repo, not on a fork. You should be able to do that now.

@mununki
Copy link
Member Author

mununki commented Jul 19, 2022

I guess for adding the syntax repo commit here, it's necessary that the syntax PR is done on a branch of the syntax repo, not on a fork. You should be able to do that now.

Got your invitation, I'll make a branch for V4 in the syntax repo, not from my forked repo, then point to the commit of it.

@mununki
Copy link
Member Author

mununki commented Jul 19, 2022

I guess for adding the syntax repo commit here, it's necessary that the syntax PR is done on a branch of the syntax repo, not on a fork. You should be able to do that now.

I think I've done it.

@cristianoc
Copy link
Collaborator

Done a bit of undocumented black magic to fix CI. Let's see if it works.

@cristianoc
Copy link
Collaborator

OK CI all green now.

@mununki mununki mentioned this pull request Jul 21, 2022
@cristianoc
Copy link
Collaborator

Would you merge this on top of master, which already contains the syntax update?

@cristianoc
Copy link
Collaborator

In terms of functionality, can this be merged?
If yes, I could do one pass of deeper review.

@mununki
Copy link
Member Author

mununki commented Jul 21, 2022

In terms of functionality, can this be merged? If yes, I could do one pass of deeper review.

Yes, I think it is ready to be merged. Let me rebase on top of master.

@mununki
Copy link
Member Author

mununki commented Jul 21, 2022

I've pushed this PR branch to upstream mistakenly, you can ignore or delete it. I was confused where this PR branch belongs to. 😓 I've pushed to my forked repo(origin), and this PR seems updated okay.

@cristianoc cristianoc merged commit 1eb6415 into rescript-lang:master Jul 21, 2022
@mununki mununki deleted the jsx-ppx-v4 branch July 21, 2022 07:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants