Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 20 21:58
    justinbmeyer commented #5459
  • Jan 20 07:49
    frank-dspeed opened #5459
  • Jan 19 16:39
    leoj3n commented #5107
  • Jan 19 16:37
    leoj3n commented #5107
  • Jan 19 16:32
    ThomasBrickerBK starred canjs/canjs
  • Jan 18 01:06
    greenkeeper[bot] commented #5422
  • Jan 18 01:06

    greenkeeper[bot] on @feathersjs

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

  • Jan 18 00:48

    greenkeeper[bot] on @octokit

    (compare)

  • Jan 18 00:46

    greenkeeper[bot] on @octokit

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

  • Jan 17 18:14
    patosullivan starred canjs/canjs
  • Jan 17 17:42
    bmomberger-bitovi synchronize #5451
  • Jan 17 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
Ilya Fadeev
@ilyavf
like, with a bind() ?
Justin Meyer
@justinbmeyer
oh, I have to click update to see the problem?
Ilya Fadeev
@ilyavf
yes, u have to click
Justin Meyer
@justinbmeyer
this is most likely b/c of the two-way binding
clicking update changes child's searchTerms, which changes parent's myval, which again tries to change child's searchTerms
oh, those only track one direction
we might need to add the other direction
viewModelPropertyUpdates[searchTerms] will be true only after parent's myval changes
we could have a similar protection coming back the other way
Justin Meyer
@justinbmeyer
basically when parent CHANGES child ... we protect against child then changing the parent
but when child CHANGES parent ... we don't currently protect the parent from trying to change the child as a result
Ilya Fadeev
@ilyavf
what line would this be ("when child changes parent")?
Justin Meyer
@justinbmeyer
this is something for @daffl to be aware of
that's the code that runs when a child's viewModel is changed
easier to read in minor
b/c variables are properly called viewModel there
that code is what listens to the child viewModel and sets up two-way binding
well, the child -> parent binding
that code listens on the value passed to the component ... essentially setting up parent -> child binding
Ilya Fadeev
@ilyavf
@justinbmeyer If I wrap line https://github.com/bitovi/canjs/blob/minor/component/component.js#L171 into an if statement (componentScope[name] !== newVal) this should fix it, right?
Justin Meyer
@justinbmeyer
That would not be a good fix
  • it would not be correct ... it's possible that a setter or getter exists on this property, that what you read there wouldn't be accurate.
  • it's best to never access property values directly on can.maps
also, in reality ... can.Map already has internal checks for this
the setter is still called
but an event wont be produced
all we are doing here is making sure sets aren't called unnecessarily
btw, is this causing a real problem in your app?
if so ... that makes me think your setter has strange side-effects
Ilya Fadeev
@ilyavf
i had to put a fix (manually check in my setter if current value is different from a prev one)
Justin Meyer
@justinbmeyer
why?
if the setter returned the same value
no events would be triggered
Ilya Fadeev
@ilyavf
it does have a side effect
Justin Meyer
@justinbmeyer
why?
what is it doing?
Ilya Fadeev
@ilyavf
so, there is an array of searchTerms that I want to filter grid data against
i guess, i should use a derived list listening to searchTerms
Justin Meyer
@justinbmeyer
side-effectual setters aren't necessarily a bad thing, I've used them a lot .. like in the make-model-year example
however, those tend to be calling other local setters
so even if things are called multiple times, my code would not be effected
Ilya Fadeev
@ilyavf
would it be a better pattern to use getters instead of a side-effect setters?
Justin Meyer
@justinbmeyer
yes, I think so
imo, it's more clear
but sometimes you need a setter
but I think @daffl created an issue about the 'double set' problem in a component