Page claims "no results" while dict file is still loading

[christophfriedrich]

Describe the bug A few minutes ago I used the website for the first time not in the office but in a train, with correspondingly low internet speed. I always open the website by typing beo <search term> into my browser's URL bar, which directly opens the website with the q parameter already set so that I have the result immediately. So this time, for the input beo foster, I was redirected to https://dict.zero-g.net/#q=foster and to my surprise saw the response "no results":

Of course there's the note below that the dictionary is still loading, but it only came to my attention like half a minute later and only because I thought "that's a normal word, why wouldn't it be included?!" I don't know if I would've kept looking for what's off if the word had been more exotic.

To Reproduce Steps to reproduce the behavior:

1. Somehow limit your internet speed and disable the cache
2. Open the link above
3. See the behaviour as in the screenshot above

Expected behavior IMO, while the file is still loading the "no results" text in the screenshot should be replaced by the note that is currently below the table. Claiming "no results" is wrong as long as the search couldn't be performed yet.

(Ideally, the search would be performed server-side anyway, eliminating the need to download 8 MB to the client (which doesn't feel much these days but may be on mobile), but I see that this is not in the scope of this project.)

Screenshots see above

Desktop (please complete the following information):

• OS: Windows 11
• Browser Firefox
• Version 129

[haukex]

Thanks, that's a very good point! I should be able to implement that this weekend.

Just to confirm - when the dictionary eventually did load, was the search performed then? (that's what's supposed to happen) I'll of course do my own testing but it is always nice to have confirmation.

(Ideally, the search would be performed server-side anyway, eliminating the need to download 8 MB to the client (which doesn't feel much these days but may be on mobile), but I see that this is not in the scope of this project.)

Yes, the client side processing allows for static hosting which is much more accessible (and often free) nowadays. That's why the app caches the dictionary relatively aggressively, so the next time you're on your mobile device the dictionary should be in the cache and the app should load quickly :-) (In fact, my most recent commit e7e7acd726a57d3e30e9d9d1e6ec69ca12e1d8f0 should speed up the loading even more, especially when there are updates, because now it always loads the dictionary from the cache first if possible, and loads the update in the background.)

[christophfriedrich]

I had closed the tab, then reopened it, then did a reload with dev tools open to check, so the whole process was not uninterrupted, but I think yes, in the end the search was performed correctly. Even after the like 2 minutes it took until the file was there.

I was not on mobile though, it was the same laptop that I had used the site with before, just this time through the train's WiFi. So apparently that aggressive caching had run out? This could be fixed by using Web Storage, but I don't know if it's worth the extra effort as usually 8 MB is okay to download.

[haukex]

Thanks for the information!

I was not on mobile though, it was the same laptop that I had used the site with before, just this time through the train's WiFi. So apparently that aggressive caching had run out? This could be fixed by using Web Storage, but I don't know if it's worth the extra effort as usually 8 MB is okay to download.

It's a possible explanation that the cache had run out, and if that does happen often, then switching from the Cache API to the Web Storage API would be one possible solution.

However, in this case, based on my experience, I think something else was happening: I noticed during development that the browser would sometimes cache the app a little too much, meaning I would sometimes get served old versions of the app from the cache (I think this might have something to do with the way Service Workers are cached). There have been several dictionary updates in the past weeks, and previous versions of the app would first check for an updated dictionary and load that before checking the cache.

So I think that what happened in your case is that your browser loaded a slightly older version of the app, which saw there was a dictionary update, and therefore ignored the dictionary you probably still had in your cache at the time.

If you clear your cache and all saved data for "zero-g.net", and then open the dictionary, you'll force a reload of the latest version of the app, which will then always load the cached dictionary first if available. If you still experience the same problem as described above, then let me know, because that would indeed be an indication that perhaps the dictionary is being dropped from the cache too soon/often.

[christophfriedrich]

I'm in a train again right now and can confirm it works as intended :) When opening the app, there was some text in the table, but I couldn't read it quick enough because then results were already being displayed -- while a new dictionary was loading in the background, which took a bit over a minute according to the DevTools.

[haukex]

Glad to hear it, thanks for checking!