MV * in Polymer, models and services as polymer elements?

Question

Let's say I want two types (polymer elements) to share a model.

In Angular, the model will live in a single-user service, which is introduced into the views, both views are read from the same source.

I tried to imitate this approach with Polymer, so I can do something like:

<polymer-element name="view1"> <template> <my-model></my-model> ... </template> ... </polymer-element> <polymer-element name="view2"> <template> <my-model></my-model> ... </template> ... </polymer-element> 

I like this approach because it is a declarative way of defining dependencies, and it basically works the same as <core-ajax> and others out of the box. Polymer elements.

Thus, I need to wait for the domReady lifecycle domReady before I can interact with any element declared in the template, so here I support my initialization logic. The problem is that this callback is called once for each declared <my-model> element (therefore, <my-model> will be initialized twice in this example because it is present in both <view1> and <view2> ) To make sure my model follows the singleton pattern, I need to move the state outside the element instance, something like this:

  <polymer-element name="my-model"> <script> (function(){ // private shared state var instances = [], registered; // pattern variables var foo; // state, model, whatever // element init logic Polymer('my-model', { // Polymer callbacks domReady: function(){ if (registered === (registered=true)) return; // singleton init logic foo = 'something'; // event handlers this.addEventListener('foo', function(){ foo += 'baz'; }); }, attached: function() { instances.push(this); }, detached: function(){ instances = instances.filter(function(instance){ return instance !== this; }.bind(this)); }, // element API update: doSomething, get state() { return foo; } }); // private functions function doSomething(){ foo += 'bar' } })(); </script> </polymer-element> 

This is how it works, but it doesn’t look right. Does <polymer-element> any incompatible with a singleton pattern? Should I move away from Polymer for models and services? How are polymer core elements related to this?

[EDIT] I have added some event listeners to the initialization code above. They are registered in only one instance to avoid listening several times in several instances. What happens if the instance in which the event handlers are declared is deleted? Wouldn't that break asynchronous logic?

Answer 1

I would say like this:
Define your model on the main page and call it from your views.

if it is deleted, you can:
1 - listen to the “separate” lifecycle callback and register it imperatively inside it or
2 - store the material on the prototype assembly in a higher-level object and access it the way you like most.
3 - if everything fails, (I'm not sure if this will happen, but I think that I have not used this kind of implementation yet, at the moment I am talking with php and passing objects that I need persistent), you can use "prepareForRemoval", knowing that you will leave an instance, local storage of your material and make number 1, then "recoverFromRemoval" if you know what I mean in the camel shell prototype sentences .

In any case, I do not really like single people. Polymer is a powerful interface, but I'm not sure if this is the best way to do this.

in the API docs they don’t mention the possibility of trimming it ( as you can see ) but I honestly think that you are right and you will lose your things.
That only my 2 cents is actually just an ineffective solution that I came up with at this very moment , maybe @ebidel, @DocDude or @dodson can help us with this issue, but you cannot mark them here on SO I mark em on G + for us, you sir intrigued me.
By the way, why would you move away from your main page? there is no point for this in the polymer, you must dynamically change the content, do not go away from it. What will be the use case?

ps: sorry i hate capitalizing my own nouns. Get over it

EDIT (not suitable for comments):

I expressed myself wrongly. In any case, I strongly think that I did not understand what you wanted.
Well, if I got this right this time, yes, it will fire several times (they should), but it should not cut others as soon as the specific view is deleted.

As for the initialization logic, I would add that adding a listener to a window or a document (I think the window is more appropriate), waiting for the "finished polymer" event.

"To make sure my model matches a singleton pattern, I have to move the state outside of the element instance"

Yes, that's right. but don't wait for it to have a domready prototype in it, instead use a construct or similar contruct-like and call it a callback to the aforementioned event listener. I will edit my answer to make it clearer (if it is not, let me know) when I get home. I hope you understand.

If you do not, I will be back soon.

Answer 2

In browsers, window == singleton object by definition. Simple use:

 var window.instances = []; var window.registered; var window.foo; 

instead.

Another way is to use the Polymer core-meta element:

  <core-meta id="x-foo" label="foo"></core-meta> <core-meta id="x-bar" label="bar"></core-meta> <core-meta id="x-zot" label="zot"></core-meta> <core-meta id="apple" label="apple" type="fruit"></core-meta> <core-meta id="orange" label="orange" type="fruit"></core-meta> <core-meta id="grape" label="grape" type="fruit"></core-meta> <h2>meta-data</h2> <template id="default" repeat="{{metadata}}"> <div>{{label}}</div> </template> <h2>meta-data (type: fruit)</h2> <template id="fruit" repeat="{{metadata}}"> <div>{{label}}</div> </template> <script> document.addEventListener('polymer-ready', function() { var meta = document.createElement('core-meta'); document.querySelector('template#default').model = { metadata: meta.list }; var fruitMeta = document.createElement('core-meta'); fruitMeta.type = 'fruit'; document.querySelector('template#fruit').model = { metadata: fruitMeta.list }; }); </script>