Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:50
    chasenlehara opened #5462
  • 10:48

    chasenlehara on chasenlehara-patch-1

    Upgrade to can-queues@1.3.2 (compare)

  • 10:41

    chasenlehara on can-simple-dom-1.7.1

    (compare)

  • 10:41
    chasenlehara closed #5458
  • 10:40

    chasenlehara on can-stache-bindings-5.0.4

    (compare)

  • 10:40
    chasenlehara closed #5455
  • 10:40

    chasenlehara on can-stache-5.1.0

    (compare)

  • 10:40
    chasenlehara closed #5453
  • 10:40

    chasenlehara on can-map-4.3.12

    (compare)

  • 10:40
    chasenlehara closed #5452
  • 10:40

    chasenlehara on can-super-model-2.0.0

    (compare)

  • 10:40
    chasenlehara closed #5449
  • 10:40

    chasenlehara on can-define-rest-model-2.0.0

    (compare)

  • 10:40
    chasenlehara closed #5448
  • 10:39

    chasenlehara on can-define-realtime-rest-model-2.0.0

    (compare)

  • 10:39
    chasenlehara closed #5447
  • 10:39

    chasenlehara on can-connect-ndjson-2.0.0

    (compare)

  • 10:39
    chasenlehara closed #5446
  • 10:39

    chasenlehara on can-observable-mixin-1.0.7

    (compare)

  • 10:39
    chasenlehara closed #5444
Nico R.
@nriesco
is attending a function? if not can I just use a property?
I tried equal(~myVar, true) but it won’t work
Brad Momberger
@bmomberger-bitovi
~ means pass that argument into the function call as a compute. This is important for two-way binding with can-stache-converters because you'd need to update the value of attending when the radio changes.
Nico R.
@nriesco
also: can I bind something to a variable’s “not” value? checked:bind=“!loading” for instance?
Brad Momberger
@bmomberger-bitovi
checked:bind=“not(~loading)”
Nico R.
@nriesco
@bmomberger-bitovi so that would be the opposite of checked:bind=“loading”?
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)