How to clean up data in components to prevent memory leaks?

[OscarCookeAbbott]

As far as I can tell, data creating inside a 'Component' function will never be inherently cleaned up?

For example, in this basic component:

function Counter() {
    const foo = van.state(123)

    return button({ onclick: () => (foo.val += 1) }, foo)
}

If the Counter() is removed after it is originally added, the state will stick around? This is also true of event listeners and other more complex issues like that.

Is there any standard method of getting around this? Because while I love the simplicity of the 'just return the DOM element' approach, it seems quite easy to create memory leaks without the extra scaffolding that (hefty) reactive frameworks implement.

[sirenkovladd]

VanJS has Garbage Collection
after removing eleent from DOM he clean everything related to this element

#81

[OscarCookeAbbott]

Sorry my example wasn't good, but here for example the derive() will hang around forever, after the div is destroyed:

function Example() {
    derive(() => console.warn(<some_global_state>.val))

    return html.div()
}

[sirenkovladd]

@Tao-VanJS
https://jsfiddle.net/Sirenko/f0yaujh3/80/

GC seems to have a bug and does not remove unused derive

Steps:

• add a new counter
• remove a counter
• every change in the input value will trigger this derive

[Tao-VanJS]

Ah... this is indeed tricky.

For @sirenkovladd's specific example, this can be fixed with https://jsfiddle.net/6eump4rj/. Basically for a derivation defined in a function to be properly GC-ed, that function needs to be a standard component (which means the function needs to return a DOM element).

I understand this is a little bit error-prone. I will keep this issue on mind to see improvement can be made.

[Tao-VanJS]

Took a closer look at @sirenkovladd's example: https://jsfiddle.net/Sirenko/f0yaujh3/80/. I believe it's a anti-pattern, despite in a subtle way.

The essential logic of the code can be summarized like that:

function createBindingFunction() {
  van.derive(...)
  return () => div(
    ...
  )
}

const root = div();
van.add(document.body, div(
  button({
    onclick: () => {
      const bindingFunction = createBindingFunction()
      van.add(root, bindingFunction)
    },
  }, 'Add'),
  root,
))

So technically, the van.derive in the code above belongs to the global scope, instead of the scope of binding function.

[OscarCookeAbbott]

Ok so I don't quite understand exactly the points made here:

1. "Basically for a derivation defined in a function to be properly GC-ed, that function needs to be a standard component (which means the function needs to return a DOM element)" but the function is returning a DOM element?
2. In your 'essential logic' example you have the 'component' returning an arrow function to a DOM, not a DOM itself, while in my problem code it is directly returning an element. Wrapping the entire 'component' inside another arrow function also doesn't work for 'lowering the scope'?

[OscarCookeAbbott]

Wait no never mind, I discovered a wonky bit of code in my project. You are all correct - as long as the binding function returns a DOM element, states are successfully removed in the GC pass after the element is destroyed.

I agree though that this could be made clearer / the nuances around this topic could maybe be covered better in the docs.

Thanks for your help!