-
Notifications
You must be signed in to change notification settings - Fork 6
proposal: simplify api #345
Comments
I'm not super into the global refs part of this proposal, but I don't mind. I'm worried about throwing an error when unset, I think that would make it more difficult to use waitForProperty in a task. Which is one nice way to hold off on performing some action until the element exists. |
|
I'm not sure how returning |
why it shoud throw error if property does not set? updated approach don't set any properties on instnces, only define custom getter on existing property |
You can also omit the ref name you accept in the decorator and use the component property name.
|
We could go this ways:
where
{{ref "field"}}
will be transformed to{{ref this "field"}}
,and
@ref
decorator will control property access (and will throw error if property does not yeat setted), it should fix all tracked issues.one more interesting thing, we can share refs between components (we could add ability to have "global" refs), in this case, we will use
@ref("field")
to access ref-bucket, and we can introduce{{ref-for "field"}}
helper, and it can return actual dom node, with same ref.it may be
{{global-ref "footer"}}
,@globalRef("footer")
,{{global-ref-to "footer"}}
in therory "ref-bucket" approach may simplify dom ref usages for template-only components, for example
example: https://github.com/lifeart/ember-ref-bucket
quite straightforward usage, we will patch
getNode
method onthis
during modifier initialization, and getNode will return value or null.and check for
this.node
property descriptior (it shoud be simple, without getters/setters )@jrjohnson @simonihmig @wycats what do you think? Any suggestions, additions?
// related duscussion -#232
The text was updated successfully, but these errors were encountered: