iron-meta
iron-meta copied to clipboard
Notify elements of the same type that some data has changed.
Hi! I have iron-metas in different elements. One is producing data and another is listening to changes. As I figured out consumer doesn't have any way to listen to changes. Am I right?
+1
what??? I have the same need, I don't understand that it is not supported...
Any plans to actually solve this? (Or should we implement our own meta element?)
(And mentioning this restriction in the documentation would have saved me half a day of debugging...)
@albinrangefelt you can take a look at this one: https://github.com/akc42/akc-meta
I've been looking into this for myself, and I have some questions.
- Is the expectation that
iron-meta
should only notifyiron-meta-query
elements, or that they should also notify otheriron-meta
elements? Is it even reasonable to have multipleiron-meta
elements with the sametype
andkey
? This seems potentially confusing. - Is it reasonable to expect notifications to only propagate to
iron-meta[-query]
elements that are in the DOM, with the expectation thatiron-meta[-query]
elements not in the DOM will be queried usingbyKey()
and will not be involved in any data bindings?
I also need this feature. akc-meta doesn't work for me as it creates cloned copy of value object. I want to share value by reference, which iron-meta already does.
Regarding expected/reasonable behavior. I assume, following can work:
- Only
iron-meta-query
should be notified. - I assume change notification will/should be sent by triggering non-bubbling
property-changed
(e.g.value-changed
) event oniron-meta-query
. Because that's the way 2-way binding works in polymer. So, it's irrelevant if whetheriron-meta-query
is in the DOM or used imperatively (Using Javascript).
There isn't any activity on this since last 3 months. So, I assume no one is working on this. So, Probably I would pick this up as I need this on priority. Is there any one working on it?
Came up against this one as well, notification of changes would be very useful
Hi Rob,
I have fixed it in my forked branch. See at https://github.com/DreamworldSolutions/iron-meta
To use this version, add "iron-meta": "DreamworldSolutions/iron-meta#^1.1.3"
as dependency in your bower.json
.
Due to busy schedule, we weren't able to write test-cases for this feature. So, it's pull request submission is still pending. I will appoint someone to submit pull request by next week and I hope that it will be accepted.
Thanks for the code @ChiragMoradiya just tried it and it looks great, works as I was expecting
+1 thanks @ChiragMoradiya, your fork is working for me as well. Hopefully you can find time for that pull request :)
@ChiragMoradiya @rwestlund @RobMaskell
Hey, I cannot understand how to use the new change features of the fork.
I have one parent meta in one element:
<iron-meta key="isAuthenticated" value="{{isAuthenticated}}"></iron-meta>
and one children in one other element:
<iron-meta-query key="isAuthenticated" value="{{isAuthenticated}}"></iron-meta-query>
when I update with this.isAuthenticated = true. the children isAuthenticated value stay undefined...
Thank you in advance...
I use the <iron-meta-query>
the same way as you do but for setting the value in the first place with the <iron-meta>
tag I have a default json object in the tag itself and then update it with this.$.session.value = resp;
where session is the id of the <iron-meta>
tag and resp is the json object. You could try something like that was a test? The only other thing I could think of is that you don't have the right code for whatever reason
Gosh, yeah, the fork-code wasn't loaded correctly. My deep fault. So glad it's working now.
Thank you for the awesome work @ChiragMoradiya and @RobMaskell for the answer!
I could be totally wrong, but I think iron-meta
is intended to be used for constants. For data that could change, a data binding would be more appropriate.
<source-element fruits={{fruits}}></source-element>
<other-element fruits=[[fruits]]></other-element>
<another-element fruits=[[fruits]]></another-element>
You are right. data-binding is more appropriate. But, in some cases it's hard to avail a constant which is configurable to each and every element on the page.
In my case, I am storing all the constants as a JS Object. Sometimes, one of the property of that object is changed later on and that change should be notified to all the elements of the app, so they can adjust around it. That use-case wasn't being solved easily without this feature.
Still no update?