The web library will probably still display the old tag in addition to
the new one, at least until browser restart. We'll have to deal with
that separately.
Closes#1205
When refreshing, if fewer than 100 tags to show, just create them from
scratch instead of updating the full set. Otherwise, remove the full set
from DOM and add it back in after updates to avoid reflows (from #1204).
There are various things that could be done to optimize this further
(avoiding unnecessary sorting during full refreshes, calculating a hash
of the full set and not updating it every time), but we should probably
just replace it with @tnajdek's React version first.
Closes#1204
Changes `libraryTreeView::addEventListener('load')` and similar to
`libraryTreeView::onLoad.addListener(listener, once)`, etc. `once` is an
optional boolean that, when true, causes the listener to fire once and
then be removed. This is implicit for 'load'.
'load' maintains its special behavior of running immediately if the
treeview has already been loaded.
Also adds `waitForLoad()` and `waitForSelect()` functions that return
promises on event completion, since most uses of those events were just
resolving deferreds.
TODO: Add text fields for controlling number of items and chunk size
(Chunk size should be small for testing UI interactions and performance
but large for generating lots of data.)
Follow-up to https://github.com/zotero/zotero-standalone-build/commit/22cfe2404
The devtools must be included in the build by passing the -t flag to
build.sh in zotero-standalone-build.
After starting Zotero with the flag, connect from a Firefox instance
with remote debugging enabled by choosing "Connect…" from the Web
Developer menu and connecting to port 6100.
For building up a big library and testing UI interaction during writes
To use, load chrome://zotero/content/tools/data_generator.html in
Firefox (for now).
Could be improved a bit to add other kinds of data (collections,
child items, relations)
The items list is generated from the database (via search), but new
items may have been added to the database but not yet been registered,
causing unloaded-data errors during sorting. Avoid that by not showing
unregistered items when generating the items list.
Additional protections are necessary -- it's still possible to get
errors, and maybe a crash, if an item has been registered but not yet
fully loaded -- but this addresses the most common one.
We could monkey-patch a finally function in connectors as described in
this gist https://gist.github.com/jish/e9bcd75e391a2b21206b , but it
appears to silence propogation of unhandled rejections
and it could later come back to bite us in the butt.
Native and proper support for finally is, however, planned in ES7.
When dragging an item to another library, we have to check if there's a
linked item in the target library, but items might not yet be laoded in
the other library, so item.getLinkedItem() can fail with "Item [n] not
yet loaded].
Fixing required asyncifying the follow functions:
- Zotero.Item::getLinkedItem()
- Zotero.Collection::getLinkedCollection()
- Zotero.URI.getURIItem()
- Zotero.URI.getURICollection()
- Various integration functions
As noted in 27cb099c82, import translators should be rewritten to return
a promise from doImport() and wait for promises from successive
item.complete() calls. They should then be marked as minVersion: "5.0"
to be handled properly by this new code.
(But this tries to account, albeit with somewhat worse behavior, for
translators that haven't been rewritten and sandboxes without Promise
(which is currently the case with child sandboxes in the client).)
(Oh, and I haven't tested this at all in the connectors.)
