Discussion: Concerns about uncollectable references?

[jonathanj]

Thanks for publishing this, I wrote something quite similar recently and it's been inspiring to read other similar implementations.

For my use case I have some top-level context providers that I suspend while they fill their context with essential data for the rest of the app. In my own implementation I ended up using a key (that I name appropriately in the code) to retain the various suspended states.

I was curious how the "dependencies array" concept worked in suspend-react (and learned about fast-deep-equal, thanks!) and in the process noticed that new entries are pushed into the cache, when dependencies change, but unless clear is called manually (with the old dependencies) the cached item is retained.

My question is: Is hanging onto the old promises (and in turn the reference to their result) something I should be concerned about? Correctly calling clean when the dependencies change seems challenging.

[drcmda]

the predecessor use-asset had a lifespan, i just added it back: https://github.com/pmndrs/suspend-react#lifespan that would allow for automatic cleanup.

function Foo() {
  // Keep cached item alive for one minute
  const result = suspend(fn, keys, { lifespan: 60000 })

generally, react itself is going to solve at least some of these concerns. the state will be reacts, it later will live inside the component graph:

import { Cache } from 'react'

<Cache>
  <Foo />

function Foo() {
  const bar = suspend(fn, [keys])

[jonathanj]

Thanks! The lifespan option looks like a good choice for my use case, the quick response is much appreciated.