May 22, 2021 Mini Program Cloud Development Advanced
Cloud development database supports the ability to push change data in real time, given the query conditions, whenever the database update results in a change in query results corresponding to query conditions, an update event can be received on the small terminal, through the object returned by the update time can get the updated content and updated query results snapshot.
When the user stays on the small terminal for a long time, need to pay attention to the behavior of other users caused by some real-time data changes, you can use real-time data push, as long as the data changes, can be presented in real-time at the front end. Real-time data push has a wide range of applications:
1, real-time data push only support small terminal (web side)
Watch requests for real-time data push only support front-end calls on small terminals (Web side) and not cloud-side.
2, do not abuse real-time data push
Real-time data push is only required when the small terminal needs to quickly synchronize the response to data changes, which is generally possible with page refresh, and real-time data push is only available if the user has been on the page for a longer period of time.
3, pay attention to the permission settings of the collection
The permissions for the collection need to be set to readable to everyone, and only the creator to read and write. The collection's read permission settings also take effect in live data push, and if the permissions are set to read only the user's own data, the non-user-created data cannot be listened to while listening.
4, query does not support field
Listen for update events for data in the collection that meets the query criteria. W here, orderBy, limit, field is not supported when using watch. I n listening, orderBy can specify up to 5 sort fields, with a maximum limit of 200. The limit does not exist by default to take all the data.
5, only listen to the necessary data
Listening should be clear query criteria, only listen to the data that must be used, avoid listening to unnecessary data, so as to improve the performance of the initial load of data and the performance of receiving data changes.
6. The data returned by listening is not subject to the default 20 restrictions
Listening may return more than 20 pieces of data, regardless of the default 20 upper limit on the small terminal. T he maximum number of records that can be listened to at a time is 5000, and if you exceed the limit, you throw the error and stop listening. Initialization is slow when listening to large amounts of data and has an impact on listening efficiency, and if you expect listening to start at less than 5000, but the subsequent number is likely to exceed 5000, be aware of re-listening when you are about to exceed and guarantee no more than 5000.
Real-time listening to a database can neither listen for changes to documents in the collection that meet the query criteria, or you can listen for a single doc, let's take the example of listening for a single doc. Create a new page using the developer tool, such as snapshot, and enter a button in snapshot.wxml that can modify the data, such as adding likes with a click:
<button bindtap="addStar">点赞{{stars}}</button>
Then create a new collection in the database, such as livevideo (note that permissions to modify the collection can be modified to read and write to everyone with security rules, or that likes are called as cloud functions), adding a simple record such as:
"_id":"room2020032101",
"star":0
Then declare the stars in the data property of the snapshot.js, and add the event handler addStar, as well as listen for changes in the data in the page's onLoad lifecycle function and render the data changes to the page.
data:{
stars:0
},
onLoad: function() {
const that =this
const watcher = db.collection('livevideo').doc('room2020032101')
.watch({
onChange: function(snapshot) {
that.setData({
stars:snapshot.docs[0].star
})
console.log('文档数据发生变化', snapshot)
},
onError: function(err) {
console.error('监听因错误停止', err)
}
})
}
addStar(){
db.collection('livevideo').doc('room2020032101').update({
data: {
star: _.inc(1)
},
success: console.log,
fail: console.error
})
}
Watch has two properties, onError is a failed callback, onChange is a successful callback, and a successful callback is passed in with the parameter snapshot as a change snapshot. O nChange and onError are mandatory parameters. O nChange is used to receive change snapshots and onError is used to handle listening errors. I f the listening fails to initiate or an unrecrowdable error occurs during the listening process, the listening is terminated and an exception is thrown through onError. o nChange receives a push event the first time it listens for initialization and subsequent data changes. The query results for the query criteria that are received at the first initialization, and subsequent change events contain a snapshot of the change content and the results of the query after the change.
If you want to preview the effect of real-time data push, you can use the developer tool multi-account debugging, in the developer toolbar - tool - multi-account debugging can be. W hen A users click on the like button, the number of likes is synced in real time to all online users of the small terminal. Printed information can also be seen in real time in the multi-account console.
We can keep an eye out for printed snapshot objects, which contain a lot of information, mainly
The queueType field in the docChanges object, which represents the impact of update events on the listening list, and the dataType field, which represents the specific update type of the record. Note the differences between the two, such as the case above where we just updated the value of the field, so it's updated; if the monitoring record increases or decreases, the value of queueType will be different, and the delete field will have a delete field; and the value of the dataType field corresponds to the method requested by the database, and all updated fields and field updated values will be in the update Fields object.