How about just putting str as a whole instead of spreading when we have no other props specified? That’d solve the problem I guess.
Not sure I understand your intention correctly. If the below example is your intention, I’m afraid that it seems not compiled.
// implementation
@react.component
let make = (~a, ~b: string) => { ... }
// type props<'a, _> = { a: 'a, b: string }
// interface
@react.component
let make = (~a:int, ~b:string) => React.element
// type props<_, _> = { a: int, b: string }
Can you show an example for me to get your point?
Good idea. Why didn’t I come up with that? 
I’ll give it a try and we’ll see how it goes.
2 Likes
What do you need specifically? Just a tag? Or a specific commit?
The smarter the ppx tries to be, the more surprises can happen with little code changes.
Also, giving type annotations does not guarantee a monomorphic type (e.g. (~x:_)).
There are several things one can try if this becomes an everyday problem. Notice also that since the PPX is intended to be completely transparent, one can just write the component definition manually as an escape hatch in extreme cases.
In this specific example, one can simply avoid naming the prop type:
@react.component
let make = () => {
let str = {
Test.s: 1
};
A (beta?) version published to the npm package registry instead of a GitHub reference.
It is not crucial for my ability to test (I can do it locally) but it would be nice.
I don’t know much about the details of how this works, but I was thinking more along the lines of:
// implementation
@react.component
let make = (~a, ~b: string) => { ... }
// type props<'a> = { a: 'a, b: string }
// interface
@react.component
let make = (~a:int, ~b:string) => React.element
// type props<'a> = { a: 'a, b: string }
But I see now that this would still require the interface knowing how the implementation is specified, which wouldn’t work anyway.
I was thinking that would be a way to opt in to the current behavior, but that would also require walking the entire type to find these holes and type variables, and would make it significantly more complex. And because the type variables need to be arguments on the props type itself, the interface would also need to know how the implementation is specified. So doesn’t seem possible in any case.
I humbly withdraw my proposal 
I think if this becomes a problem, then perhaps one can let the user define the props type directly and simply pass its name as argument to @react.component or something. Also, this could be useful in case of components that need to share the same prop type (by default, each definition is different – nominal typing).
There are several things one can try, depending on what pain points look like in everyday use. We’ll need to learn a bit about pain points once people use this more extensively.
3 Likes
Side note: I’m having the thanksgiving holiday around this weekend. I couldn’t make enough time to look into the feedback in depth. I’ll come back next week and see each in detail!
3 Likes
FYI, The rescript@next = v10.1.0.alpha1 is release to npm.
1 Like
I was testing one of our projects with ReScript 10.1.0-alpha.1 and
"jsx": {
"version": 4,
"mode": "classic"
}
-
It seems that the schema for bsconfig.json does not include the
jsxkey yet, therefore the editor warns about this (“Property jsx is not allowed”). -
It seems that, for things to work, this configuration needs to be set not just in the root bsconfig.json, but in each bsconfig.json in any library used. This means that all such libraries would need to be updated accordingly (and possibly provide both a jsx 3 version for compatibility and a jsx 4 version). Isn’t that rather impractical? Or am I missing something?
1 Like
Cool, thanks! Do you also plan on releasing an alpha version of rescript-react?
If you use the pre-release channel, support has been added already.
You can use a V3 library with a V4 project. Converting to V4 cannot be done at once with all the dependencies includes, so a gradual upgrade process is supported by design.
(simply applying V4 to a library would likely incur issues in breaking changes, e.g. one component per module at most, making it impossible to use that library)
Sorry for the confusion. The extension versions are not called alpha.
The extension supports several versions of the compiler at once, including 10.1 alpha. And the pre-release channel has the most complete support.
This is not what I am experiencing. Am I doing something wrong?
I upgraded one of our projects to ReScript 10.1.0-alpha.1 and modified bsconfig.json to use
"jsx": {
"version": 4,
"mode": "classic"
}
The project is using (among others) the rescript-react-intl library as an npm dependency.
This compiled fine previously:
open ReactIntl
<FormattedTime value hour=#"2-digit" minute=#"2-digit" />
Now I get
The record field hour can't be found.
It is an explicit design goal of JSX V4 not to be magic, so the representation as record type is part of the spec.
That said, the message is indeed confusing for newcomers.
Would you have a suggestion for phrasing that message that does not hide the internal representation?
Notice the message should apply to other uses of records too, so a “if this is a component” phrasing could be required. It not impossible to technically figure out whether we are in a component context, but going in that direction amounts to essentially adding an extra layer of magic that would not apply when one defines the component directly without using @react.component, which one should be able to do.
The general philosophy is of “use the language” as much as possible, so JSX is a pretty simple, documented transform.
I think we are talking about two different things: the rescript-vscode extension (which has a prerelease channel that I’m using) versus the rescript-react package with React bindings (which has had its last release a year ago, and no alpha release yet).
The announcement suggests using @moondaddi ’s personal fork of rescript-react on GitHub; I was asking/suggesting to merge that into the parent repository and publish that as a prerelease/alpha version to npm.