Skip to content
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

Explore record type extension #5659

Closed
2 of 3 tasks
cristianoc opened this issue Sep 13, 2022 · 4 comments
Closed
2 of 3 tasks

Explore record type extension #5659

cristianoc opened this issue Sep 13, 2022 · 4 comments
Milestone

Comments

@cristianoc
Copy link
Collaborator

cristianoc commented Sep 13, 2022

type extended = {...t, x:string} as an abbreviation instead of repeating the field of the type definition of t.

@cristianoc cristianoc added this to the v10.2 milestone Sep 13, 2022
@mununki
Copy link
Member

mununki commented Sep 13, 2022

Another magic would solve the key props issue here 👍

@cknitt
Copy link
Member

cknitt commented Sep 22, 2022

This would be so great for the React Native bindings!

Currently the props of View need to be repeated for all subclasses of View, see e.g. https://github.com/rescript-react-native/rescript-react-native/blob/4f04d7788829f4764ca570ec3920f24b8c149568/src/components/Slider.res#L21.

Having

module Slider = {
  type props = {
    ...View.props,
    disabled?: bool,
    maximumTrackImage?: bool,
    // ... more slider props ...
  }

  @module("react-native")
  external make: props => React.element = "Slider"
}

instead would be a huge win!

/cc @MoOx

@cristianoc
Copy link
Collaborator Author

I wish we could extend the parse tree and this would be some clean extension.
Instead, one would have to find a representation using the existing AST. For instance, a fake field called "...".
Other than that, the type checking extension should not be difficult.

@mununki
Copy link
Member

mununki commented Sep 22, 2022

Not sure, but isn't it workable with label_declaration and attribute something @spread?
Deleted a confused comment.

cristianoc added a commit that referenced this issue Oct 2, 2022
Uses convention on field name "dotdotdot", to be replaces with a parser producing e.g. a field called "...".
Currently expands the type eagerly.

See #5659
cristianoc added a commit that referenced this issue Apr 11, 2023
Uses convention on field name "dotdotdot", to be replaces with a parser producing e.g. a field called "...".
Currently expands the type eagerly.

See #5659
cristianoc added a commit that referenced this issue Apr 12, 2023
Uses convention on field name "dotdotdot", to be replaces with a parser producing e.g. a field called "...".
Currently expands the type eagerly.

See #5659
cristianoc added a commit that referenced this issue Apr 13, 2023
Uses convention on field name "dotdotdot", to be replaces with a parser producing e.g. a field called "...".
Currently expands the type eagerly.

See #5659
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants