I wish there was a way to limit props to a subset of the obj fields in a generic way (trivial in TypeScript, by the way). Otherwise, you can easily pass "agw" and spend some time debugging why age fails to update.
Programming languages enthusiast. Author of Learn Type Driven Development: https://www.packtpub.com/application-development/learn-type-driven-development
Good point! Hopefully this becomes less of a pain once records-as-objects is shipped and we can start modelling JS objects as Reason records with immutable update. Assuming they give the OK to use it like that!
Programming languages enthusiast. Author of Learn Type Driven Development: https://www.packtpub.com/application-development/learn-type-driven-development
It could be handled with a PPX too. E.g. the [@bs.deriving abstract] annotation generates getters and setters for the object type it annotates: bucklescript.github.io/docs/en/obj... . Theoretically it could be extended to also generate a 'copy constructor':
Well, if I correctly understand what record-as-objects is (namely, compiling ML records to JS objects as opposed to JS arrays), your ‘copy constructors’ (or assign constructors or what have you) could still be useful, provided one needs do deal with optional object properties. I mean, you would still probably need [@bs.derivig abstract] if some of your properties are optional, no?
Programming languages enthusiast. Author of Learn Type Driven Development: https://www.packtpub.com/application-development/learn-type-driven-development
I wish there was a way to limit
props
to a subset of theobj
fields in a generic way (trivial in TypeScript, by the way). Otherwise, you can easily pass"agw"
and spend some time debugging whyage
fails to update.Good point! Hopefully this becomes less of a pain once records-as-objects is shipped and we can start modelling JS objects as Reason records with immutable update. Assuming they give the OK to use it like that!
Oh. I thought that maybe things like that can be amended via some PPX, but if there’s a first-class support forthcoming, so much the better.
It could be handled with a PPX too. E.g. the
[@bs.deriving abstract]
annotation generates getters and setters for the object type it annotates: bucklescript.github.io/docs/en/obj... . Theoretically it could be extended to also generate a 'copy constructor':Well, if I correctly understand what record-as-objects is (namely, compiling ML records to JS objects as opposed to JS arrays), your ‘copy constructors’ (or assign constructors or what have you) could still be useful, provided one needs do deal with optional object properties. I mean, you would still probably need
[@bs.derivig abstract]
if some of your properties are optional, no?If the properties themselves are optional, true! That throws another thorn into the copy constructor generator idea.