diff --git a/docs/client/api.html b/docs/client/api.html index d8a5ae87bd..aa553a1d40 100644 --- a/docs/client/api.html +++ b/docs/client/api.html @@ -28,6 +28,37 @@ put on the screen. }); } +{{> api_box flush }} + +Normally, when you make changes (like writing to the database), +their impact (like updating the DOM) is delayed until the system is +idle. This keeps things predictable — you can know that the DOM +won't go changing out from under your code as it runs. It's also one +of the things that makes Meteor fast. + +`Meteor.flush` forces all of the pending reactive updates to complete +(for example, it ensures the DOM has been updated with your recent +database changes.) Call `flush` to apply those pending changes +immediately. The main use for this is to make sure the DOM has been +brought up to date with your latest changes, so you can manually +manipulate it with jQuery or the like. + +When you call `flush`, any auto-updating DOM elements that are not on +the screen may be cleaned up (meaning that Meteor will stop tracking +and updating the elements, so that the browser's garbage collector can +delete them.) So, if you manually call `flush`, you need to make sure +that any auto-updating elements that you have created by calling +[`Meteor.ui.render`](#meteor_ui_render) have already been inserted in the main +DOM tree. + +Technically speaking, `flush` calls the [invalidation +callbacks](#on_invalidate) on every [reactive context](#context) that +has been [invalidated](#invalidate), but hasn't yet has its callbacks +called. If the invalidation callbacks invalidate still more contexts, +flush keeps flushing until everything is totally settled. The DOM +elements are cleaned up because of logic in +[`Meteor.ui.render`](#meteor_ui_render) that works through invalidations. +

Publish and subscribe

These functions control how Meteor servers publish sets of records and @@ -1112,36 +1143,6 @@ Example: }); document.body.appendChild(frag); -{{> api_box flush }} - -Normally, when you make changes (like writing to the database), -their impact (like updating the DOM) is delayed until the system is -idle. This keeps things predictable — you can know that the DOM -won't go changing out from under your code as it runs. It's also one -of the things that makes Meteor fast. - -`Meteor.flush` forces all of the pending reactive updates to complete -(for example, it ensures the DOM has been updated with your recent -database changes.) Call `flush` to apply those pending changes -immediately. The main use for this is to make sure the DOM has been -brought up to date with your latest changes, so you can manually -manipulate it with jQuery or the like. - -When you call `flush`, any auto-updating DOM elements that are not on -the screen may be cleaned up (meaning that Meteor will stop tracking -and updating the elements, so that the browser's garbage collector can -delete them.) So, if you manually call `flush`, you need to make sure -that any auto-updating elements that you have created by calling -[`Meteor.ui.render`](#meteor_ui_render) have already been inserted in the main -DOM tree. - -Technically speaking, `flush` calls the [invalidation -callbacks](#on_invalidate) on every [reactive context](#context) that -has been [invalidated](#invalidate), but hasn't yet has its callbacks -called. If the invalidation callbacks invalidate still more contexts, -flush keeps flushing until everything is totally settled. The DOM -elements are cleaned up because of logic in -[`Meteor.ui.render`](#meteor_ui_render) that works through invalidations. {{#api_box_inline eventmaps}} diff --git a/docs/client/docs.js b/docs/client/docs.js index 682f3cfaf8..a00e017bd2 100644 --- a/docs/client/docs.js +++ b/docs/client/docs.js @@ -82,7 +82,8 @@ var toc = [ "Core", [ "Meteor.is_client", "Meteor.is_server", - "Meteor.startup" + "Meteor.startup", + "Meteor.flush" ], "Publish and subscribe", [ @@ -147,7 +148,6 @@ var toc = [ "Meteor.ui.render", "Meteor.ui.chunk", "Meteor.ui.listChunk", - "Meteor.flush", {type: "spacer"}, {name: "Event maps", style: "noncode"} ],