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"}
],