Handling computed values in listeners

[gismya]

Hello!

Is there a way when using multiple values in a listener, where some are computed values based on another of the values, to have the computed values update before the callback function triggers?

Example sandbox:
https://codesandbox.io/p/sandbox/javascript-forked-5fqzg5?file=%2Fsrc%2Findex.js%3A13%2C1

I have a computed value based on another value: in the example, it's currentFPS, which is dependent on CurrentPlaylistItem. I always want the latest value of currentFPS when running the callback for CurrentPlaylistItem.

The three ways I've tested it is

1. Simply listening to CurrentPlaylistItem, and having a currentFPS.get() in the callback. But it gets the old value and never updates.
2. The example sandbox solution with listening to both CurrentPlaylistItem and currentFPS - the values are always eventually correct, but it requires two passes of the callback function.
3. Setting the listener as a computed. Works, but feels very hacky.

[ai]

Sorry, I don’t get the task. In an example CurrentPlaylistItem is not a computed(), but an atom().

[ai]

No, it is a way to define computed store.

Why you may want to define store in a listener? (Seems like a still don't understand what is the problem can 6ou show a simple code, to illustrate your problem, not a while project?)

[gismya]

I'll try to simplify an example.

I have two stores,
const currentPlaylistItem = atom(playlistItems[0]);
which has a computed
const currentFPS = computed(currentPlaylistItem, (item) => item.fps);

When the currentPlaylistItem changes I'm initializing a class
currentPlaylistItem.listen(loadPlayer);

and loadPlayer is calling a function that needs both the playlistItem and currentFPS (an external module)

function loadPlayer {
   setupPlayer(currentPlaylistItem.get(), currentFPS.get())
}

I can't run setupPlayer with the incorrect values, so I need to wait until both currentPlaylistItem and currentFPS has the updated values before running the loadPlayer callback.

(Of course this is a greatly simplified example, there's no need having currentFPS as a computed if it's just a getter for .fps)

[gismya]

loadPlayerListener = computed([currentPlaylistItem, currentFPS], (item, fps) => {
  setupPlayer(item, fps);
})
loadPlayerListener.listen(() => {})

Is one way that could be done, but that feels janky

[ai]

Got it. The problem is that currentPlaylistItem.listen(loadPlayer) is running before the currentFPS update (since computed() use the same currentPlaylistItem.listen and listeners are executed by the order)?

The simplest solution without overcomplicating is to create getFPS(playlistItem)and use it in listener.

More complex solution is to create store playerOptions computed from currentPlaylistItem and currentFPS and init player on playerOptions changes.

[gismya]

Thank you so much!

Got it. The problem is that currentPlaylistItem.listen(loadPlayer) is running before the currentFPS update (since computed() use the same currentPlaylistItem.listen and listeners are executed by the order)?

Exactly

The simplest solution without overcomplicating is to create getFPS(playlistItem)and use it in listener.

Me advising a team member not to do this was actually the catalyst to me deep diving in this. I'll get back to him and tell him I was wrong.

More complex solution is to create store playerOptions computed from currentPlaylistItem and currentFPS and init player on playerOptions changes.

I'll look into this!

Would a "multiListen" function that uses similar strategies as the computed to set listenerLevel be of any interest for the respository? Or have any obvious issues such that it's foolish to even look into. Might develop one for our use case, but if it could be of interest to the main repo I could polish it enough for it to create a PR here as well.

[ai]

I am afraid multiListen will only make API more complex.