# Reclaiming memory from Nodes

**URL:** <https://discourse.nodered.org/t/reclaiming-memory-from-nodes/49554>\
**Category:** Developing Nodes\
**Created:** [10 August 2021 04:29 UTC](https://discourse.nodered.org/t/reclaiming-memory-from-nodes/49554 "2021-08-10T04:29:25Z")\
**Posts on this page:** 1\
**Showing post:** 21

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [20 August 2021 09:11 UTC](https://discourse.nodered.org/t/reclaiming-memory-from-nodes/49554/21 "2021-08-20T09:11:06Z")

</div>

If you are interested in where I've got to in deconstructing the uibuilder runtime, please check out the v4.2.0-dev branch. It is quite interesting but I'm not sure I would recommend it except for complex nodes as it does need some advanced features of node.js. However, I have managed to eliminate the `node` variable completely. The exported function is only a few lines long now as all the work is done in separate functions. This has also resulted in some simplification of the code and the removal of a few pieces of odd logic.

The only reason this was a fairly straightforward task (an evening) was because I already saved all of the important module-level data in variables outside the exported function. This meant that they were still available when the functions were split out.

The only exeption to that is the `RED` variable which is the reference to the Node-RED runtime object. I could actually further simplify the code if I saved a reference to RED. Something I might try.

[https://github.com/TotallyInformation/node-red-contrib-uibuilder/blob/v4.2.0-dev/nodes/uibuilder.js](https://github.com/TotallyInformation/node-red-contrib-uibuilder/blob/v4.2.0-dev/nodes/uibuilder.js)

> [@kevinGodell](#):
>
> I was actually going to suggest that, but didn't want to sound like a preachy javascript nut. I find classes to be a nice way to structure and organize my code.

Well now that I have destructured the code, I think that I can see how a node might be converted to a class. But I am far from sure that it would have any runtime benefits.

> [@kevinGodell](#):
>
> The benefit of adding methods to the class is that they get added to the object's prototype, which is supposed to save memory if you have many instances.

I actually don't think that applies to nodes. In reality, only a single copy of the module that defines a node is loaded. It is only the function passed to `registerType` that is run more than once - for each instance of a node.

> [@kevinGodell](#):
>
> I heavily utilize class(static) properties to share info between instances if needed.

I went down the singleton route myself. `web.js`, `socket.js` and `security.js` are now all singleton class modules. Means that I don't have to fret over static elements. I really like how clean that code is now and far more comprehensible and easier to debug - though I have had to wrap the `require`s in try/catch statements so that I get the correct source line if there is an error in the class. Even the "disadvantage" of the singleton model (you can't pass parameters to the constructor) is an advantage in my case because I don't want to (can't actually) fully set-up the class instance when it is require'd, that has to be done later on and I just use another class method.

It has been quite a journey of understanding getting into the depths of classes in JavaScript and exactly what they are and are not. I've also learned a lot more about the `this` object and arrow functions.

There is certainly more to come. I really need to deal with the messy uiblib.js file which is a random collection of utility functions. Most of which get passed an inordinate number of parameters!

---

_[View the full topic](https://discourse.nodered.org/t/reclaiming-memory-from-nodes/49554)._