jenkins-bot has submitted this change and it was merged.
Change subject: On re-sort, just render all the topics we fetched
......................................................................
On re-sort, just render all the topics we fetched
This avoids inconsistent state bugs at the cost of an inconsistent
UX (10 topics at page load, 50 on re-sort).
Bug: T118108
Change-Id: Id6b8d393bf60977e8a1bfcd8877fa41858bb0525
---
M modules/flow/dm/mw.flow.dm.System.js
M modules/mw.flow.Initializer.js
2 files changed, 18 insertions(+), 7 deletions(-)
Approvals:
Catrope: Looks good to me, approved
jenkins-bot: Verified
diff --git a/modules/flow/dm/mw.flow.dm.System.js
b/modules/flow/dm/mw.flow.dm.System.js
index 49a089c..e03ec4d 100644
--- a/modules/flow/dm/mw.flow.dm.System.js
+++ b/modules/flow/dm/mw.flow.dm.System.js
@@ -308,6 +308,8 @@
* When we scroll down or load a topic, this is the number that defines
the
* batch of topics to be loaded and rendered.
*
+ * This does not affect the number of topics loaded when the sort order
changes.
+ *
* @return {number} Rendered topics
*/
mw.flow.dm.System.prototype.getRenderedTopics = function () {
diff --git a/modules/mw.flow.Initializer.js b/modules/mw.flow.Initializer.js
index a6a9a41..d37ca74 100644
--- a/modules/mw.flow.Initializer.js
+++ b/modules/mw.flow.Initializer.js
@@ -288,13 +288,22 @@
resetBoardEnd: function ( data ) {
var $rendered;
- // HACK: Trim the data for only the rendered
topics
- // We can't have the API request use a limit
because when we
- // rebuild the board (when we reorder) we want
the full 50
- // topics for the ToC widget. When the topic-
and board-widget
- // are operational, we should render properly
without using this
- // hack.
- data.topiclist.roots =
data.topiclist.roots.splice( 0, mw.flow.system.getRenderedTopics() );
+ // populateBoardFromApi uses the larger TOC
limit so the TOC can
+ // be fully populated on re-sort. To avoid two
requests
+ // (TOC and full topics) with different limits,
we do a single
+ // full-topic request with that limit.
+ //
+ // However, this is inconsistent with the
number of topics
+ // we show at page load.
+ //
+ // This could be addressed by either showing
the larger number of
+ // topics on page load, doing two separate
requests (might still be
+ // faster considering the backend doesn't have
to get full data for
+ // many topics), or filtering the topic list on
render.
+ //
+ // The latter (filter on render) could be done
when the topic- and
+ // board-widget are operational using some sort
of computed subset
+ // data model.
$rendered = $(
mw.flow.TemplateEngine.processTemplateGetFragment(
'flow_block_loop',
--
To view, visit https://gerrit.wikimedia.org/r/251801
To unsubscribe, visit https://gerrit.wikimedia.org/r/settings
Gerrit-MessageType: merged
Gerrit-Change-Id: Id6b8d393bf60977e8a1bfcd8877fa41858bb0525
Gerrit-PatchSet: 1
Gerrit-Project: mediawiki/extensions/Flow
Gerrit-Branch: master
Gerrit-Owner: Mattflaschen <mflasc...@wikimedia.org>
Gerrit-Reviewer: Catrope <roan.katt...@gmail.com>
Gerrit-Reviewer: Mooeypoo <mor...@gmail.com>
Gerrit-Reviewer: jenkins-bot <>
_______________________________________________
MediaWiki-commits mailing list
MediaWiki-commits@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-commits
