♻️ Cleans Up Entangle

[ekwoka]

Just improves the logical flow of entangle to clean out unnecessary operations.

The whole stringify/parse thing seems unnecessary and there is nothing in the history to indicate why it was ever needed (and it didn't even do it in all cases). Seems like an unexpected behavior to have it clone the objects, and not explicitly reference the same object. I definitely wouldn't understand why using modelable with an object would not share references...It was just always rerunning the entangle if a property changed.

But this also allows an initial outer value of undefined which did not work before.

It can be reintroduced to actually clone (and do it for all cases) pretty simply, if you remember why that was a wanted behavior.

In fact, don't even need the hash really, could just directly reference the previous and compare.

[joshhanley]

@ekwoka thanks for the PR! The entangle code was originally in Livewire. There were issues with Alpine mutating Livewire's javascript objects without the parse. Here's a PR for reference livewire/livewire#2251

So we opted to clone the data using stringify/parse. Do you know if your changes will cause the same issue?

[ekwoka]

I can check.

Do you know of a reason that the outer being set to the inner before was NOT doing this cloning? It would just copy by reference.

That was the thing that made me more confused about if it was necessary, since surely if it was needed it should be done every time, not just some of the time.

I'll probably edit this to just do the clones all the time (but maintain the other cleanliness improvements) if I can't meaningfully validate that it's safe for Livewire.

I assume that maintaining compatibility with older LiveWire is still necessary?

[joshhanley]

@ekwoka which part do you mean about the outter being set to the inner?

In regards to safe for Livewire, I can pull your branch into Livewire and run the test suite to confirm, once you think it's good to test.

This is only for Livewire V3, as Livewire V2 as it had this code built in, so don't need to maintain compatibility with V2.

[ekwoka]

@joshhanley Previously the branch for responding to changes did not clone the value when assigning it from the outer to the inner

if (outerHashLatest !== outerHash) { // If outer changed...
    inner = innerGet()
    innerSet(outer)

So this was only copying by reference.

It was only doing the deep cloning for the initial setting, and if the inner changed. This definitely struck as peculiar.

And no worries, I can do the livewire check myself. It's something I've been meaning to check out.

EDIT: It does fail the livewire tests, so I'll reintroduce the clone, and to be consistent, do so for all entangled assignments.

[calebporzio]

Thanks for checking that out in Livewire's codebase @ekwoka!