ReScript 10 / records with optional fields

ReScript 10 will support records with optional fields. This would allow us to simplify a lot of things/move them closer to how they are done in JS.

E.g., styles: Instead of

let styles = StyleSheet.create({
  open Style
  {
    "statusBar": style(
      ~flexDirection=#row,
      ~height=dp(22.),
      ~alignItems=#center,
      ~paddingLeft=dp(12.),
      (),
    ),
    "text": style(~color=NativeColors.white, ~marginLeft=dp(4.), ()),
  }
})

we could have

let styles = StyleSheet.create({
  open Style
  {
    "statusBar": style({
      flexDirection: #row,
      height: dp(22.),
      alignItems: #center,
      paddingLeft: dp(12.),
    }),
    "text": style({
      color: "white",
      marginLeft: dp(4.),
    }),
  }
})

Or for APIs taking some config object, like

Share.share(Share.content(~title="Title", ~url="https://example.com", ()))

we could have

Share.share({title: "Title", url: "https://example.com"})

@MoOx For me the question is, can these be breaking changes or should we try to remain compatible with the existing way where possible?

If we go for breaking changes, then we could also do #748 at the same time.

I guess we can do breaking changes. This will be painful to migrate but it will be more easy for new comers. Alternatively, since we have bindings, we could offers 2 version, deprecate one, and later kill old ones ? Maybe a open ReactNative_Alt or something that could help people to slowly migrate ?

@MoOx We can do it like this:

type content = {
  title?: string,
  message?: string,
  url?: string,
}

@obj @deprecated("Directly create record instead")
external content: (~title: string=?, ~message: string=?, ~url: string=?, unit) => content = ""

The record with optional fields will not even compile with pre-10.x compiler versions though.

That's why I didn't merged #767. I wanted to do a release before a v10 only version.

Oh, sorry, I thought #767 was ready to merge as you had approved it.

If you want all breaking changes in the v10 release, then we can either revert #767 or continue with the v10 stuff on master and create a 9.x "maintenance branch". What would you prefer?

Yes I prefer major changes associated with v10 release indeed. I will revert #767 and reopen the PR and keep opened PRs with a milestone for React Native 0.70 (coming very soon, it's in RC 3 or something like that). Meanwhile, I will cut a 0.69 release with a solution for hitSlop #765

Just to let you know, I am on vacations with limited access to computer & web, I will handle all this release when I get back, mid September.

@MoOx How shall we proceed regarding a "ReScript 10" release with the breaking changes? I think more breaking changes are to come with JSX 4 in 10.1, so it makes sense to wait for 10.1.

However, shall we merge the corresponding PRs to some "future" branch or something? So that we have something to test with already?

I guess waiting to release for JSX 4 is a good thing for official release. I was undecided for the hitSlop thing & didn't do anything...

I will handle 0.69 release & will merge everything in main branch for 0.70 release :)

Busy day, I have released 0.69 today and will review & merge all pending PR tomorrow morning :)

@cknitt when will be released JSX 4 approximately ?

It will be part of ReScript 10.1. A few more weeks and a few more alpha/beta releases of ReScript 10.1 I guess.

Maybe @mattdamon108 and @cristianoc can comment on that?