This is difficult to implement design-wise. Refreshing the whole list is not an option, it would be hindering for a user. The only acceptable option would be inserting new items into the list on their positions honoring the current sorting.

Inserting new items into the list would still be a huge improvement.

It's not that easy as one might think. Too many issues, too many cases. What if 100 records have been added.

Updating is difficult too. Should we subscribe to each rendered record? Too many subscriptions is not good. Should we listen to any record being updated and then re-fetch? What if there're many users and many records being updated each second.

I don't see any good solution.

I had an idea, what about giving admin the option to select entities which will have WebSocket enabled for list view? With a tooltip message warning about not enabling it for entities which gets a lot of record added at the same time?

I think that subscribe for create event is easy to implement by your own with custom list views, but as Yuri said implementing the update listeners foreach record on list views is server killer and you should be careful with it.

For create event you should use this.collection.fetch method

Just as a big sidenote, I think this could be done in Postgres using LISTEN and NOTIFY without having to listen to each individual record, but obviously, it's not reasonable to have a Postgres-only feature of such magnitude.

I have developed my custom websocket event for list view, but it's really buggy as of now.