On 7/20/19 5:23 PM, Max Suica wrote:
> I'd like to hop aboard the electron conversion effort. How should I go
> about that?
>
> […]
>
> Questions:
> - Is there any public location where a new contributor can get a high
> level view of the current plan and tasks in the conversion project?
> - What are some of the keywords you use to search and track the
> current effort? Where do you search for them (zot-dev? gh-PRs? Other)?
Thanks for your interest here!
We've done some work internally to get a sense of the best path forward
for getting to Electron — mostly involving shimming Mozilla XPCOM
interfaces (e.g., nsIFile) and/or Zotero functions (e.g.,
Zotero.File.getContentsAsync()) so that we can avoid rewrites and
minimize the amount of time we have to have an active Electron branch
for the main code base — but most work on that front is premature and/or
counterproductive at this point.
The top priority currently is converting the entire UI from XUL to HTML,
mostly using React. That's underway — the tag selector is completely
changed, the collections tree and items tree are underway, and the item
pane and preferences are next — but there's a lot to do.
If this sort of thing interests you, that'd be a great place to start,
and the benefit is that the code would roll out to production as soon as
it was done instead of at some indeterminate point in the future. For
simplicity, we're trying to keep things mostly pixel-identical at first,
but this work will allow us to start modernizing the design
independently of the switch to Electron.
We've been taking this component by component, and we haven't yet made
firm decisions on everything (e.g., SASS vs. CSS-in-JS). In some cases,
we need to come up with primitives that can be used across components
(e.g., a generic replacement for the XUL 'wizard'). Some things we can
adapt from work on the new Zotero web library [1], though due to
differing requirements we're unlikely to directly share much code.
Architecturally speaking, the plan for most components is to separate
them into 'containers', which will call into the data layer and receive
change notifications via Zotero.Notifier, and 'components', which should
ideally receive data entirely via props (which means, among other
things, that they could potentially be developed outside of Zotero using
something like nwb). You can see an example in the tag selector [2] [3]
[4]. That code uses classes, but new code should probably use React Hooks.
If it'd be helpful, we can go through and create issues for each window
or component that needs to be changed, which can also serve as areas for
implementation discussions. But off the top of my head, something very
simple and isolated like the export options window [5] would probably be
a good starting place. The import wizard [6] would be another good one,
though that's an area where we may want to figure out a more general
solution (probably starting with seeing what Mozilla is doing to replace
the XUL 'wizard').
If you're interested in working on a specific part, create an issue on
GitHub and we can discuss further there. Thanks again!
- Dan
[1]
https://github.com/zotero/web-library
[2]
https://github.com/zotero/zotero/blob/master/chrome/content/zotero/containers/tagSelector.jsx
[3]
https://github.com/zotero/zotero/blob/master/chrome/content/zotero/components/tag-selector.jsx
[4]
https://github.com/zotero/zotero/blob/master/chrome/content/zotero/components/tag-selector/tag-list.jsx
[5]
https://github.com/zotero/zotero/blob/master/chrome/content/zotero/exportOptions.xul
[6]
https://github.com/zotero/zotero/blob/master/chrome/content/zotero/import/importWizard.xul