These are chat archives for canjs/canjs

5th
Oct 2017
Nico R.
@nriesco
Oct 05 2017 20:10

In this example:

https://canjs.com/doc/can-stache-converters.examples.input-radio.html#Bindingtoaselectedvalue

What exactly is the ~ in here: <input type='radio' checked:bind="equal(~attending, 'no')" />

Thanks

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
Oct 05 2017 20:13
~ 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
Oct 05 2017 20:13
also: can I bind something to a variable’s “not” value? checked:bind=“!loading” for instance?
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 20:13
checked:bind=“not(~loading)”
Nico R.
@nriesco
Oct 05 2017 20:14
@bmomberger-bitovi so that would be the opposite of checked:bind=“loading”?
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 20:14
Yes
Nico R.
@nriesco
Oct 05 2017 20:14
thanks!!
Nico R.
@nriesco
Oct 05 2017 20:40

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
Oct 05 2017 20:41
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
Oct 05 2017 20:45
doing that made none of the radio buttons to be clickable
radio1.gif
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 20:53
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
Oct 05 2017 20:54
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
Oct 05 2017 20:57
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
Oct 05 2017 20:57
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
Oct 05 2017 20:57
That, I guess, is the opposite of what we were thinking of.
Nico R.
@nriesco
Oct 05 2017 20:58
very weird
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 21:08
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
Oct 05 2017 21:13
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
Oct 05 2017 22:05
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
Oct 05 2017 23:08
@bmomberger-bitovi I found two workarounds, but I can't figure out how can-value works on canjs 3.
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 23:08
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
Oct 05 2017 23:09

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
Oct 05 2017 23:10
Nico R.
@nriesco
Oct 05 2017 23:10
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
Oct 05 2017 23:11
They may not be compatible with named groups.
Using the name property could still be causing issues.
Nico R.
@nriesco
Oct 05 2017 23:12
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
Oct 05 2017 23:17
Did you ever say whether the keys in questions were bound to parent component values?
Nico R.
@nriesco
Oct 05 2017 23:28
I didn’t mention it but yes there is some binding to parent components.
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 23:29
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
Oct 05 2017 23:30
that is definitely my case
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 23:31
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
Oct 05 2017 23:34
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
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 23:36
Having something with the same name in a parent component shouldn't be an issue. We don't let components leak scope by default
Nico R.
@nriesco
Oct 05 2017 23:38
thats good to know
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
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 23:41
I worked on both of those warning messages, and it's unlikely that the second one is causing a problem.
You should fix that first one, though.
And also give your DefineMap subclasses names. :)
Nico R.
@nriesco
Oct 05 2017 23:43
what do you mean?
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 23:43
DefineMap.extend("NameForThisMap", { ... })
Nico R.
@nriesco
Oct 05 2017 23:45
otherwise I’m extending the whole DefineMap class for the whole app?
Brad Momberger
@bmomberger-bitovi
Oct 05 2017 23:53
no, it just doesn't change the name on the constructor
If you extend a DefineMap without a name, it's still got "DefineMap" as the name
which can make it harder to track down "the definition for ok on DefineMap"
can-component actually generates names for the DefineMap subclass if you pass plain objects (i.e. DefineMap prototypes) in as the viewModel
I'm not saying to do that. I am saying, when you extend a DefineMap, it's good practice to give the extended map a name.