Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-24842

The export tree is instantiated on page load instead of when the export modal is opened

    XMLWordPrintable

Details

    • Unknown

    Description

      Reproduction steps

      1. Visit http://localhost:8080/xwiki/bin/view/Sandbox/
      2. Open the browser debugger, network tab
      3. Reload the page, and do not open the export modal

      Expected

      The export tree is not built, and no page tree query is sent to the server, until the user opens the export modal.

      Actual

      The tree inside exportTreeModal is instantiated during page load and its root node is expanded straight away, which sends 4 requests to /bin/get/<Space>/<Page>?... on every page view — server-side page tree queries for a modal that was never opened.

      On a terminal page, where the exportTreeModal markup is not even emitted, the xwiki-export-tree and xwiki-export-tree-filter modules are still fetched and the initialisation still runs against an empty selection.

      The modal markup itself is also inlined in the HTML of every page: about 5.8 KB for exportModal plus 4.5 KB for exportTreeModal, for anyone who can see the "More actions" menu, guests included.

      Analysis

      The last statement of the top-level require(['jquery'], ...) block in uicomponents/exporter/exporter.js is:

      require(['xwiki-export-tree', 'xwiki-export-tree-filter'], function () {
        $('.export-tree').exportTree();
      });
      

      $.fn.exportTree ends in a call to .xtree(...), which calls jstree(...), and instantiating jsTree immediately triggers _load_node on the root node — hence the requests above.

      Note that jstree.min.js and tree.min.css themselves are not wasted on a default flavor, because the Navigation panel displays a tree on every page and legitimately needs them. What is wasted here is the second, hidden tree instance and its server round-trips.

      There is already a show.bs.modal handler in the same file, but it only refreshes an existing tree: waitForExportTreeReady() calls treeElement.jstree(true) and assumes the instance has already been created. So moving the initialisation into that handler requires making waitForExportTreeReady cope with a tree that has not been instantiated yet.

      The sibling exportModal already uses exactly the wanted lazy pattern in the same file, so there is a local precedent to follow.

      Suggested fix

      Instantiate the export tree from the show.bs.modal handler rather than on page load, and adapt waitForExportTreeReady accordingly. Loading the modal markup itself on demand would be a further improvement, in the spirit of XWIKI-22266.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              mleduc Manuel Leduc
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated: