if anyone is familiar with immer js or immutable js:

if the producer copies the base state to nextState, and nextState is a const, doesnt that defeat the purpose?

I mean you're going for immutability, which is great for say an undo function, or for finding bugs, but what are you doing with all these immutable values now hanging around in memory?

I assume each new state returned is being pushed onto an array? (because you cant stuff it into nextState because nextState is immutable).

Wont this lead to memory usage increasing over a user session, the longer the session lasts?

I feel like I'm misunderstanding some core concept here.

edit: also what the hell is structural sharing?

They dont hang around in memory, you transform the old state to the new state, the previous state gets collected when it goes out of scope.

If that's not the case, you're doing it wrong.

@SortOfTested I think Im starting to get it?

How does thay make the old state immutable though?
Doesnt that defeat the purpose?

Or is it like the base state is immutable to the *current draft state* only, but not *strictly* immutable?

The current state cannot be mutated. You can take the current state, apply changes to a copy of the original data and receive a new state object, but you never have an object whose value you can alter.

The mechanisms of how you do that vary library to library and language to language, but the principle is the same.

@SortOfTested thank you for your answers and for being so patient! If currentState is entirely immutable, and nextState is disposed of when out of scope, then where are the changes to state stored?

I don't know JavaScript much...

But I think you're (@SortOfTested @Wisecrack) two different things.

The term structural sharing stems from joyful data structures...

In simple, not (fully) correct, binary search trees where only modified data between two states is added or inserted, rest is kept intact.

Reality is more complex. ;)

@Wisecrack
First off, let's talk immutability, immutablejs style:
https://stackblitz.com/edit/...

The final result of an operation which transforms an immutable record is a new record. See example;

Second off:
Immerjs' draft construct creates a tree of pending changes. These changes are instructions that will exist so long as they have not yet been applied. This is similar to immutable's withMutations.

It uses a strategy known as copy-on-write that will delay the actual creation of a new state copy until something actually modifies it. You keep a tree around as long as something is in a draft state. If that draft state is realized, the tree is finalized into a state and the copy is returned.

Personally I think immer is a shitshow, and immutablejs is poorly written. Both only exists because of Reactland's fascination with god object state machines. Just my opinion though.

@IntrusionCM
It's not quite a trie. It's just an insertion order tree of proxies that only live so long as their mutations haven't been executed. You couldn't search down the tree to find context, it keeps the reference to a node in the caller and only crawls the parent axis. Branches are trimmed when refcount = 0 at intersectional nodes (no leaves).

Yes, they don’t hang around in memory. Imagine a linked list with two heads, v1 and v2. Perceived as two lists but they’re the same structure in memory.

Google “persistent data structures”

@SortOfTested Ah k. Was pretty sure I didn't get it right, but wanted to give a "lil pushie" in the right direction... And most immutable data structures are "something trie'ish"

The solution is to stop using immutable javascript altogether. It's just needlessly complicating your development cycle. I promise.

@IntrusionCM
Tries can be used for immutability, just not in the case of either or those libs

@junon
To me it simplifies it if you're dealing garbage jslang, but I also use rx code most of the time.

I find it preferable to have reliable messaging without the need to consider the case that something with a reference to the same object might have made changes that are incompatible with my algorithm.

all im asking is where the currentState actually must live..

its become obvious that the current state (less the base state) isnt stored on the base state, and it's not stored on nextState until the application ends, because otherwise you'd have a shit ton of variables of the flavor nextState1, nextState2, nextState3, etc, kicking around.

So you're telling me this is storing the curentState somewhere in immer itself or in a variable produced by immer?

@junon you’re wrong and your dick is probably too small and you know it

@kiki I am always correct and my dick is of formidable stature.

@kiki @junon
Devrant couple: formed

completely off topic. i like this.

if its gonna be a couple might as well include SortOfTested and I to make it a foursome.

continue the insults. I find them exciting! 👉👈 👉👌👅😺🍆👂

I ran of ideas for lewd emojis.