Improve docs for handling the warning "computations created outside a createRoot or render will never be disposed"

[mauriver21]

I'm seeing a potential Achilles heel in Solid because is very easy to fall on this warning, and in some cases, the reactivity is lost.

computations created outside a `createRoot` or `render` will never be disposed

Despite the rules of hooks doesn't apply to SolidJS, invoking a hook (that contains effects) inside a function triggered by an onClick event shows this warning. Here is a demo example at SolidJS playground:

https://playground.solidjs.com/anonymous/57dfbe9b-80e3-4a6a-a445-33b7c6dcf87e

Solutions for mitigating this problem:

• To add docs at solid-site which give information about how to mitigate this warning.
• To add inside this warning a link that targets solid-site docs that explain how to mitigate this warning.

For my part, I don't know how to give a solution for the given playground example.

[mauriver21]

I found the solution, however, is not intuitive for the development experience the fact of manually specifying an owner inside an event listener. Why the owner is not auto-injected for event listeners in Solid?

const App: Component = () => {
  const owner = getOwner();

  const onClick = () => {    
    owner && runWithOwner(owner, () => useHook())
  };

  return (
    <>
      <button onClick={onClick}>Click me</button>
    </>
  );
};

[LiQuidProQuo]

The dx can be improved(subjectively) with a utility/primitive

import { getOwner, runWithOwner } from "solid-js";

//stay liquid

/**
 * provide a default owner to a callback.
 * if there is an active owner, the active owner takes precedence. 
 */
export const withOwner =
  (fn, o = getOwner()) =>
  (...args) => {
    o ??= getOwner(); 
    return o ? runWithOwner(o, () => fn(...args)) : fn(...args);
  };

export const useEvent = withOwner

usage:

const myEventHandler =  useEvent(()=>{
    createEffect(()=>{})
})

<>
   <button onClick={myEventHandler}></button>
</>

or  directly in JSX element

<>
   <button onClick={useEvent(()=>{ createEffect(()=>{} ) })}></button>
</>

playground

[mauriver21]

I'm aware of that, you can do a workaround by creating a utility/primitive, or maybe a provider that contains as a fallback a global owner, but this additional step is what still ruins the dev experience. This detail is like looking for a needle in a haystack.
I suggest this must be handled by the framework itself, Solid must be smart enough to identify the owner of this callback or event.

[ryansolid]

The thinking is creation under async is sort of dangerous. The warning is precisely to discourage this. Because yes without the hook rules you can do exactly this and it all works and doesn't lose reactivity, but it also isn't a great thing to do. Top level computations are fine as they are probably intended as global, but ones created during timeouts, async callbacks, and event handlers can be called repeatedly and get lost. And I have no intention of trying to patch every possible async callback.

The owner in this case is what? The scope the event handler is declared in? That means you click 100 times you create 100 effects that only get disposed of when that scope cleans up.

The current setup sort of pushes entry into the system through data. If you want to create an effect, set a signal that maps it. It would be interesting to see a logical way to remove this constraint that wouldn't lead people into temporary memory leaks.

But mostly I'm curious of the scenario you want this. Like what are you attempting to accomplish? I think talking through that would be more interesting to understand.

[mauriver21]

But this problem doesn't only occur with hooks. I have this other scenario, I'm implementing a factory pattern for building a centralized system that handles dialogs on my application. Every time I create a modal, an instance is created and when closed it's destroyed in memory. Those instances are saved in a store exposed by a provider. I share the playground showing the basic mechanism. The warning happens when I pass a reactive object as part of the content of the modal. Using runWithOwner, the warning disappears but is not intuitive to work with this helper function, people are not going to be aware of using this helper function for this kind of scenario. Most developers will ignore the warning which will cause bad practices in the community. At this point Solid becomes similar to React, now the mind model of re-renders is substituted by ownership (runWithOwner / createRoot makes me feel to be working with useMemo / useCallback as a workaround), which reduces the framework's transparency.

https://playground.solidjs.com/anonymous/9c96ffd7-f4ce-4b42-81a9-52472d4037fa

Let me know if this scenario is enough to track the problem.

[ryansolid]

Hmm.. yeah I wouldn't recommend this pattern. It creates elements outside of anything with reactive bindings. Like it basically creates DOM elements and stores them in the Store. Typically we'd push the actual rendering to the end of the chain. Ie.. pass in a render function or use a getter. With a getter you'd need to be careful not to spread it.. But that's pretty typical for Solid.. we don't spread or destructure props. There is mergeProps for this but in this simple case I just mutated it.

Like here: https://playground.solidjs.com/anonymous/1ba9466f-6121-4239-826b-26820316a131

The reason the error was happening was because the fragment created a reactive memo. It needs to do that to preserve reactivity. So it was the same thing more or less.

Honestly, we have owner APIs for some advanced cases for writing libraries but I don't think any application code should really ever need it. I recognize this really is a documentation issue because a lot of advanced users of Solid will be able to use these APIs to do incredible things but really for the most part like the first few APIs you learn are all you really need for pretty much everything.