type person = {name: string, age: int}
let createPerson = (~name, ~age) => {name: name, age: age}
In the above code if we want to add an optional field hobbies: option<string> to the person type, then ReScript v9 compiler would guide us through all the places where we might have to add a field hobbies.
During that process we would decide whether to add a None or Some("xyx") based on our requirements.
But with this change, rescript compiler would not complain about createPerson, so I had to manually search and go through the entire codebase where we create a person type value and then add the field if it is required. By doing this I could be sure that the program would not crash. But I would not be sure that this is functionally correct since I might have missed some cases.
Yeah this would be nice I guess.
I can then use this feature only for particular cases like ReactNative styles and would not use this for most of the other part of the codebase.
Hi, I polished the implementation a little bit, the feature is close to be finalized.
So this new feature would be opt-in by using an attribute called @obj. For types like this:
@obj
type r = {
x : int ,
y : option <int>
}
let v0 = { x : 3 }
let v1 = { x : 3 , y : None}
generated JS would be:
var v0 = { x : 3 }
var v1 = { x : 3 }
The idea is that for objects annotated with obj, you don’t care about its performance in general, it is used in config patterns with lots of optionals.
Let me know if I miss anything or if any sematnics is unclear, thanks!
exciting! Regarding the name, I wonder if it makes sense to disambiguate from the @obj on externals, and provide something a little more descriptive, maybe like @stripUndefined ?
I was thinking the function need to be created to make @obj backwards compatible, but I just realized the previous @obj is an annotation to a function instead of a record. So agree!
