Thanks for the article Ustun. I’d made some progress towards this approach, but your write-up has convinced me to go all in, and write ‘setters’ as well as ‘getters’.
To summarise how I’ve stumbled on this use of Records, I’ve found that what might otherwise be written as selector functions (that have to be individually imported wherever they’re used), can instead be very conveniently written as methods on the record subclass—or even better, as ES6 getters. I’ve found that this ‘store API’ makes it easy to write concise, DRY
‘mapStateToProps’ functions when creating connected components, with a minimum of duplicated logic. It’s also good for keeping the store normalised, with getters used to compute derived data on the basis of the underlying record fields.
Generalising this a bit, I see no reason not to define the root atom of the store as a Record subclass, with selectors that need to draw from different slices of the state as methods on the root record.
Anyway, thanks again—what you’ve put forward has inspired me to keep going down this route.