@bmomberger-bitovi I’ll check that, if it works then I don’t need any examples :-)
The
radiochange event in CanJS is the one I was thinking of. You can use it to listen to individual properties that are bound to chacked on different radio buttons in a group: https://canjs.com/doc/can-event-dom-radiochange.html
I have been tooling around with a JSBin and these stache snippets. I had similar problems to yours when my
myVarName property was a gettersetter and didn't update the getter correctly
I mean defined
const MyModel = DefineMap.extend({
seal: false
}, {
'_id': 'any',
...
'myVarName': 'any',
...
});
The type is the same as yours, the radio template is exactly what you were using with checked property binding.
If there is something else going on it's probably an upper level binding. Is your component where this is happening two-way bound to a parent component's property?
also it is fine to use
equal(~myVar.property, 'yes')
Workaround #1 => stores a boolean value and uses an additional variable (just ignore it):
<input type="radio" checked:bind="myVarName" name="myVarName" />
<input type="radio" checked:bind="myVarNameDUMMY" name="myVarName" />Workaround #2 => can store any value, limited to strings only:
<input type="radio" can-value="myVarName" value="first" />
<input type="radio" can-value="myVarName" value="second" />
Check out the converter examples in https://canjs.com/doc/can-stache-converters.examples.input-radio.html
any attempts on using
equal or not caused trouble
Using the
name property could still be causing issues.
no it didn’t work. The first workaround is not the most elegant, but it does work with little effort, at least for two option radios
as you said it looks like somehow on the upper levels something is causing this
but still it looks suspicious
if I find any other evidence I’ll try to replicate it and eventually create an issue :-)
So if I have a parent component A and child components B and C, binding A.foo two way with B.foo and also with C.foo can have unexpected results.
But I think you might have better luck with putting your shared properties like that in an observable state object that gets passed parent-to-child in all cases.
So in the A B and C example above, I want to share foo with two-way into B and C from A, but instead I package up
foo into bar which is observable, and then push bar into B and C using one-way binding to-child.
so if B flips the value of
bar.foo, C will also see it because it's observing the same object.
the value I’m trying to set with the radio button is only important within its model
and is a very weird name:
sellsAllCatalogListings so chances are tha I’m not using the same one on another level and that causes trouble
one thing I noticed today though is a lot of warning because of the old style bindings and an incorrect use of the type in my variables, could a warning be related to this issue?
warning 1:
WARN: can-define: the definition for ok on DefineMap uses a constructor for "type". Did you mean "Type”?
warning2:
WARN: can-stache-bindings: the data binding format {($value)} is deprecated. Use value:bind instead
You should fix that first one, though.
And also give your DefineMap subclasses names. :)