-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate export dialog to web #3145
base: main
Are you sure you want to change the base?
Conversation
This looks like a nice implementation @RumovZ and sensible step forward in Anki's UI migration. However, looking at the impact of this on the add-on ecosystem, this will break almost all add-ons extending the export system, including:
Add-ons in 2) could create their own export UIs, but it would be a significant downgrade in Anki's extensibility if add-ons have to ship custom solutions for this, rather than hooking into an exporter API (not to mention a worse UX, with native and addon-provided export options spread apart). Add-ons in 1) would have no recourse and would have to drop functionality. I think it would be important for us to think through how we can maintain extensibility here in a sensible way. |
To summarize, based on existing use cases, the three most important abilities for add-ons would be:
I can look into 2.) and 3.) as these needs are essentially only present for the AMBOSS add-on at the moment. 1.) seems like it will require a bit more consideration, and I'd be curious what your thoughts are on how we can best do this (if you are on board with adding an exporters API, @dae). It seems like a JS API that would expose |
Appreciate your input! As long as we don't have to keep a second legacy exporting module this all sounds good to me. I will have to look into how add-on integration in webviews works. |
In the short term, we may want to do this, as the existing add-ons that make use of the hooks will take some time to get updated. Can't we just put it under the same legacy import/export flag we already have?
I wouldn't say we have a well-established pattern for this yet. Some of our screens provide the ability for add-ons to extend them, but it hasn't been widely used yet, adds a bunch of noise to our implementation, and locks users into using Svelte. The reviewer screen exports some globals that can be appended to as a makeshift hook system, but we only do it there so far, if I recall correctly. |
And what about the legacy-legacy dialog? Do we drop that for good then?
Seems reasonable here. Being able to extend or modify the list of exporters should cover most use cases, and it's similar to how the current API works. |
I'd honestly forgotten about it ^_^; I know that we can't remove the legacy import code yet due to the popularity of the special fields add-on, but I'm not aware of any big add-ons that use the old exporting path. Do you have any thoughts on this @glutanimate? |
32c6983
to
c6f76a9
Compare
I have spent some time looking into add-on integration now, and dispatching an event with a writable store is the best I could come up with: ankitects/anki-addons#21 Originally, I was imagining the page load to look something like this:
However, steps 1. and 3. seem inseparable, at least in the new SvelteKit views, and any add-on code is loading in parallel. That means add-on code cannot rely on any already existing variables to hook into, and our Svelte code must be reactive to changes made by add-ons after the fact. I had looked at https://github.com/hgiesel/closet and https://github.com/kleinerpirat/anki-tooltips, but they use the Do either of you see a better alternative, @dae, @glutanimate? |
77e22a2
to
f88f05a
Compare
I think your assessment is correct - reactivity+stores is probably our best option for now. As an aside, Svelte 5 is not too far off though (RC announced a few days ago: https://www.youtube.com/watch?v=gkJ09joGBZ4&t=8610s), and the new Rune system looks like it'll be a fair bit easier to use than stores. I am tempted at this point to hold off on porting the editor to SvelteKit until we've upgraded to Svelte 5, as it's going to need a bunch of refactoring anyway, and the new functionality needs to be opted into a file at a time. |
f88f05a
to
b7728f0
Compare
Closes #3023.
I deleted the now unusable hooks. Do we have to be more considerate?