-
Notifications
You must be signed in to change notification settings - Fork 422
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
Bug with conditional attribute #2077
Comments
You tried this with master? |
Yes with yesterday master. |
In this case: <some-comp {{#unless allowSome}}disabled{{/unless}}></some-comp> if
|
@whitecolor I get no errors with: test("conditional attributes (#2077)", function(){
can.Component.extend({
tag: 'some-comp',
viewModel: {
define: {
disabled: {
type: 'htmlbool'
}
}
}
});
var template = can.stache("<some-comp {{#unless allowSome}}disabled{{/unless}}></some-comp>");
var map = new can.Map({allowSome: true});
template(map);
map.attr("allowSome", false);
map.attr("allowSome", true);
}); Can you submit a test? |
So the problem was that this was never working great to begin with. However in 2.0, it was working on component initialization because attribute callbacks were called before tag callbacks. This meant that Now this happens after. I'm trying to track down why we made this change, although I think it makes sense that components are invoked first. |
This commit changed each attribute to be added to the front: bdb06d6 This has the effect of making the tag run last because it will be added first. This was added because bindings needed the view-model to be created before they ran. This is no longer the case because can-component sets up bindings itself. So the hack solution is to reverse this. This will bring back compatibility. But the better solution is to be able to handle attributes being added and removed. The better solution isn't easy to write because binding split between components and can/view/bindings. I might make this work with can/view/bindings without components first, and then make components do it and try to share as much code as possible. |
@whitecolor to be clear ... the "good" short term fix for this is to have Having both will allow us to turn off all the view-binding |
Ok thanks, for now I just got rid of such cases in the code. But it would be nice if it would start to work again. |
Closed via #2089 |
In 2.3 (it worked in 2.2):
If
preview
istrue
nextPage
attribute value is string value{nextPage}
, not actually value ofnextPage
in parent scope.Maybe some why to do it with new binding sintax?
test is comming.
The text was updated successfully, but these errors were encountered: