Skip to content
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

Prefetching drop down entries when adding transaction #352

Closed
zynexiz opened this issue Apr 6, 2024 · 3 comments · Fixed by #384
Closed

Prefetching drop down entries when adding transaction #352

zynexiz opened this issue Apr 6, 2024 · 3 comments · Fixed by #384
Assignees
Labels
enhancement New feature or request fixed Bugs that are fixed (in a coming release).
Milestone

Comments

@zynexiz
Copy link

zynexiz commented Apr 6, 2024

I hade some issues when adding new transaction in the app. I just noticed this worked without issues when I was connection to my home network, so this issue appears when I'm om mobile network. The issue occurs when starting to type in something in the input boxes with the drop down menu. It seems that the search for the string you start to type is done on the fly, fetching the result from the server itself. This issue seems to be affected when using high latency networks, like mobile network.

This makes the result "jump around" for a second before settling for the result i typed in. Half of the times when I press one of the results, it rearrange the order in the drop down menu entries, thus selecting something else in the end. I have to wait for a second or two for it to "settle" before selecting something. Not a huge issue, but still pretty annoying experience.

One solution is to prefect the entries and do the search locally, alternatively add 500-800 ms delay after last character was typed before querying the result? This would make the experience a bit more consistent.

@dreautall
Copy link
Owner

The autocomplete is done completely server-side, yes. Obviously on bad connections this might cause some issues.

I can try to put in a delay, but not sure if this wouldn't be too disturbing in most circumstances (assuming you have somewhat good mobile internet). I will experiment a little bit with it in an upcoming beta version.

I could shoot the query right away and then show the results if there was no further input for 500ms. The overhead of the queries should be pretty minimal.

@dreautall dreautall self-assigned this Apr 7, 2024
@dreautall dreautall added the enhancement New feature or request label Apr 7, 2024
@dreautall dreautall added this to the v1.0.2 milestone Apr 7, 2024
@dreautall
Copy link
Owner

After playing around a bit, I couldn't find an option that feels "natural" in good internet environments 😞 Might need to play around a bit more, but so far every delay just feels... strange.

@dreautall dreautall modified the milestones: v1.0.2, v1.1.0 Apr 19, 2024
@dreautall
Copy link
Owner

dreautall commented May 18, 2024

After playing some more (sorry for the long delay), I think I found the best way: The requests are still send instantaneously, but the results are not progressed if a new letter is entered before the answer arrived. This should prevent jump-arounds while not introducing a fake latency with a forced wait, which makes for a way better flow on fast networks.

I'll implement this for the text fields on the transaction page in a future release.

@dreautall dreautall linked a pull request May 18, 2024 that will close this issue
@dreautall dreautall added the fixed Bugs that are fixed (in a coming release). label May 18, 2024
@dreautall dreautall modified the milestones: v1.1.0, v1.0.4 Jun 1, 2024
@dreautall dreautall mentioned this issue Jun 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fixed Bugs that are fixed (in a coming release).
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants