Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 06 18:40
    cherifGsoul review_requested #5441
  • Dec 06 18:39
    cherifGsoul opened #5441
  • Dec 06 18:22

    cherifGsoul on update-infrastructure-page

    Update infrastructure page with… (compare)

  • Dec 06 18:14
    greenkeeper[bot] commented #5422
  • Dec 06 18:14

    greenkeeper[bot] on @feathersjs

    chore(package): update @feather… (compare)

  • Dec 06 18:11
    greenkeeper[bot] commented #5401
  • Dec 06 18:11

    greenkeeper[bot] on @feathersjs

    chore(package): update @feather… (compare)

  • Dec 04 22:03
    chasenlehara opened #5440
  • Dec 04 22:03
    chasenlehara labeled #5440
  • Dec 04 19:18
    cherifGsoul review_requested #5432
  • Dec 04 14:09
    m-ahmadi starred canjs/canjs
  • Dec 04 10:52
    ansyeow starred canjs/canjs
  • Dec 03 14:53
    matthewp commented #5439
  • Dec 03 14:30
    frank-dspeed opened #5439
  • Dec 02 18:13
    greenkeeper[bot] commented #5392
  • Dec 02 18:13

    greenkeeper[bot] on core-js-3.4.7

    chore(package): update core-js … (compare)

  • Dec 02 17:48
    greenkeeper[bot] commented #5392
  • Dec 02 17:48

    greenkeeper[bot] on core-js-3.4.6

    chore(package): update core-js … (compare)

  • Dec 02 15:38
    phillipskevin commented #5438
  • Dec 02 15:38
    phillipskevin closed #5438
Nico R.
@nriesco
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
Brad Momberger
@bmomberger-bitovi
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
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
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
what do you mean?
Brad Momberger
@bmomberger-bitovi
DefineMap.extend("NameForThisMap", { ... })
Nico R.
@nriesco
otherwise I’m extending the whole DefineMap class for the whole app?
Brad Momberger
@bmomberger-bitovi
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.
Nico R.
@nriesco
oh, I see you refer to the warning I got, thanks a lot, that shuld definitely make thinks easier to track
Morgan Heimbeck
@Xitstrategies
@justinbmeyer I am just waiting to hear from you on canjs/can-ajax#13 If there is someone who can give me a brief run down or document on what all I need to do to document my pull request change, let me know.
Brad Momberger
@bmomberger-bitovi