Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 18:14
    patosullivan starred canjs/canjs
  • 17:42
    bmomberger-bitovi synchronize #5451
  • 17:42

    bmomberger-bitovi on update-deps

    update can-view-live, can-dom-m… (compare)

  • Jan 16 00:11
    greenkeeper[bot] labeled #5458
  • Jan 16 00:11
    greenkeeper[bot] opened #5458
  • Jan 16 00:11

    greenkeeper[bot] on can-simple-dom-1.7.1

    fix(package): update can-simple… (compare)

  • Jan 14 01:51
    likun7981 starred canjs/canjs
  • Jan 13 14:06
    piraz starred canjs/canjs
  • Jan 11 00:56
    KonTrax starred canjs/canjs
  • Jan 10 02:37
    jlburke starred canjs/canjs
  • Jan 09 04:17
  • Jan 09 04:17
    bbbbbroot starred canjs/canjs
  • Jan 06 18:58
    greenkeeper[bot] commented #5442
  • Jan 06 18:58

    greenkeeper[bot] on can-view-live-5.0.3

    fix(package): update can-view-l… (compare)

  • Jan 06 18:29
    greenkeeper[bot] opened #5457
  • Jan 06 18:29

    greenkeeper[bot] on can-dom-mutate-2.0.8

    fix(package): update can-dom-mu… (compare)

  • Jan 06 05:48
    frank-dspeed edited #5456
  • Jan 06 05:41
    frank-dspeed edited #5456
  • Jan 06 05:34
    frank-dspeed edited #5456
  • Jan 06 05:31
    frank-dspeed opened #5456
Brad Momberger
@bmomberger-bitovi
Yes
Nico R.
@nriesco
thanks!!
Nico R.
@nriesco

I have these two options:

<input type="radio" checked:bind="myVarName" name="myVarName" />      
<input type="radio" checked:bind="not(~myVarName)" name="myVarName" />

Only the first one is clickable.

  • Click on the first one => it will be perfectly selected
  • Click on the second one => it will de-select the first one but not select the second one

Do you see anything wrong here?
Thanks

Brad Momberger
@bmomberger-bitovi
We should be able to support named radio groups just fine without a manual binding on checked. (I filed the original issue some time last year and I know work was done on it)
Try this:
<input type="radio" value:bind="myVarName" value="true" name="myVarName" />      
<input type="radio" value:bind="myVarName" value="" name="myVarName" />
Nico R.
@nriesco
doing that made none of the radio buttons to be clickable
radio1.gif
Brad Momberger
@bmomberger-bitovi
Hm. That might be a weird two-way bind thing, but this should work instead:
    <input type="radio" on:change:value:to="myVarName" value="true" name="myVarName" />      
    <input type="radio" on:change:value:to="myVarName" value="" name="myVarName" />
Nico R.
@nriesco
is there any simple example so I can use that as the base code for my app? I can also change the value stored to a text string instead of a boolean if that makes it easier
@bmomberger-bitovi I’ll check that, if it works then I don’t need any examples :-)
Brad Momberger
@bmomberger-bitovi
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
Nico R.
@nriesco
mmm it is possible to select the value but it won’t load it when editing. Also it will set the first one as false and the second option as false...
Brad Momberger
@bmomberger-bitovi
That, I guess, is the opposite of what we were thinking of.
Nico R.
@nriesco
very weird
Brad Momberger
@bmomberger-bitovi
OK, so I think that what may be going wrong here is in your view model
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
Nico R.
@nriesco
my myVarName is set like this in the viewmodel: ’myVarName': 'any’,
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?
Nico R.
@nriesco
is it ok to use this syntax: equal(~myVar.property, 'yes’) I saw your example and it works but mine is still not working..
Nico R.
@nriesco
@bmomberger-bitovi I found two workarounds, but I can't figure out how can-value works on canjs 3.
Brad Momberger
@bmomberger-bitovi
can-value is still technically supported but it shouldn't work any differently from value:bind
also it is fine to use equal(~myVar.property, 'yes')
Nico R.
@nriesco

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" />
Brad Momberger
@bmomberger-bitovi
Nico R.
@nriesco
those two worked perfectly fine, loading the already contained value, changing ok and setting the new value
any attempts on using equal or not caused trouble
Brad Momberger
@bmomberger-bitovi
They may not be compatible with named groups.
Using the name property could still be causing issues.
Nico R.
@nriesco
let me check
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 :-)
Brad Momberger
@bmomberger-bitovi
Did you ever say whether the keys in questions were bound to parent component values?
Nico R.
@nriesco
I didn’t mention it but yes there is some binding to parent components.
Brad Momberger
@bmomberger-bitovi
OK. One thing I know has been a problem in the past is multiple two-way bindings.
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.
Nico R.
@nriesco
that is definitely my case
Brad Momberger
@bmomberger-bitovi
OK. So you definitely did the right thing with setting the type to "any" in this child component (in my own experience, the worst thing is dealing with multiple type conversions)
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.
Nico R.
@nriesco
the thing is that I don’t have many problems because the binding is mostly to set query conditions to sub elements.. I build a form from several tables each represented by a component, so you can have as many components as you want press save and all gets updated
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