Wire failure to connect

[Charilaos Skiadas]

Ok I dug in a little deeper into my connect problems, let's see if someone can help me clear it up completely. I suppose at the heart of it I might just need to understand better how the proxies and the magic of connections works. Perhaps I can summarize my question thusly:

If someone or something gets hold of a reference to an object's method during the create/configure/initialize lifecycle stages, would calling that method through this reference no longer activate any of the methods supposedly linked to it during the connect lifecycle stage?
If this is indeed the case, then using Backbone.history is going to be a major pain in the youknowwho.


Here's some more details of my setting:

Anyway, here is the situation, basically. I have one component, whose module is a somewhat standard Backbone.router, and roughly looks like this:

```js
define(['backbone'], function(Backbone) {
return Backbone.Router.extend({
routes: {
"structure/:id" : "getStructure",
...
},
getStructure: function(id) {
this.editStructure(id);
console.log("Structure: ", id);
},
editStructure: function(id) {
console.log("Calling edit")
},
...
startListening: function() {
console.log("Router starting to listen.")
Backbone.history.start();
}
});
});
```

I've omitted things irrelevant to my question. Here is how this is wired into the spec:

mainRouter: {
create: 'js/routers/main',
ready: 'startListening',
connect: {
'getStructure': 'sidebar.highlightActive'
},
},


So startListening is called on ready, and it starts up the history-tracking. When the location bar changes, getStructure is called, however, sidebar.highlightActive which was supposed to be linked to it does not trigger. However, if I change the connect to 'editStructure' instead of 'getStructure', then sidebar.highlightActive will in fact run.

So Backbone must be doing something behind the scenes in the way it is calling getStructure, that somehow bypasses the system wire uses to connect the two, so I think I need a better understanding of how that works.

I suspect that upon its creation, Backbone.router activates the routes method, which turns around and calls the route method for each route, which seems to add some callback function triggers in the Backbone.history object. This all seems to happen before the connect facet gets to run. Could this be the source of the failure to connect?


Haris Skiadas

[Brian Cavalier]

Yeah, that sounds like part of the problem.  If Backbone is storing a direct reference to a function, or using bind() to effectively copy a function, wire has no hope of adding behavior to Backbone's stored copy of that function.  In fact, there is simply no way to achieve that in Javascript today.  In ES6, we could use real Proxies, but that would *only* work if we could get access to the functions *before* Backbone captures/copies them.

One way we may be able to deal with this is to integrate Backbone routing via a wire plugin.  Admittedly, I don't know the first thing about Backbone routing, but my hope is that a wire plugin could control when Backbone is allowed to do its magic.  IOW, the plugin would provide a "routes" facet that you'd use in your wire spec instead of using the Backbone native "routes" property hardcoded into Backbone objects--that's looser coupling anyway.  Also, a wire plugin potentially could abstract the routing implementation entirely, such that other routing plugins could be substituted as long as they all provide the same additions to the wire DSL.

We've bounced around the idea of providing a simple routing plugin for wire out-of-the-box, and then hoping that others router implementors would implement their own versions with the same DSL.  Seems like a fun little project, would you like to give it a go?  I probably have some sample code laying around that implements a simple routing plugin using HTML5 history.  You could use that as a starting point.

[Charilaos Skiadas]

On Jul 9, 2013, at 3:18 PM, Brian Cavalier wrote:

> We've bounced around the idea of providing a simple routing plugin for wire out-of-the-box, and then hoping that others router implementors would implement their own versions with the same DSL. Seems like a fun little project, would you like to give it a go? I probably have some sample code laying around that implements a simple routing plugin using HTML5 history. You could use that as a starting point.

That does sound like a fun project, would love to give it a go. Never really messed with HTML5 history much before, but it's a good time to start. If you've got some notes already they'll help get me started.

In the meantime, I'll just make the router methods turn around and call another "real" version of them, that seemed to work.

Haris Skiadas

[Brian Cavalier]

Awesome, I'll dig up my most recent version of a bare bones wire routing plugin and post it somewhere for you, then we can discuss and see what direction we think is best, how to abstract so that other routing packages can be supported, etc etc.  I'll post a link here once I dig up the code.

[Brian Cavalier]

Ok, here's a slightly cleaned up version of a recent version I did as a test.  I updated it to support the newest (>= wire 0.10) plugin format.  It's totally untested, but hopefully a good place to start coming up with ideas.  I think there are still lots of questions ... even basic ones like: how will people tend to use routing in a wire'd application?

Anyway, this is a good place for us to start discussing.  Def interested in hearing your ideas!

https://gist.github.com/briancavalier/5970232

[Charilaos Skiadas]

On Jul 10, 2013, at 4:03 PM, Brian Cavalier wrote:

> Ok, here's a slightly cleaned up version of a recent version I did as a test. I updated it to support the newest (>= wire 0.10) plugin format. It's totally untested, but hopefully a good place to start coming up with ideas. I think there are still lots of questions ... even basic ones like: how will people tend to use routing in a wire'd application?
>
> Anyway, this is a good place for us to start discussing. Def interested in hearing your ideas!
>
> https://gist.github.com/briancavalier/5970232

Looks very promising already. Do you want to do the discussion in the gist's comments, or on the mailing list?

My current use case: A number of different views need to be notified and change based on the route. Now truth be told they need to have the new state of the data first, so in some sense they wouldn't be listening to the route directly, but instead would probably connect as "after" methods on some model method.

One thing I'd like to see is incorporating the history api more directly, and ideally offer a way to deal with full-fledged location addresses instead of relying on the hash part. But I think that's something one would need to opt-in, as it requires some stuff on the server to be happening.

Haris Skiadas

[Brian Cavalier]

We can discuss either place, although I find gist/github a bit more "code pasting" friendly.

Yeah, this version uses hashchange, but it wouldn't be hard to convert it to use pushState (rather than the hash), which would be nicer for browsers that support it.  Full-fledged location addresses can be tricky since applications can be deployed at different base urls over their lifetime.  E.g. a staging or QA server versus production.  Relative urls usually cause fewer headaches in my experience, but as always, every situation is different.

Like you said, perhaps an opt-in would be ok.

I think starting with pushState would be a great way to go to get something working.

[Charilaos Skiadas]

Hm I left a comment on the gist, but it made me wonder, do we get automatic notifications when comments are added like that, similar to issues? If not, perhaps gists aren't the best place to have a discussion.

> --
> You received this message because you are subscribed to the Google Groups "cujojs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cujojs+un...@googlegroups.com.
> To post to this group, send email to cuj...@googlegroups.com.
> Visit this group at http://groups.google.com/group/cujojs.
> To view this discussion on the web visit https://groups.google.com/d/msgid/cujojs/6bc599f0-3876-48d9-a98c-7a225e9acfe1%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Haris Skiadas

[Brian Cavalier]

Ugh, I didn't get notified :(  Sorry about that.  But wow, did you write a lot!  I'll dig into it no later than tomorrow.

Github's notifications baffle me sometimes ... I'm fine with moving the discussion here.

[Charilaos Skiadas]

Yeah I had a few hours this morning ;) It's mostly brainstorming, some of it might be scattered thoughts.

My guess is github just doesn't do notifications for gists period. Would it make sense to create an issue instead?

> To view this discussion on the web visit https://groups.google.com/d/msgid/cujojs/25f0c628-5420-4ee7-9da7-c58ed0a418b7%40googlegroups.com.

[Brian Cavalier]

Good call.  A github issue it is: https://github.com/cujojs/wire/issues/124

Feel free to copy/paste your gist comment into an issue comment.