-
-
Notifications
You must be signed in to change notification settings - Fork 70
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
auto updating relativeTime and rt #241
Comments
@HIRANO-Satoshi good ideas. Tbh I'm having a very challenging time right now at my company so I'm kinda out of order for the upcoming week. I will definitely revisit this afterwards, as it is an important aspect of performance savings. So please stay tuned a bit longer |
the relative time binding behavior now additionally listens to the aurelia-relativetime-signal. Use this to only notify RT about changes related issue #241
I went with option A and added an additional signal listener |
You did? Thanks. That means a timer should tick very second, even though relativeTimes were counting hours or days. If we don't need to think about battery consumption, it would be good. I thought option B would be better, since each realtiveTime could setup setInterval() by itself according to its time scale. Hourly ticks are enough for a hour counter, for example. |
Thats true but since now the dev has to setup the interval first he/she can decide when to start/pause and on which interval length. Adding all of the edgecases would be likely to heavy for the Plugin |
@HIRANO-Satoshi feature is released. I'm gonna close this issue for now, if we have any additional requirements/problems we can always repoen |
Thanks so much! |
Hi,
relativeTime and rt do not update their time by themselves. "in 1 minute" remains as it is forever.
I tried the following code. It forces 'value & rt' to rewrite every one second.
It is very heavy since aurelia-translation-signal causes df, nf and t to rewrite, too.
There are some approaches.
rt listens another signal such as aurelia-timeupdate-signal.
cons: there must be a signal sender somewhere.
no effect to relativeTime()
pros: only one signal sender with only one setInterval()
I can send a PR.
relativeTime updates itself (when an options is given?).
pros: self contained. easy to use. rt updates.
cons: possibly very many setInterval()s
I think 2 is better but not very good. Any idea?
The text was updated successfully, but these errors were encountered: