Execution order .on_change and .js_on_change

Hi,

I am trying to create interactions on a Datatable using a Select widget that modifies a GroupFilter in CDSview.

I am aware of the limitations that the CDSview can’t detect the changes, see Changing CDSView filters' attributes does not trigger rendering · Issue #7273 · bokeh/bokeh · GitHub

I have managed to get a rough working version using a CustomJS callback with source.emit() and source.selected.emit().

However, the changes in the Datatable consistently lags by one interaction. Am trying to figure out what is causing this, and one possible reason would be that if .js_on_change is executed before .on_change (where the changes in the GroupFilter are processed), this would lead to the observed lag.

Could someone confirm what the execution order is?

This seems related:

Generally, the execution of the JS callback, and the websocket protocol message to trigger a Python callback occur roughly contemporaneously. But when the server callback actually executes can depend on many external factors (i.e. network or server load) that are not controllable. It’s probably the case that a JS callback executes first, most of the time. But things may be different for different models, depending on their implementations, the actual amount of work done in the various callbacks, network and load conditions.

TLDR; There are not any guarantees about order of JS callbacks vs Python callbacks, so I would advise not to try to rely on any specific order.

Thanks again @Bryan. Have solved it as follows:

• Select widget with GroupFilter is bound to .on_change Python callback
• This callback updates the data and source, and also a dummy widget
• Another .js_on_change callback is bound to the dummy widget (which is hidden)

This does the trick, and now we can easily filter a DataTable with a GroupFilter.