Custom mutable methods on ReactiveArray

[0kku]

By design, ReactiveArray mirrors the functionality of native Arrays as closely as feasible. The major difference is, that instead of returning plain values and new Arrays, it returns ReactivePrimitives and new ReactiveArrays. For example, ReactiveArray.length is Readonly<ReactivePrimitive<number>> instead of number.

The library encourages mutability, because that's how it tracks changes to changes to things like arrays. However, some methods on native Array are immutable, which in some cases orthogonal to the workflow in Destiny UI. With this in mind, ReactiveArray specifies some mutable alternatives to the immutable ones, such as ReactiveArray::mutFilter() and ReactiveArray::mutMap() which are equivalent to Array::filter() and Array::map() respectively, except that they mutate the array, instead of creating a new one. ReactiveArray::filter() and ReactiveArray::map() are naturally also available, so the mutable versions are an additional addition. The immutable versions return a piped readonly ReactiveArray, which is kept updated with the original array.

Do these additional mutable versions provide meaningful value to warrant increased bundle size? Are they confusing? Should all immutable array methods that return a new array have a mutable equivalent?

[0kku]

Example of ReactiveArray::mutFilter() in use

[b-fuze]

In all honesty I thought they were kind of redundant, primarily because of my exposure to the standard API. However, your example does hold value, but in reality I expect most people to be inclined to use the standard APIs unless they have a fairly deep understanding of JS and realize how the implementation of an immutable filter is in fact redundant behind-the-scenes (assuming they don't need the original).

Really, I think it's fine. And what people should be doing is using a tree shaker that can remove most of the methods that aren't used.