Code Monkey home page Code Monkey logo

Comments (4)

fricke avatar fricke commented on August 28, 2024

Actually, I'm sorry, the proto is still there, it's just has different properties than what it had before it was passed. Here's what it has after it's passed to the child context:

defineGetter: function defineGetter() { [native code] }
defineSetter: function defineSetter() { [native code] }
lookupGetter: function lookupGetter() { [native code] }
lookupSetter: function lookupSetter() { [native code] }
constructor: function Object() { [native code] }
hasOwnProperty: function hasOwnProperty() { [native code] }
isPrototypeOf: function isPrototypeOf() { [native code] }
propertyIsEnumerable: function propertyIsEnumerable() { [native code] }
toLocaleString: function toLocaleString() { [native code] }
toString: function toString() { [native code] }
valueOf: function valueOf() { [native code] }

Before:

constructor: function (){ return parent.apply(this, arguments); }
getImageCount: function (){
getLinkData: function (type){
init: function (){
parse: function (response){
url: function () {
proto: ctor

I basically lose all those methods and also anything up the proto chain since afterwards it only has one level. I'm going to start stepping through the code, but maybe we just need to go up the chain further to preserve the object.

from wire.

briancavalier avatar briancavalier commented on August 28, 2024

Hey @fricke,

Thanks for all the info, and for digging a bit deeper!

The issue here is that when calling the injected showCard method, it considers its argument to be a wire spec, coupled with the fact that plain objects in a wire spec are treated as a scoping construct. Wire descends into the object while parsing, and creates a new nested scope (which can contain it's own plugins, etc). That scope is just an object itself, but one created by wire.

Since wire itself doesn't know anything about backbone, a backbone model just looks like a plain object, and wire attempts to parse it as a nested scope. So, you end up with an object that looks kind of like the original backbone model, but is actually a wire scope object.

The same thing would happen if you tried to put a backbone model instance directly into your child spec, for example. Wire would parse it as if it was a scope.

So, the question is what can you accomplish passing your backbone model through? I haven't tried it with a backbone models specifically, but wire's literal factory should work here:

this.showCard({ data: { literal: model } });

The literal factory means "don't try to parse the right-hand-side", and so will leave the model untouched. What you should end up with, after parsing, is data: model, and you would still reference it as { $ref: 'data' } in your child spec.

Let me know if that works. If not, we can dig in a bit more to find a solution, which may involve writing a wire plugin to help do what you need.

BTW, did you write your own jQuery wire plugin? I notice you're loading wire/jquery, and have $ref: '$!#var_detail'. If so, very cool. There's one in wire's dev branch, so maybe we could discuss pulling some of your plugin's features into it for an upcoming release?

Good luck!
Brian

from wire.

fricke avatar fricke commented on August 28, 2024

Brian,
Thank you so much, that worked and makes complete sense. Benefit from this exercise is that I got to step through a lot of the code and understand what's going on, just getting to the place where it was creating the items in a wired scope and wondering how to keep the proto chain. But this solution makes way more sense since it marks it as a "leave me alone" type object.

As for the wire/jquery plugin, my coworker Jaime created that in a flash and it doesn't really have features, it's just to give us the object $. I'd say we'll probably just move over to your plugin instead once it's ready. However, if we do need/add features in the meantime I'd be more than happy to pull our resources together.

Thanks again

Chris

from wire.

briancavalier avatar briancavalier commented on August 28, 2024

Great, glad to hear that worked out, Chris.

We're pulling together a release for early next week that will have a wire/jquery/dom plugin that provides a ref resolver for dom nodes using jQuery, which sounds exactly like what Jaime created. Hopefully, it'll be seamless if you switch over to it. The only difference might be that we made the syntax match the wire/dojo/dom plugin: $ref: 'dom.query!<selector>'.

We can compare notes once v0.7.4 is out :)

from wire.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.