These are chat archives for canjs/canjs

8th
May 2015
Alex
@whitecolor
May 08 2015 11:50
'{document} click' ('{window} blur') global handlers in component events are not removed on element removal (removed event is handled). Probably is it not reprodusable with simple example. What can be the reason?
Alex
@whitecolor
May 08 2015 12:29
I found the reason.
Matthew Phillips
@matthewp
May 08 2015 14:26
what is the reason?
Chris Gomez
@akagomez
May 08 2015 14:57
@justinbmeyer Quick question: In can.List.splice we pass the list of removed items as the oldVal to both the “remove” and “add” event.
https://github.com/bitovi/canjs/blob/master/list/list.js#L333
https://github.com/bitovi/canjs/blob/master/list/list.js#L340
Is that intentional? It could be argued that the “add” event’s oldVal should be undefined since the “remove” event described the newVal as undefined.
Marshall Thompson
@marshallswain
May 08 2015 15:39
@whitecolor can you share what you found?
largoelks
@largoelks
May 08 2015 19:23
I'd like to use the can.route pushstate plugin with IE9. But IE 9 doesn't support pushstate. Can anyone recommend a poloyfill that works well with the plugin?
Matthew Phillips
@matthewp
May 08 2015 19:32
you should be able to use it and it will fall-back to hashchange
largoelks
@largoelks
May 08 2015 19:34
true, but the url will be different for different users/browsers. Right?
Matthew Phillips
@matthewp
May 08 2015 19:38
yeah, but not by much
You can't polyfill pushstate
so for modern browsers you'll have /foo/bar
and in older it will be #!/foo/bar
which isn't bad
it can still be bookmarked
and most importantly you as the developer don't have to do anything special to get this behavior
largoelks
@largoelks
May 08 2015 19:54
@matthewp o.k. the general suggestion is to not ployfill and go with the hash fallback for older browsers? Thank you for the help
Matthew Phillips
@matthewp
May 08 2015 19:59
well, to be clear, it is not possible to polyfill the history api
so it's not really a suggestion as much as you have no other choice :)
Adam L Barrett
@BigAB
May 08 2015 20:47

Has anyone written anything to keep two separate can.Maps in sync, presumably by subscribing to and applying each others change events (or something like that)?

I am specifically thinking of keeping a can map in a web worker in sync with a can map on the main… uhh… thread? Execution context? ...Where the DOM stuff is.

It could also apply to keeping a can.Map on the server in sync with one on the client with a web socket I suppose.

Anyone already write anything like that?

Justin Meyer
@justinbmeyer
May 08 2015 21:19
@BigAB Why?
typically components do this for you
Adam L Barrett
@BigAB
May 08 2015 21:19
Fortune and glory kid, fortune and glory
Justin Meyer
@justinbmeyer
May 08 2015 21:19
yeah, you could probably just dispatch all change events
Adam L Barrett
@BigAB
May 08 2015 21:19
What do you mean, components do this for you?
Justin Meyer
@justinbmeyer
May 08 2015 21:20
well components keep some properties of one component tied to another
however, yeah, you probably want the change event
buuuuuuuut
if you really want fame and fortune
Adam L Barrett
@BigAB
May 08 2015 21:20
fortune and glory
Justin Meyer
@justinbmeyer
May 08 2015 21:20
you get vdom worker threads working
fortune and glory
get vdom worker threads going
and then you run your entire app in a workerthread
we actually have stache running against a vdom
so you only need to get it to send changes to the 'main' thread
and get evens to go the other way
most of the hard work is done
we just need someone to get the glory
@akagomez not sure actually
maybe write up pros and cons in an issue
Adam L Barrett
@BigAB
May 08 2015 21:26
I see what you are saying. Without trying to go into too much detail and spamming this chat room, the idea I was rolling around with was enforcing stricter separation of “Modely-stuff” and “Viewy-stuff” by making the main thread (is thread the right word? Probably not), only handle view-components and rendering stuff, and everything in the web worker does all the Models and fetching and calculations and whatnot, and only updates the “Master View Model” (for lack of a better term)… so that it is very very clear, even for teh Junior devs, what belongs where.
Justin Meyer
@justinbmeyer
May 08 2015 21:27
@BigAB a noble goal, but the problem is now that applications are wired up through the view
all orchestration happens via custom HTML elements
so, you sorta need a "DOM" ish hierarchy so child components know how to talk to parent components and so forth
Adam L Barrett
@BigAB
May 08 2015 21:30
Yes. But I see the possibility of somethign more, “Flux-ish” for lack of a better term. Perhaps I will flesh out my idea’s in a document, write a demo and discuss it with you out of this gitter room.
Justin Meyer
@justinbmeyer
May 08 2015 21:30
also, a VDOM more or less enforces VM + M vs V separation
this gitter room is a fine place to talk about this stuff
VDOM enforces because you can't really talk to the view anyway
Adam L Barrett
@BigAB
May 08 2015 21:30
How does VDOM more or less enforces VM + M vs V separation, I am curious, and nothing leaps to my mind
Justin Meyer
@justinbmeyer
May 08 2015 21:31
because only the View reading the VM/M is really capable of updating itself
meaning, if you were running everything in a worker thread
not on a real dom
you can't really manually do this.element.addEventListener( ... )
or this.element.innerHTML = "foo bar"
the only way to really manipulate the DOM is via live-binding
you really only have Views and View Models ... doing stuff elsewhere is difficult
And, what is CanJS if not already fluxish, but lets you escape it?
if you are only using ViewModels
and wiring them up with components
everything is one directional view-model "change" -> view "change"
only canjs lets you relatively easily escape that:
inserted: function(){ this.element }
Gerard Finnerty
@halcyonandon
May 08 2015 21:35
I ran into an issue, not sure if there's a way to do this... I have an array in my scope, i iterate via {{#each something}} then inside something has an attribute 'id'... when I try to pass that to a child component as <childcomponent someid="{id}"/>, but {id} never gets added to the child scope
however, in my child's template, I can use {{ id }} and it is the correct value... but I don't want to access the parent scope this way
Justin Meyer
@justinbmeyer
May 08 2015 21:36
I know we don't bind to id="{{id}}"
but someid should work
(id and class are protected, we don't setup bindings with them)
Gerard Finnerty
@halcyonandon
May 08 2015 21:38
yeah, i wouldnt even try that, haha, but someid doesn't work for me when passing an array item's attribute like that... im certain the value is correct and there and I'm passing something else that isn't part of the each data and that gets passed correctly'
dylanrtt
@dylanrtt
May 08 2015 21:38
I had that issue today. Instead of <tag personId="{person.id}"></tag>, I had to pass the whole person to read the id from it
Justin Meyer
@justinbmeyer
May 08 2015 21:40
oh
Gerard Finnerty
@halcyonandon
May 08 2015 21:40
i can pass dot notation values without issue, its only when iterating over an array and passing the id of the item that way... i also see the correct value in there when i inspect the dom
Justin Meyer
@justinbmeyer
May 08 2015 21:40
you know you need to do person-id
they need to be hyphened
dylanrtt
@dylanrtt
May 08 2015 21:40
oh yeah! I forgot about that
Gerard Finnerty
@halcyonandon
May 08 2015 21:40
or all lowercase, correct?
i was also surprised I could use {{id}} inside the child's mustache template, even though that attribute isn't defined in the scope (e.g. its accessing the parent's each attributes without passing them)
dylanrtt
@dylanrtt
May 08 2015 21:43
the parent scopes get passed down by default. they added a new property leakScope: false or something that allows you to prevent that
Gerard Finnerty
@halcyonandon
May 08 2015 21:43
oic, good to know, thanks
is there a performance advantage to not leaking scope? i'm explicit with everything that gets passed already
Matthew Phillips
@matthewp
May 08 2015 22:35
There is no performance advantage, it's purely a style thing
Well there could be a performance advantage since there is less scope walking, but I doubt it amounts to much
dylanrtt
@dylanrtt
May 08 2015 22:54
actually, after reading the docs on leakScope and fiddling with it, I'm not sure that's what it does at all
Matthew Phillips
@matthewp
May 08 2015 22:57
that's what it does
it makes it so the use "light dom" cannot access properties on the component's viewModel
dylanrtt
@dylanrtt
May 08 2015 22:59
well I guess if your child component has a template and you don't have user content, it would have the desired effect, but I find it strange how it prevents the user content from reading out of the viewModel
Matthew Phillips
@matthewp
May 08 2015 23:00
it's lexical scope
dylanrtt
@dylanrtt
May 08 2015 23:00
I guess I understand it and see the merits now but the docs on it seem super confusing
Matthew Phillips
@matthewp
May 08 2015 23:01
i don't use it personally, i like my scope leaky :)
Gerard Finnerty
@halcyonandon
May 08 2015 23:24
why do you like it leaky?
asking b/c i'm of the mindset that a component should only be aware of itself, one of the things I appreciate the most about component-driven architecture... if I were to start using a leaky scope, then I create dependencies to the parent(s), where if I just passed what I needed into scope, it would remain clean.
i have a .test.js file inside every component, unit tests render and test only that component... leaky scope would mean I'd need to be aware of the parent-child dependency and the parent would need to be included in all child unit tests (unless i hack in the assumed values inside the child)
Matthew Phillips
@matthewp
May 08 2015 23:47
You wouldn't have to include the parent
but you would have to include the data that your component is looking for
so if it expects {{fruits}} to leak
you have to provide fruits when you render
renderer({ fruits: new Fruit.List() })
but you've articulated the advantages of non-leaky scope well