Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Justin Meyer
@justinbmeyer
this might be something can.view.live needs a special case to fix
@dylanrtt can you create an issue?
someone can take a look at this
dylanrtt
@dylanrtt
sure
Justin Meyer
@justinbmeyer
just to make sure I see what the problem is ... basically if <option>s are added / removed from the DOM, the selected one is not currently maintained?
just saw your issue ... if you could provide a bit of text around the bug, that would be helpful
(issues that people have to "dive into" to have an idea about what's breaking are fixed a bit slower then ones where it's more immediately obvious)
thanks!
I wonder if this is a problem with normal live-binding
as much as it is w/ two way binding
Chris Gomez
@akagomez
@justinbmeyer Yeah, I read it wrong. I think you’ve got it.
So as new <option>’s are rendered as children of a <select> element they should check their value against the can-value property of the parent <select>?
And add selected to the <option> element.
@justinbmeyer You mean if I rebuild the list of <option> tags with JS in general, will the selected option be marked selected?
Justin Meyer
@justinbmeyer
I don't think it will
I'm not sure
but it should be
Chris Gomez
@akagomez
@justinbmeyer Doesn’t look like it: http://jsbin.com/bazavuxiro/edit?html,js,output
Justin Meyer
@justinbmeyer
what is that supposed to show?
oh
Chris Gomez
@akagomez
If the list of options is rebuilt with the same values the selected element is not shown as selected.
Justin Meyer
@justinbmeyer
it works for me
Chris Gomez
@akagomez
Really? Browser?
Justin Meyer
@justinbmeyer
nm
had to hit autorun
yeah
this is the problem
I suppose that live-binding should check if the parent element is a <select>
and make sure the value is maintained if possible
Chris Gomez
@akagomez
@justinbmeyer If you detach and append the exact same <option> elements, it shows the correctly selected option item: http://jsbin.com/tupodanihu/1/edit?html,js,output
Although I’m not really surprised by that now that I think of it.
Justin Meyer
@justinbmeyer
yeah, b/c of Selected
Chris Gomez
@akagomez
@justinbmeyer Shouldn't registered can.view.attr functions be run when the attribute is added post-render, like this: {{#if panelB}}st-panel-resizable{{/if}}
Matthew Phillips
@matthewp
I have a list of 5 items
I call .destroy() on one of them
I would expect the list to be 4
where is the logic where it gets spliced out of the list?
dylanrtt
@dylanrtt
Matthew Phillips
@matthewp
i think you're right
thanks
espretto
@espretto
hi there, i'm new to gitted and canjs, anybody home?
Chris Gomez
@akagomez
Welcome.
espretto
@espretto
great! could you help me with some canjs basics?
Chris Gomez
@akagomez
I’ll do my best.
espretto
@espretto
i've been working with emberjs and knockoutjs but am still struggling atm with canjs observables/computed attributes - hands on: how do you typically wire up model requests depending on some observable e.g. the route?
as suggested in the docs i created a computed representing the request deferred
can.Map.extend({
   model: null,
    state: 'pending', 

    promise: compute(function () {
      var scope = this,
          promise;

      promise = ConfigModel
        .findOne({
          version: scope.attr('version'),
          title: scope.attr('panoTitle')
        })
        .then(function (model) {
          scope.attr('model', model);
        })
        .always(function () {
          scope.attr('state', promise.state());
        })
        .promise();

      scope.attr('state', promise.state());

      return promise;
    })
});
problem is the promise doesn't evaluate its dependencies until someone binds to it
Chris Gomez
@akagomez
@espretto That’s by design.
espretto
@espretto
makes sense, now..