JS persistence safety: What AnkiDroid does is actually preferable

Anki Suggestions
1

Yet another post about javascript persistence.

My suggestion is to make the javascript behaviour safer. The current persistence of the whole document object between can create incredibly juicy bugs like this: Issue with shortcut for a button

I only realized what the cause could be because I’d struggled with getting stuff working the same between desktop and Ankidroid and had to think a lot about the persistence problem.

Compromise for safety and consistency

Due to this latest bug I’ve come to think that actually the AnkiDroid way of resetting the whole document object would actually be preferable.

Pros:

  • Consistent behaviour between desktop and mobile
  • Less bizarre bugs in people’s javascript

Cons:

  • Loss of the ability to load big js modules only once per review session, making javascript-heavy cards load faster on desktop.
  • Lots of people’s current card templates using some front to back persistence breaking ← This is probably the big reason why doing this is would be bad

So…

In an ideal JS world…

Then some day, if possible, I’d like to have a separate storage of javascript objects (not just strings) which would allow loading large js modules once per review session instead of needing to load them on every card render.

Maybe a card template includes two document instances that are merged on card render? One is kept separate and persistent between reviews while the other is reset per card front / back. The merge would allow the card to access objects in the persistent one.

1 Like
2

FWIW, AnkiDroid is going to migrate to the same JS loading of the desktop version. The previewers were migrated already.

3 Likes
3

It’s a good move as prep for being able to be in sync with the desktop Anki’s JS logic in the future. If it’s possible to use the Anki source code for that like they did for parts of the backend, then hopefully if desktop Anki were to switch to a safer JS logic, it wouldn’t be hard for AnkiDroid to follow.

1 Like
4

IMO, the current approach is quite safe if you know what you are doing.

5

I’m mostly against this now because of how complex it feels when actually needing to manage it. It’s hard to “keep it simple stupid” when the environment requires clever hacks to do certain otherwise basic things (thinking about the addEventListener case as the basic thing here).

1 Like
6

This doesn’t come as a surprise, but I agree.