As LiveRecord.Models.all.MODEL.subscribe() is just a pub-sub in itself, when you have a where condition passed into it (i.e. Book.subscribe({where: {title_matches: 'Harry Potter'}})), the JS-client only receives streamed NEW records that matches the title as specified, but does not receive OLD records that just happened to be updated (into say... '...Harry Potter...' matching the where condition above).
This is intended, however when developing in the JS-side, I ran into a situation where I'd like a "single-source-of-truth" subscription where I wouldn't want to care if a record is NEW or OLD, but just that I want to receive ANY records that matches my specified where condition, so that my store will be always kept up-to-date.
Having said these , in essence, so as to not confuse with proper terminology, what I want to have in addition to subscribe({where: {...]}), is also to have something like say... autoload({where: {...}}) where it auto-loads OLD and NEW records, as opposed to subscribe() which only receives NEW records.
As simple and as convenient this new feature would be, pondering about an implementation made me realise how big of the scope this entails, primarily because the where condition allows you to track "ANY NUMBER OF MATCHING CONDITIONS" which then would need me to write some efficient tracking-system such that when an OLD record is updated (whenever), the tracking-system would take note of the "changed attributes", and then tries to map these "changed attributes" to all/any subscribed JS-client, that has an autoload({where: {...}) having a where condition that takes into consideration any of the "changed attributes". Not to even mention having to support ransack, if it's going to be used.
Probably, there is a lot better way? Please do let me know. But at the moment, I'd have to skip on this feature.
As
LiveRecord.Models.all.MODEL.subscribe()
is just a pub-sub in itself, when you have a where condition passed into it (i.e.Book.subscribe({where: {title_matches: 'Harry Potter'}})
), the JS-client only receives streamed NEW records that matches thetitle
as specified, but does not receive OLD records that just happened to be updated (into say... '...Harry Potter...' matching the where condition above).This is intended, however when developing in the JS-side, I ran into a situation where I'd like a "single-source-of-truth" subscription where I wouldn't want to care if a record is NEW or OLD, but just that I want to receive ANY records that matches my specified where condition, so that my store will be always kept up-to-date.
Having said these , in essence, so as to not confuse with proper terminology, what I want to have in addition to
subscribe({where: {...]})
, is also to have something like say...autoload({where: {...}})
where it auto-loads OLD and NEW records, as opposed tosubscribe()
which only receives NEW records.As simple and as convenient this new feature would be, pondering about an implementation made me realise how big of the scope this entails, primarily because the
where
condition allows you to track "ANY NUMBER OF MATCHING CONDITIONS" which then would need me to write some efficient tracking-system such that when an OLD record is updated (whenever), the tracking-system would take note of the "changed attributes", and then tries to map these "changed attributes" to all/any subscribed JS-client, that has anautoload({where: {...})
having awhere
condition that takes into consideration any of the "changed attributes". Not to even mention having to supportransack
, if it's going to be used.Probably, there is a lot better way? Please do let me know. But at the moment, I'd have to skip on this feature.