-
-
Notifications
You must be signed in to change notification settings - Fork 408
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
Optional closure actions #90
Comments
I guess a 4th possibility would simply to allow undefined actions being passed into the |
I think #3 is the right solution:
App.OptionalActionHelper = Ember.Helper.helper(function([action]) {
return action || function() { };
}); |
@rwjblue I hadn't thought of just returning an empty function, great idea! My idea for #3 was that it would call through to the {{x-foo fire-away=(action (optional-action 'foo') baz)}} would be {{x-foo fire-away=(optional-action 'foo' baz)}} but yours is much nicer/cleaner as just a separate helper! Wonder if this should be built-in, or at least documented with closure actions as it seems like something which would be fairly common (unless I'm the only one doing this!). |
Closing this for now, the helper solution works perfectly. Maybe in future a similar helper / syntactic sugar could be built-in but it's trivial to add to an app in the meantime. |
RFC for caching results of `treeFor` hook
Short version
Closure actions break if you give them an undefined value, making it impossible to have optional actions:
Long Version
Consider a hypothetical image component which sends an action when it's loaded:
Now consider an image-list component which displays a list of images:
So far so good, now this component wants to just pass the loaded event up to its parent component.
Nice and easy to do with closure actions:
This is called as so:
But we don't want to require having
on-image-loaded
being passed in, this now breaks:I know, we'll make the action optional:
No dice,
(if)
isn't lazily evaluated, so the(action)
helper gets called withundefined
regardless.Now we're stuck, we can't use closure actions anymore and have to go back to using
(action "imageLoaded")
andsendAction
which is happy if the action isn't wired up.Possible Solutions
In order of personal preference:
1. Make
(if)
lazily evaluateCurrently the
(if)
helper executes both branches before testing (as helpers receive values and not streams), regardless of whether the predicate is interpreted as true or false.If this instead lazily evaluated then it would be safe to use the
action
keyword inside anif
as theaction
keyword would only be called if valid:2. Add
optional=true
flag toaction
keywordThis would disable the checks in the
action
keyword.I personally prefer this to 3. because it doesn't require an entirely new keyword but still makes it clear what's going on.
3. Add
(optional-action)
helper/keywordThis simply guards against undefined actions before passing along to the action keyword, but is an entirely new helper/keyword just for a guard clause
The text was updated successfully, but these errors were encountered: