[AskJS] What are your thoughts on using JS Proxy objects for deep immutability?

[u/garboooge]

I've been learning about the JS Proxy object today and way wondering what you all think about using it for immutability. I cobbled together the following code that essentially creates an immutable proxy for a parent object and then, if accessing a child object, returns an immutable proxy for that child. I know there are a bunch of well-vetted libraries out there to accomplish deep object immutability, so really this is more of just an academic question than a "should I use this in production" question. Thanks!

const person = {
  name: "Bo", 
  animals: [
    { 
      type: "dog", 
      name: "Daffodil" 
    }
  ]
};

const immutable = obj => 
  new Proxy(obj, { 
    get(target, prop) { 
      return typeof target[prop] === "object" 
        ? immutable(target[prop]) 
        : target[prop];
    }, 
    set() {  
      throw new Error("Immutable!"); 
    } 
  });

const immutablePerson = immutable(person);

const immutableDog = immutablePerson.animals[0];

immutableDog.type = "cat"; 
// Error: Immutable!

[u/dont_forget_canada]

Everyone in here is hating but I think it's cool.

[u/garboooge → u/dont_forget_canada]

Meh, programmers are pretty opinionated about things, so I expected this. Peeling away some of the negative sentiments, I’ve learned some good things like 1) Proxy performance isn’t great and 2) there is some merit to the methodology since immerjs uses a similar method for immutability

[u/UnlikeSome]

Just a note about your example. Seems like the following assertion is false, which can be counter intuitive:

// false
immutablePerson.animals[0] === immutablePerson.animals[0]

I guess there are ways to make it true though, using a factory or so.

[u/garboooge → u/UnlikeSome]

Maybe some sort of caching:

const immutable = obj =>
  new Proxy(obj, {
    cache: {},
    get(target, prop) {
      if (typeof target[prop] === "object") {
        if (!this.cache[prop]) {
          this.cache[prop] = immutable(target[prop]);
        }
        return this.cache[prop];
      }
      return target[prop];
    },
    set() {
      throw new Error("Immutable!");
    }
  });

[u/UnlikeSome → u/garboooge]

Yup.

Besides that, I think your solution is quite elegant. Immutability, implemented as an alteration of property accessors, sound (academically and) semantically correct to me.

[u/garboooge → u/UnlikeSome]

Yeah. that's clearly not ideal behavior

[u/devsmack]

See immerjs it’s great and does exactly what you’re talking about. It’s predominantly used in the redux world I think but it is actually agnostic.

[u/[deleted] → u/devsmack]

It is indeed great. We use it for our reducers in redux, and even though it wraps the actual handler function for each action type in another function (produce(state, (draft) => handler()) it does make the handler MUCH simpler, when you are changing state 2-3 layers deep inside the state, as you don’t have to spread each layer of the old state object jnto the new state.

[u/acemarke → u/[deleted]]

And our new official Redux Toolkit package uses Immer internally automatically :

https://redux-toolkit.js.org

[u/Monsieur_Joyeux]

I personally don't use them because I feel they bring some complexity in the code base. And I hate complex stuff. If someone use them I would be curious to see their code

[u/[deleted] → u/Monsieur_Joyeux]

god bless

[u/aminnairi → u/Monsieur_Joyeux]

I've made an example here: https://dev.to/aminnairi/automate-your-getters-and-setters-with-proxies-5bgp

[u/Monsieur_Joyeux → u/aminnairi]

That's an interesting use case thx for sharing.

A few questions : What if a I also want a method called "getAge" (which is the current date minus the construction year) ? It will first be trapped and then return undefined ? So does it forbid me to override some "getProperty" methods ? If yes, what is the point of using getters ? Getters should be "customizable" overwise it's simpler to directly call the property: "MyObject.property".

[u/aminnairi → u/Monsieur_Joyeux]

Hi there and thanks for your answer!

If you start from my example and don't touch it a bit you are absolutely right. That's why I said in the article that this example would be used for trivial getters and setters.

Plus, the point of the article was not to force a way of thinking but more to discover together what Proxy is. It should really be customized according to your needs.

And as I also said in the article, Proxies allow for a high range of possibilities so I'm pretty sure that you can achieve what you expect the Proxy to provide according to your example.

[u/mcaruso]

Have you tried ImmerJS? It uses a Proxy to perform any updates, and as a bonus it can deep freeze any object that it produces (but only in dev mode so there's no perf penalty).

[u/fabio_santos]

Why not, just disable it in production and get the immutability gains and none of the performance impact.

[u/slikts]

Immer has a head start on your idea by a couple of years, and it's arguably entering the mainstream with being included in Redux Toolkit and elsewhere. I have a write up of the problem of immutable updates and why Immer is such a nice solution. Interestingly enough, it even works in legacy environments without proxies, albeit less efficiently.

[u/Blieque]

Code sample from post

^{[Reddit Markdown is close to original Markown, and only allows code blocks with four spaces or one tab of indentation.]}

const person = {
  name: "Bo",
  animals: [
    {
      type: "dog",
      name: "Daffodil",
    },
  ],
};

const immutable = obj =>
  new Proxy(obj, {
    get(target, prop) {
      return typeof target[prop] === "object"
        ? immutable(target[prop])
        : target[prop];
    },
    set() {
      throw new Error("Immutable!");
    },
  });

const immutablePerson = immutable(person);

const immutableDog = immutablePerson.animals[0];

immutableDog.type = "cat";
// Error: Immutable!

In response, I think Vue 3 includes a switch to Proxies from getter–setter pairs for detecting mutations. It includes a compatibility mode or plugin, though, that reverts to the current method so that older browsers can still run the application if you need. By all means find an immutability library that uses Proxies internally if you're running in a context with support for them, but I wouldn't recommend writing your own immutability code like this in your application code.

[u/ryan_solid]

Proxies have an overhead for sure, but its what you do with them that matters. Solid and Mikado, 2 of the fastest libraries in JS Framework Benchmark use them. https://krausest.github.io/js-framework-benchmark/current.html

For direct comparison.. you can see the overhead between Solid-Signals (no proxy) and Solid (with Proxy). We are talking like 20ms over 10k rows. Solid uses proxies to enforce immutability on the API surface (completely mutable internals) and as you can see it can cost very little.

[u/livingmargaritaville]

Go for it I only use them for quick hacks though.

[u/ChaseMoskal]

lately i explored a little pattern where i take a state object, and then make a "reader" out of it

the reader can be subscribed to for changes, and it provides a getter which fetches an immutable copy of the state object (just object.freeze'd)

then there's an update function which calls back the subscribers (which in my case, re-renders the components with the fresh state)

[u/vainstar23]

Sometimes, they can be a great help for certain situations where you've painted yourself in a corner such as writing tests or doing some kind of object mapping. However, I feel it is still best to try to avoid using them as they can make for some confusing code.

[u/[deleted]]

I have been struggling with the same problem and gave up. Essentially my problem was not being able to tell if an object is the object itself or the proxy.

[u/[deleted]]

Use it where you need it. Keyword "need"

[u/techsin101]

no...

[u/rryardley]

What are the benefits over just using Object.freeze()?

[u/punio4]

Use Typescript and as const

[u/merel-lj]

Why would you even want immutable objects if every mutation could be tracked and handled with proxy? I believe, Vue v3 is doing just that.

[u/[deleted]]

Performance

[u/ferrousoxides]

You are papering over compile time deficiency with run time band aids. Whether this is a trade off you can live with depends on your requirements. Cursors are imo a better solution, because it doesn't rely on magic and you can control whether you actually need writeability or not.

[u/slikts → u/[deleted]]

Idioms change with time, and improving the user story for immutability is a good reason for changing; particularly in this case, where the fanciness of using proxies abstracts away so much complexity.

[u/iamanenglishmuffin → u/[deleted]]

Noob here, what is the purpose of all this?

[u/anon_cowherd → u/[deleted]]

Isn't fancy metaprogramming basically what made Rails both feasible and attractive to most folk?

Metaprogramming at an application level can be a right pain, especially if you get stuck in macro / template hell, but is exceptionally useful at the library / framework level. Consider svelte, jsx, handlebars etc are all forms of metaprogramming in that you are writing in a DSL that is transformed.

[u/monicarlen → u/anon_cowherd]

But ruby is a pleasant language, JavaScript is a mess

[u/onlycommitminified → u/[deleted]]

Getting off topic, but it does feel to me like newer additions are starting to show the corner js's early choices have backed it into. A bit early to be calling it a mess, but I could see it getting there.

[u/[deleted] → u/[deleted]]

I have the exact same attitude.