Update Bokeh DataTable with JS callback

I am trying to update the source of the datatable. Below is the sample code I have been using. It was working fine with bokeh 2.2.3 but after I upgraded to the recent version it is only displaying the first row. Looks like it is not updating the index array. I have tried several things but am unable to update the index. Or I am not sure if I am missing something

showevents_cb = CustomJS(args={'source': source,  'events_source': events_source},
                     code="""
                        var events = events_source.data;
                        for (i = 0; i < del_arr.length; i++) {
                            events.index[i] = i;
     
                            if (i < del_arr.length){
                                events['loss'][i] = del_arr[i];
                                }
                            else{
                                events['loss'][i] = '-';
                                }
                            }
                            events_source.change.emit();
                            )

Hi @Gopi1616 unfortunately it’s not really possible to speculate without a complete Minimal Reproducible Example to run and observe directly.

@Bryan I understand! Unfortunately, it is a small piece of bigger code so it is difficult to make a working version of this as there are lots of dependencies. At the minimum could you confirm if this is the right way of updating the index in the datatable source in JS callback in 3.1.1?

Below are the screenshots of Datatable’s source index values from the browser console for the prev Bokeh version 2.2.3 (the same code displayed all the array elements in the table after updated through JS cb) and the 3.1.1 with the same code where it is only showing the first element in the first row.

Has anything changed since 2.2.3 in the way the index is modified ?- in 3.3.1 the amp array has two values after being updated through the code but the index just has one value and its dtype seems to be int instead of an array object as you see in the 2.2.3 screenshot.

2.2.3 :

3.1.1

@Gopi1616 A great deal changed about the low-level serialization from 2.x to 3.x but not really at a user-level. I’d still expect in a CustomJS to just need to update a source.data as always, and I don’t think I would expect you to see that column format with dtype field at this point. (cc @mateusz). I’ve very curious what exact event this CustomJS is triggering off of. I’d highly encourage you to try to work up a small toy example that demonstrates this same behavior.

Thanks @Bryan . I will try to generate a reproducible example. Meanwhile, if you don’t mind could you please provide a simple example code to update the index and a column of data table in a Javascript callback?

It looks like the data table column data have changed from a simple array in v2.4.2 to an ndarray object in 3.1.1 so my above code is no longer working. I would really appreciate a simple JS example code as I am very very new to JS. Thanks!

2.4.2:

3.1.1 :

@Bryan Actually nevermind. I just figured out that the shape of the objects needed to be updated with the length of the columns values. Also, the built-in index seems to be an Int32Array so I had to convert the index array values to Int32Array. So I got it working by adding the lines below.

events.index = Int32Array.from(events.index)
events.amp._shape = [events.amp.length]
events.index._shape = [events.index.length]

Hope this helps someone

@Gopi1616 Here is an example that updates source.data in JS code in a CustomJS callback:

https://docs.bokeh.org/en/latest/docs/user_guide/interaction/js_callbacks.html#js-on-change-callback-triggers

As you can see it does not do anything different or special.

If mean using only BokehJS directly I don’t use the JS API very much, so I don’t have any examples to share. @mateusz might Otherwise, that is why having an MRE to start from is important.

It looks like the data table column data have changed from a simple array in v2.4.2 to an ndarray object in 3.1.1 so my above code is no longer working.

As I mentioned above, this is expected to be an internal change. I would not expect users to encounter this data structure, or have to deal with it, and I don’t know why you are seeing it, without being able to actually investigate real code. This is another reason an MRE is critical.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.