Hi. I’m developing board view app that detects changes in realtime, by using
monday.listen(“events”…)
also I need to check for currently filtered items
monday.listen(“itemIds”…)
my app should only detect changes in the items that are within currently filtered.
But when user add new item, first “events” callback fires, and only after that “itemIds” (if this new item goes in filtered).
So, if I’m checking filtered in “events” callback it would always fail. I guess I can workaround by adding some delay in check, but this doesn’t look good, maybe there is more clean way?
The lack of activity in this post is disturbing…
Hey @yureckey
Sorry for the delay in reply.
Why do you try to check filtered in “events” callback? If you want to display filtered items, so you need to rely to the “itemIds” changes and not to “events”, because user can add new item and change filters, so this item will not be in filtered anymore. Or to create an item and then change it, so it will become part of filtered items.
There is some confusion, probably I didn’t described my problem properly.
My app dedicated to the tracking of data updates by using monday.listen(“events”…). When there is new data added or old data updated my app react in it’s UI. I wanted to have option, so app user can choose whatever to track all changes or only changes in data currently filtered in the view. I thought, I should embrace monday.listen(“itemIds”…) so when filter changes, my app will set state with changed items ids and then callback of “events” will execute and inside it there is reading of those ids, is it filtered or not. But then I run test - set filter in view and added data/updated old data. And I realized that currently “events” callback runs first, and only after it, “itemIds” change callback run. So what is proper way to check is newly added/updated item in current filter view?
In case of tracking changes in data currently filtered in the view, I would suggest to listen only to “itemIds” changes and check the diff between current “itemIds” array and the new array, which is coming to the callback.
By this, you will be able to track not only the creation of the new item but also if an item was changed and it became part of the filter/was removed/was changed in a way that it became out of the filter, etc.
Yes, valid points, thanks. But then again, app should track data updates, like when cell updates, so it needs to use “events”, otherwise cell update event is lost (if it’s not causing the filter to change). So, again, since filter view change generates “itemsIds” after “events”, I need to use something in “events” callback to ensure that updated data was in filter view. Looks like I should stick to time delay.
I think that in “events” you need to listen only to “content” updates, like change_column_values, but in “itemIds” listen to the “visible items” changes (if it’s add/remove/change filters/etc.)
after some experiments with “itemIds” I can say that I can’t really use it in my app.
My app dedicated to tracking change of real data, not change in the view data. And with “itemIds” it’s impossible to detect if event called due to simple change of filter or real data adding/removing.
1 Like
Hey @yureckey! Just to make sure we are on the same page, do you mean it’s impossible to only use an itemIds listener to check for changes to data?
This is true; you will need to watch both events and itemIds to track both data updates and view updates.
Let us know if you have additional questions or thoughts.
Yes, I wasn’t clear, sorry. I mean that I hoped to use “itemIds” along with “events” to track adding and removing data. And I was able to use it to track adding data and determine if it in filter or not. But it’s impossible to track data deletion, since it doesn’t generate “events” and you can’t tell if it user changed filter or data was removed for real. Possible workaround is to query those items from monday.com, but it doesn’t look like good solution
We are indeed missing an event that triggers item deletion. A webhook like “When item is deleted send a webhook” (including support for this webhook type in the API would be very helpful.