New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing jQuery object as data argument to this.trigger in debug mode fails #38

Closed
alex-seville opened this Issue Feb 11, 2013 · 9 comments

Comments

Projects
None yet
6 participants
@alex-seville
Contributor

alex-seville commented Feb 11, 2013

While in debug mode, trigger attempts a window.postMessage with the data argument of the trigger call. If this data is a jQuery object, the call (sometimes, maybe always?) fails because the object is not serializable into JSON.

However, the jQuery trigger method can take jQuery objects as data, and if I disable debug mode it works in Flight as well.

The relevant line is here: https://github.com/twitter/flight/blob/master/lib/component.js#L70

I would have submitted a PR but I'm not sure the best way to handle this situation (maybe check if data instanceof jquery and don't throw an error if it is?).

@angus-c

This comment has been minimized.

Show comment
Hide comment
@angus-c

angus-c Feb 11, 2013

Collaborator

We did this to discourage passing of functions between components. Allowing a component's functionality to be invoked, by proxy, elsewhere compromises the isolation of a function - making testing more tricky and inviting model complexity.

You can run with debug off if this is not a concern to you. Curious what your use case for passing a jQuery object is

Collaborator

angus-c commented Feb 11, 2013

We did this to discourage passing of functions between components. Allowing a component's functionality to be invoked, by proxy, elsewhere compromises the isolation of a function - making testing more tricky and inviting model complexity.

You can run with debug off if this is not a concern to you. Curious what your use case for passing a jQuery object is

@alex-seville

This comment has been minimized.

Show comment
Hide comment
@alex-seville

alex-seville Feb 11, 2013

Contributor

I was refactoring code (converting it to Flight components), so the passing of a jQuery object was just part of that process. I've since refactored that bit of code and moved it into a ui component, so there's no passing of any objects, but I found it curious that I was getting different results depending on whether Debug was enabled or not.

So is the reason it's discouraged, rather than explicitly forbidden in the code, because you're waiting to see if people have use cases for passing jQuery objects?

Contributor

alex-seville commented Feb 11, 2013

I was refactoring code (converting it to Flight components), so the passing of a jQuery object was just part of that process. I've since refactored that bit of code and moved it into a ui component, so there's no passing of any objects, but I found it curious that I was getting different results depending on whether Debug was enabled or not.

So is the reason it's discouraged, rather than explicitly forbidden in the code, because you're waiting to see if people have use cases for passing jQuery objects?

@angus-c

This comment has been minimized.

Show comment
Hide comment
@angus-c

angus-c Feb 11, 2013

Collaborator

No - the reason it is only forbidden in debug mode is so it is caught in development. We didn't want such tests in production because of inconsistent cross browser support and the additional (albeit slight) overhead of the postMessage.

Was asking about passing jQuery object in case there was a good use case that we had overlooked. Disallowing non-serializable payloads was primarily targeted at discouraging function payloads - but I'm not seeing a good use case for passing jQuery objects either (not saying there isn't one - just not seeing one)

Collaborator

angus-c commented Feb 11, 2013

No - the reason it is only forbidden in debug mode is so it is caught in development. We didn't want such tests in production because of inconsistent cross browser support and the additional (albeit slight) overhead of the postMessage.

Was asking about passing jQuery object in case there was a good use case that we had overlooked. Disallowing non-serializable payloads was primarily targeted at discouraging function payloads - but I'm not seeing a good use case for passing jQuery objects either (not saying there isn't one - just not seeing one)

@alex-seville

This comment has been minimized.

Show comment
Hide comment
@alex-seville

alex-seville Feb 11, 2013

Contributor

Good to know.

Contributor

alex-seville commented Feb 11, 2013

Good to know.

@simonsmith

This comment has been minimized.

Show comment
Hide comment
@simonsmith

simonsmith Mar 14, 2013

@angus-c I have an Ajax mixin that triggers an event with the arguments from beforeSend, complete etc and one of those is the jqXHR object. Obviously I'm hitting the same issue as that object contains methods.

Is this something you would not expect to be passed between components?

simonsmith commented Mar 14, 2013

@angus-c I have an Ajax mixin that triggers an event with the arguments from beforeSend, complete etc and one of those is the jqXHR object. Obviously I'm hitting the same issue as that object contains methods.

Is this something you would not expect to be passed between components?

@angus-c

This comment has been minimized.

Show comment
Hide comment
@angus-c

angus-c Mar 14, 2013

Collaborator

@simonsmith—basically this #38 (comment)
We don't want to compromise the decoupling of components. Limiting their external object dependencies to simple hashes, primitives etc. keeps them detangled and easily testable.

Collaborator

angus-c commented Mar 14, 2013

@simonsmith—basically this #38 (comment)
We don't want to compromise the decoupling of components. Limiting their external object dependencies to simple hashes, primitives etc. keeps them detangled and easily testable.

@danse

This comment has been minimized.

Show comment
Hide comment
@danse

danse Apr 4, 2013

i found the same problem. I was sending some components in an event in order to add them to an (already initialized) form component. Either i send them to the container component somehow, or i have to import (require) them in the container component and send just the path. i thought that the first solution was more elegant but now i see it is discouraged

danse commented Apr 4, 2013

i found the same problem. I was sending some components in an event in order to add them to an (already initialized) form component. Either i send them to the container component somehow, or i have to import (require) them in the container component and send just the path. i thought that the first solution was more elegant but now i see it is discouraged

@boschni

This comment has been minimized.

Show comment
Hide comment
@boschni

boschni Apr 13, 2013

I've ran into the same problem. I want to automatically initialize all Flight components within a specific DOM node with my ComponentInitializer component. The ComponentInitializer will search for uninitialized Flight components within a given DOM node, and initializes them automatically.

But before the components are initialized, I want to trigger a "before initialization event" so that other (existing) components have the ability to process/modify the DOM node (the context) before the Flight components within it are initialized. Because of this, I need to send the node together with the "ComponentInitializer:beforeInitializeContext" event like this:

this.trigger('ComponentInitializer:beforeInitializeContext', { context: context });

Unfortunately, Flight throws an error because the context property (the DOM node) is not serializable. Would this be a valid use case or am I moving in the wrong direction?

boschni commented Apr 13, 2013

I've ran into the same problem. I want to automatically initialize all Flight components within a specific DOM node with my ComponentInitializer component. The ComponentInitializer will search for uninitialized Flight components within a given DOM node, and initializes them automatically.

But before the components are initialized, I want to trigger a "before initialization event" so that other (existing) components have the ability to process/modify the DOM node (the context) before the Flight components within it are initialized. Because of this, I need to send the node together with the "ComponentInitializer:beforeInitializeContext" event like this:

this.trigger('ComponentInitializer:beforeInitializeContext', { context: context });

Unfortunately, Flight throws an error because the context property (the DOM node) is not serializable. Would this be a valid use case or am I moving in the wrong direction?

@traviskaufman

This comment has been minimized.

Show comment
Hide comment
@traviskaufman

traviskaufman Feb 3, 2015

can't pass FormData either, making decoupling data and ui for a "File Upload" component pretty tricky

traviskaufman commented Feb 3, 2015

can't pass FormData either, making decoupling data and ui for a "File Upload" component pretty tricky

@flightjs flightjs locked and limited conversation to collaborators Feb 4, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.