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

Cannot export a component's prototype function to the references scope #2051

Closed
dylanrtt opened this Issue Nov 2, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@dylanrtt
Contributor

dylanrtt commented Nov 2, 2015

I should be able to export a function from a component like this:

<foo-bar {^@foo}="*bar"></foo-bar>
{{*bar()}}

It should work for functions defined on the component's viewmodel or the viewmodel's prototype, but neither seems to work.

http://jsbin.com/zumebacuma/edit?html,js,console,output

@justinbmeyer justinbmeyer added the bug label Nov 2, 2015

@justinbmeyer justinbmeyer added this to the 2.3.2 milestone Nov 3, 2015

justinbmeyer added a commit that referenced this issue Nov 3, 2015

@daffl daffl closed this in #2055 Nov 4, 2015

@dylanrtt

This comment has been minimized.

Show comment
Hide comment
@dylanrtt

dylanrtt Nov 5, 2015

Contributor

I gave this a try on master and the foo function is running 3 times, or just twice if {{*bar()}} is removed. The whole point is that it shouldn't be running at all with @.

http://jsbin.com/pezologeyi/edit?html,js,console,output

I also tried using the function on the viewmodel instance instead of the prototype method and that doesn't work (never runs). I know it's not mentioned in title of this issue but I think that should work too if it's not too much trouble.

Contributor

dylanrtt commented Nov 5, 2015

I gave this a try on master and the foo function is running 3 times, or just twice if {{*bar()}} is removed. The whole point is that it shouldn't be running at all with @.

http://jsbin.com/pezologeyi/edit?html,js,console,output

I also tried using the function on the viewmodel instance instead of the prototype method and that doesn't work (never runs). I know it's not mentioned in title of this issue but I think that should work too if it's not too much trouble.

@justinbmeyer justinbmeyer reopened this Nov 5, 2015

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Nov 5, 2015

Contributor

arg. will look at it.

Contributor

justinbmeyer commented Nov 5, 2015

arg. will look at it.

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Nov 8, 2015

Contributor

The problem here seems to be that a compute is built around *refKey:

{^@method}='*refKey' 

So, when the reference scope's *refKey vale is set, the compute tries to update its internal value. So, it tries to read *refKey instead of @*refKey.

I'm not sure what the best solution is. One possibility is to get people to write (and make this work):

<foo-bar {^@foo}="@*bar"></foo-bar>

I think this makes sense because this is what would have to be written if two-way binding a function was ever to be done. Ugly, but works.

Alternatively, I could special case one way bindings to not create a compute around the value that is going to be set.

I might need to make both work.

Contributor

justinbmeyer commented Nov 8, 2015

The problem here seems to be that a compute is built around *refKey:

{^@method}='*refKey' 

So, when the reference scope's *refKey vale is set, the compute tries to update its internal value. So, it tries to read *refKey instead of @*refKey.

I'm not sure what the best solution is. One possibility is to get people to write (and make this work):

<foo-bar {^@foo}="@*bar"></foo-bar>

I think this makes sense because this is what would have to be written if two-way binding a function was ever to be done. Ugly, but works.

Alternatively, I could special case one way bindings to not create a compute around the value that is going to be set.

I might need to make both work.

justinbmeyer added a commit that referenced this issue Nov 9, 2015

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Nov 9, 2015

Contributor

Ok, so I made this work right now the ugly way: <foo-bar {^@foo}="@*bar"></foo-bar>. I'm not happy with this. But it will at least let you move forward and us get out a 2.3.2.

To make it work without the double @, it seems to require a bit of additional code.

Currently, we know which context to set because we always read the current value and set the first context that has a value. If no context has a value we set the top of the scope.

To set a value, we'd need some similar logic, but something that is able to tell if a property is in some context of the scope without actually reading it.

Essentially, I would need some type of "scope.hasOwnProperty". But this would extend to can.compute.read and eventually to maps.

This is a problem I've know about, but it wasn't a problem because computes were always read first, so the set context was known. Always seemed like a cheat.

Contributor

justinbmeyer commented Nov 9, 2015

Ok, so I made this work right now the ugly way: <foo-bar {^@foo}="@*bar"></foo-bar>. I'm not happy with this. But it will at least let you move forward and us get out a 2.3.2.

To make it work without the double @, it seems to require a bit of additional code.

Currently, we know which context to set because we always read the current value and set the first context that has a value. If no context has a value we set the top of the scope.

To set a value, we'd need some similar logic, but something that is able to tell if a property is in some context of the scope without actually reading it.

Essentially, I would need some type of "scope.hasOwnProperty". But this would extend to can.compute.read and eventually to maps.

This is a problem I've know about, but it wasn't a problem because computes were always read first, so the set context was known. Always seemed like a cheat.

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Nov 9, 2015

Contributor

I'm going to add some docs for this ugly way until #2065 is working.

Contributor

justinbmeyer commented Nov 9, 2015

I'm going to add some docs for this ugly way until #2065 is working.

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