-
-
Notifications
You must be signed in to change notification settings - Fork 55
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
Error on combination of oneTime & signal binding behavior #176
Comments
@jdanyow Isn't a signal automatically a one-time binding? How should this be handled. |
The combination of signal + one-time was intentionally disabled:
Time to reconsider this limitation... binding perf refactoring is complete. It should be safe to remove this check and allow one-time + signal. Thoughts? |
Obviously, the fix is simple. You are the binding expert. It's your call. |
Will add some tests and get this into the next release. |
Beautiful :) |
works like a charm, Thanks! |
It worked for the above case, but not with
The list get's rendered once, If I add an Should I open separate issue? |
please do- the repeat custom attribute handles oneTime differently than regular bindings |
When trying to use onTime with signal binding as follows:
an error is thrown:
It is useful as explained in example in aurelia-binding-behaviors
"Value converter that uses the current time to convert a record's datetime to a "time ago" value: posted ${postDateTime | timeAgo}. The moment this binding expression is evaluated it will correctly result in posted a minute ago. As time passes, it will eventually become inaccurate..."
So we can use signal to reavaluate the postDateTime that doesn't change.
From my understanding the signal is complementary to the binding and doesn't replace it.
I find it many times useful to manually reevaluate, so oneTime & signal seems like natural solution.
Is there a reason they cannot work together?
Thanks
The text was updated successfully, but these errors were encountered: