Skip to content
This repository has been archived by the owner on Mar 13, 2018. It is now read-only.

Allow filters to express implicit dependencies #53

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nevir
Copy link

@nevir nevir commented Sep 4, 2014

myFilter = {
  filter:    ... // The filter function.
  extraDeps: ... // A function that returns an array of observers.
};

An example of where I'm using it: https://github.com/Polymore/more-routing/blob/master/polymer-expressions.html#L25-33

@nevir nevir changed the title Allow filters to express implicit dependencies. Allow filters to express implicit dependencies Sep 4, 2014
```js
myFilter = {
  filter:    ... // The filter function.
  extraDeps: ... // A function that returns an array of observers.
};
```
@@ -213,6 +213,11 @@
fn = fn.toDOM;
}

var extraDepsFn = fn.extraDeps;
if (fn.filter) {
fn = fn.filter;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we could just put the extraDeps property on function itself? Since in JS that's no big deal. That way the filter would be callable.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that would jive better w/ filters within elements too. I was trying to follow along with toDOM/toModel - not sure whether it's worth it though?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think toDOM/toModel is for two-way bindings. Conceivably they could have different "extra deps"?

@jmesserly
Copy link
Contributor

did you figure out:

// TODO(nevir): Why does this only trigger once if we return a PathObserver?

... seems worth addressing (or at least understanding)

I added my $0.02 but would be great to get thoughts from @rafaelw if he's around :)

@jmesserly
Copy link
Contributor

btw, the general idea here seems reasonable to me (give filters an easy a way to signal other dependencies they might have)

@nevir
Copy link
Author

nevir commented Sep 9, 2014

...I didn't figure that PathObserver vs addPath thing, either. It seems to only occur for a compound observer that already has some paths (and some other conditions I haven't been able to nail down yet...)

@rafaelw
Copy link
Contributor

rafaelw commented Sep 10, 2014

Sorry for the latency.

I just talked with Ian in person. I think the question here is whether
Scott wants to add this feature. If he does, I'm happy to review this.

That said, it seems to me like this is a bit of a band-aid over a larger
problem and since we are holding off no addressing the larger problems, I'd
be tempted to not make stop-gap fixes that we'll have to unroll or support
going forward.

On Tue, Sep 9, 2014 at 12:33 PM, John Messerly notifications@github.com
wrote:

did you figure out:

// TODO(nevir): Why does this only trigger once if we return a PathObserver?

... seems worth addressing.

I added my $0.02 but would be great to get thoughts from @rafaelw
https://github.com/rafaelw if he's around :)


Reply to this email directly or view it on GitHub
#53 (comment)
.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants