If the model/state type used with Solid.createElmishStore contains an F# union, the union value is not deep-cloned. This causes any compile-time immutable values inside the union to be unexpectedly mutated at runtime, and also breaks Solid's granular change detection (since Fable emits unions as classes and Solid stores treat classes atomically).
Currently Util.deepClone only handles values whose runtime type is either an array, an F# record, or a plain JS object. Would it be reasonable to add F# unions to this list?
It does look like union types get a single generated prototype method called cases. In order to not break any emitted code that depends on this, one thought I had would be to, as part of the cloning process, copy all the methods from the object's prototype (as well as maybe Union.prototype and System.Object.prototype) onto the instance. Might make sense to do the same for records, too, so that things like ToString continue to work as expected.
If the model/state type used with
Solid.createElmishStorecontains an F# union, the union value is not deep-cloned. This causes any compile-time immutable values inside the union to be unexpectedly mutated at runtime, and also breaks Solid's granular change detection (since Fable emits unions as classes and Solid stores treat classes atomically).Currently
Util.deepCloneonly handles values whose runtime type is either an array, an F# record, or a plain JS object. Would it be reasonable to add F# unions to this list?It does look like union types get a single generated prototype method called
cases. In order to not break any emitted code that depends on this, one thought I had would be to, as part of the cloning process, copy all the methods from the object's prototype (as well as maybeUnion.prototypeandSystem.Object.prototype) onto the instance. Might make sense to do the same for records, too, so that things likeToStringcontinue to work as expected.