Skip to content

Merge type domProps and type props in JsxDOM #5706

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 1 commit into from
Oct 1, 2022

Conversation

mununki
Copy link
Member

@mununki mununki commented Sep 29, 2022

This PR is to merge two props type for dom element into one. type JsxDOM.domProps and type JsxDOM.props has only difference which is ref type. The ref: domRef => unit is for the callback refs which was recommended in the earlier release of React 16.3. Furthermore, JSX ppx v3 and v4 don't use type props anymore.

@cristianoc
Copy link
Collaborator

When is this expected to land? In the next 10.1 release?
If so it should go the the 10.1 branch first. (Then cherry-picked later to master).

@mununki
Copy link
Member Author

mununki commented Sep 29, 2022

I expect that it depends on how the tests are going. Let me run on a larger project, then how about another round of test from the forum?

@mununki
Copy link
Member Author

mununki commented Sep 29, 2022

Should be consideredreviewed with rescript-lang/syntax#665

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

This will be the breaking change against the ReactDOM.domProps https://github.com/rescript-lang/rescript-compiler/blob/e8ccf3c1437882865b021bf65f12b380718ae825/jscomp/others/jsxDOM.ml#L288

method seems the reserved keyword in OCaml, anyhow avoiding the breaking?

@cristianoc
Copy link
Collaborator

This will be the breaking change against the ReactDOM.domProps

https://github.com/rescript-lang/rescript-compiler/blob/e8ccf3c1437882865b021bf65f12b380718ae825/jscomp/others/jsxDOM.ml#L288

method seems the reserved keyword in OCaml, anyhow avoiding the breaking?

Can you write this file in .res?

@cristianoc
Copy link
Collaborator

cristianoc commented Sep 30, 2022

Also how about aria props, do they work with record representation? Better test them.

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

This will be the breaking change against the ReactDOM.domProps
https://github.com/rescript-lang/rescript-compiler/blob/e8ccf3c1437882865b021bf65f12b380718ae825/jscomp/others/jsxDOM.ml#L288

method seems the reserved keyword in OCaml, anyhow avoiding the breaking?

Can you write this file in .res?

💡💡💡

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

When is this expected to land? In the next 10.1 release?
If so it should go the the 10.1 branch first. (Then cherry-picked later to master).

I'll cherry-pick and make the base to master 10.1 branch.

@mununki mununki changed the base branch from master to 10.1_release September 30, 2022 11:54
@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

Cherry-picked and rebased to 10.1_release

/* accessibility */
/* https://www.w3.org/TR/wai-aria-1.1/ */
/* https://accessibilityresources.org/<aria-tag> is a great resource for these */
/* [@optional] [@as "aria-current"] ariaCurrent: page|step|location|date|time|true|false, */
Copy link
Collaborator

Choose a reason for hiding this comment

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

Want to update the stuff in comments too?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, I will.
What was history left aria-* as comment?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Not sure why it is a comment.
And not sure why things are in multiple clusters of things where each cluster is in alphabetical order.

Copy link
Member Author

Choose a reason for hiding this comment

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

5b2554f uncomment.

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Collaborator

@cristianoc cristianoc left a comment

Choose a reason for hiding this comment

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

Just a comment on comments.

@cristianoc
Copy link
Collaborator

There are a few more things that are keywords only in OCaml. Perhaps provide also the version without underscore?

  • begin
  • end
  • to

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

Something weird. I uncommented ariaCurrent?: [#page | #step | #location | #date | #time | #"true" | #"false"], then I ran on the example project, it builds failed.

let _ = ReactDOM.createDOMElementVariadic("div", ~props={ariaCurrent: #page}, [])
// The field ariaCurrent does not belong to type JsxDOM.domProps

@cristianoc
Copy link
Collaborator

Something weird. I uncommented ariaCurrent?: [#page | #step | #location | #date | #time | #"true" | #"false"], then I ran on the example project, it builds failed.

let _ = ReactDOM.createDOMElementVariadic("div", ~props={ariaCurrent: #page}, [])
// The field ariaCurrent does not belong to type JsxDOM.domProps

"make lib" locally

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

"make clean" -> "npm install" -> "make lib"

a7ae475 I guess that JsxDOM.js should not suppose to be removed.
I have to go now, I'll be back in a couple of hours. I'll retry it.

@cristianoc
Copy link
Collaborator

@mattdamon108 there's a problem. Added commit to also build .res files in others/. The problem is that build dependencies are determined using ocamldep, which only works for .ml files. This means that jsxDom.res will have build errors.

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

@mattdamon108 there's a problem. Added commit to also build .res files in others/. The problem is that build dependencies are determined using ocamldep, which only works for .ml files. This means that jsxDom.res will have build errors.

Should I revert to .ml back?

@cristianoc
Copy link
Collaborator

@mattdamon108 there's a problem. Added commit to also build .res files in others/. The problem is that build dependencies are determined using ocamldep, which only works for .ml files. This means that jsxDom.res will have build errors.

Should I revert to .ml back?

Probably.
The alternative would be to hack ad-hoc the build system by making that file build last. But then the next change is going to be hairy.
Or find some other build method, which is going to take a while.
Or, move this outside the compiler into rescript-react.

@cristianoc
Copy link
Collaborator

Or, to make jsxDom.res self-contained file that does not depend on anything. Is it possible?

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

@mattdamon108 there's a problem. Added commit to also build .res files in others/. The problem is that build dependencies are determined using ocamldep, which only works for .ml files. This means that jsxDom.res will have build errors.

Should I revert to .ml back?

Probably. The alternative would be to hack ad-hoc the build system by making that file build last. But then the next change is going to be hairy. Or find some other build method, which is going to take a while. Or, move this outside the compiler into rescript-react.

Agreed. How about making just method_ to breaking change? I think JsxDOM locationg in the compiler would be better choice with Jsx.element

@cristianoc
Copy link
Collaborator

E.g. do we really need JsxEvent to be in a separate file?

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

E.g. do we really need JsxEvent to be in a separate file?

How about Jsx? Do you mean all the Jsx* togther?

@cristianoc
Copy link
Collaborator

E.g. do we really need JsxEvent to be in a separate file?

How about Jsx? Do you mean all the Jsx* togther?

Probably. As build dependencies both ways are missing.

@cristianoc
Copy link
Collaborator

E.g. do we really need JsxEvent to be in a separate file?

How about Jsx? Do you mean all the Jsx* togther?

Probably. As build dependencies both ways are missing.

Btw I'm not sure it's a good idea, just asking if possible at all.

@cristianoc
Copy link
Collaborator

Probably best to go back to .ml for now.

Longer term: an observation.
A bunch of files in tests build just fine, even thought that are .res. Some of them need to have zero dependencies, and some of them (such as in build tests) do not.
So it's conceivable to build certain things later, as long as there's nothing using them earlier on in the compiler.

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

Probably best to go back to .ml for now.

Longer term: an observation. A bunch of files in tests build just fine, even thought that are .res. Some of them need to have zero dependencies, and some of them (such as in build tests) do not. So it's conceivable to build certain things later, as long as there's nothing using them earlier on in the compiler.

Totally agreed. I'll revert JsxDOM.res to ml back.

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

Can I reset to the commit JsxDOM was ml instead of revert, if you don't mind?

@cknitt
Copy link
Member

cknitt commented Sep 30, 2022

.res would be very nice to have because of the enums for the missing aria attributes.
Shall we create an issue to revisit that later?

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

.res would be very nice to have because of the enums for the missing aria attributes. Shall we create an issue to revisit that later?

That would be great!

@cknitt
Copy link
Member

cknitt commented Sep 30, 2022

Added #5708 for tracking.

@mununki
Copy link
Member Author

mununki commented Sep 30, 2022

With all changes in PRs, I ran on my company project. It works fine.

Copy link
Collaborator

@cristianoc cristianoc left a comment

Choose a reason for hiding this comment

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

This is probably good to go.
Is there a way to make git diff less confused? The diff shows domProps changed a lot while it has not. Mostly just removal.

@mununki
Copy link
Member Author

mununki commented Oct 1, 2022

Explored many paths and tried, but finally, ended up removing JsxDOM.props only.
Clean up the commits and rebased.

@cristianoc cristianoc merged commit 7dbcc93 into 10.1_release Oct 1, 2022
@mununki mununki deleted the jsx-v4-lowercase branch October 1, 2022 05:55
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.

3 participants