mavo
mavo copied to clipboard
mavoweb
<input> and <textarea> should not update expressions on every keystroke by default
There are many instances where the current behavior is undesirable, and often people need to circumvent it with cumbersome hacks like using actions (example). This is especially undesirable when the expression is used in a slow context, especially URLs where every update triggers a new HTTP request.
There are still use cases for the current behavior (e.g. showing a character counter or validating input), so it should be possible, but through an opt-in (thoughts about syntax?).
Instead, the default behavior should be to update when the user pauses typing. Possibly the delay should be configurable, which lends itself to a nice opt-in to the current behavior: setting the delay to 0. Perhaps mv-edit-typingdelay?
In fact, I'm thinking there should be an mv-edit-delay that would work for any element, and would just default to a > 0 value for <input> and <textarea>. People may want to throttle other elements as well, e.g. if you have a slider you usually want immediate updates, but what if you use that value in an expression?
...which makes me wonder if we actually need an expression throttle, and not an editor throttle...
If you implement expression throttles you need to be careful that long chains of expressions don't sum their delays such that the overall recalculation becomes very slow.
On 10/18/2021 10:00 AM, Lea Verou wrote:
In fact, I'm thinking there should be an |mv-edit-delay| that would work for /any/ element, and would just default to a > 0 value for || and |
...which makes me wonder if we actually need an expression throttle, and not an editor throttle...
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mavoweb/mavo/issues/782#issuecomment-945802753, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIWSXRBSFTN4M654UZ6FMTUHQR6ZANCNFSM5GGWZBHQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I'd like to understand more about the motivation for slowing updates. Is it purely a matter of efficiency? Issues with UI flashes?
Another option might be to allow certain inputs to be configured such that their value only propogates when they lose focus?
On 10/18/2021 9:53 AM, Lea Verou wrote:
There are many instances where the current behavior is undesirable, and often people need to circumvent it with cumbersome hacks like using actions (example https://codepen.io/leaverou/pen/QWLGWzx). This is especially undesirable when the expression is used in a slow context, especially URLs where every update triggers a new HTTP request.
There are still use cases for the current behavior (e.g. showing a character counter or validating input), so it should be possible, but through an opt-in (thoughts about syntax?).
Instead, the default behavior should be to update when the user pauses typing. Possibly the delay should be configurable, which lends itself to a nice opt-in to the current behavior: setting the delay to 0. Perhaps |mv-edit-typingdelay|?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mavoweb/mavo/issues/782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIWSXRH7M4O2SQE2P6ISW3UHQRERANCNFSM5GGWZBHQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I think the primary problem is when expressions are used in URLs, firing off a separate HTTP request for incomplete inputs.
Just to mention that since all our storage attributes are live now (and might be changed via expressions), we might face the same issue not only with evident URLs but also with those that are hidden under the hood. E.g., fired off by storage plugins.
that suggests that you should throttle fetches, not expressions. and perhaps that once a fetch has been successful, you shouldn't replace its results with unsuccessful/404 fetches during recalculations.
On 10/18/2021 10:12 AM, Lea Verou wrote:
I think the primary problem is when expressions are used in URLs, firing off a separate HTTP request for incomplete inputs.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mavoweb/mavo/issues/782#issuecomment-945815552, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIWSXWJFZPM4SCQWC4IJPDUHQTMRANCNFSM5GGWZBHQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
that suggests that you should throttle fetches, not expressions. and perhaps that once a fetch has been successful, you shouldn't replace its results with unsuccessful/404 fetches during recalculations.
Mavo does not control when the browser fires off an HTTP request. We can only throttle our own fetches that way.
On 10/18/2021 10:57 AM, Lea Verou wrote:
that suggests that you should throttle fetches, not expressions. and perhaps that once a fetch has been successful, you shouldn't replace its results with unsuccessful/404 fetches during recalculations.Mavo does not control when the browser fires off an HTTP request. We can only throttle our own fetches that way.
Mavo can decide when to invoke fetch. and whether to incorporate what comes back or ignore it (404)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mavoweb/mavo/issues/782#issuecomment-945862596, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIWSXTW5NI7FZFJZDEBIPDUHQYWJANCNFSM5GGWZBHQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Mavo can decide when to invoke fetch. and whether to incorporate what comes back or ignore it (404)
No. The browser immediately fires an HTTP request every time e.g. <img src> changes, and there's absolutely nada that JS can do about it. Also, even for JS fetches, Chrome prints out 404s as errors in the console, and there's no way to suppress them.
2 different cases.
- expression in an href or a src: mavo can decide when to update the value of that attribute (to control when fetch happens)
- expression in mavo attribute, e.g. mv-source. mavo can decide when to respond to changes in the value
On 10/18/2021 11:35 AM, Lea Verou wrote:
Mavo can decide when to invoke fetch. and whether to incorporate what comes back or ignore it (404)No. The browser immediately fires an HTTP request every time e.g. |
| changes, and there's absolutely nada that JS can do about it.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mavoweb/mavo/issues/782#issuecomment-945901307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIWSXV2CMGD6TEZXGOYEQ3UHQ5FTANCNFSM5GGWZBHQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.