33 ms·

Another option if you can afford it is to just use immutablejs. Or make your functions return new objects.

nine_k 8y ago
I suppose immutable.js supports partial reuse of objects, that is, if you only change the value of one attribute, the changed copy has this attribute set differently, but the rest is shallow-copied? If so, indeed immutable objects would not run into the problem of copying, as long as you can afford them to be immutable. (That is, you're not working with any APIs that assume and use mutability.)
beaconstudios 8y ago
I cannot recommend ramda enough. It provides the immutability and flexibility of immutablejs, but because it's build in a functional paradigm, the logic is fully composeable so complex, deeply nested changes are very simple and readable.
- oweiler 8y ago
  That is an apples to oranges comparison. ramda does not provide persistent data structures.
  - beaconstudios 8y ago
    both are used to approach the same problem: immutable manipulation of javascript data. The fact that immutableJS provides a persistent object is an implementation detail in the strategy used to solve that problem.
realharo 8y ago
I would recommend immer (https://github.com/mweststrate/immer https://github.com/mweststrate/immer) instead of ImmutableJS. You can work with regular JS objects, plus it plays much nicer with TypeScript.
- benvan 8y ago
  I wrote a tiny library called fn-update for this that does composable functional updates (https://github.com/benvan/fn-update https://github.com/benvan/fn-update). Personally, I prefer not having to mutate data, even wrapped in a produce method
  - realharo 8y ago
    Having to specify the path using an array of strings would be an instant dealbreaker for me. It messes with all tooling and is bad for readability.
TheAceOfHearts 8y ago
ImmutableJS is a pretty huge library. I'd conjecture most web apps don't have a legitimate need for something so comprehensive and would be better off with a simpler solution. If you know the shapes of your objects ahead of time you can create one-off functions, which will probably be faster and require far less code.

I suppose immutable.js supports partial reuse of objects, that is, if you only change the value of one attribute, the changed copy has this attribute set differently, but the rest is shallow-copied? If so, indeed immutable objects would not run into the problem of copying, as long as you can afford them to be immutable. (That is, you're not working with any APIs that assume and use mutability.)

beaconstudios 8y ago

I cannot recommend ramda enough. It provides the immutability and flexibility of immutablejs, but because it's build in a functional paradigm, the logic is fully composeable so complex, deeply nested changes are very simple and readable.

oweiler 8y ago
That is an apples to oranges comparison. ramda does not provide persistent data structures.
- beaconstudios 8y ago
  both are used to approach the same problem: immutable manipulation of javascript data. The fact that immutableJS provides a persistent object is an implementation detail in the strategy used to solve that problem.

realharo 8y ago

I would recommend immer (https://github.com/mweststrate/immer https://github.com/mweststrate/immer) instead of ImmutableJS. You can work with regular JS objects, plus it plays much nicer with TypeScript.

benvan 8y ago
I wrote a tiny library called fn-update for this that does composable functional updates (https://github.com/benvan/fn-update https://github.com/benvan/fn-update). Personally, I prefer not having to mutate data, even wrapped in a produce method
- realharo 8y ago
  Having to specify the path using an array of strings would be an instant dealbreaker for me. It messes with all tooling and is bad for readability.

TheAceOfHearts 8y ago

ImmutableJS is a pretty huge library. I'd conjecture most web apps don't have a legitimate need for something so comprehensive and would be better off with a simpler solution. If you know the shapes of your objects ahead of time you can create one-off functions, which will probably be faster and require far less code.