I'm getting into Polymer and i like the deps resolution approach using imports.
And i like the extending capability through the behaviors config.
However, there's something that doesn't feel comfortable to me, about behaviors in particular.
Looking at the PolymerElements code i see that behaviors, are defined inside their own html in the global object Polymer and then referenced directly when imported by another component..
For example:
paper-button imports paper-button-behavior
https://github.com/PolymerElements/paper-button/blob/master/paper-button.html#L14
it then defines paper-button-behavior as behavior referencing from global Polymer.PaperButtonBehavior
https://github.com/PolymerElements/paper-button/blob/master/paper-button.html#L144
wich is defined here (the imported html)
https://github.com/PolymerElements/paper-behaviors/blob/master/paper-button-behavior.html#L49
Ain't it an anti-pattern, especially as typically an app will not use Polymer's world exclusively?
Related
I have the following scenario. I am writing a complex component that is using three-js:
The component manages complex mouse interactions and updates other elements in the DOM using two-ways data binding: variables, JSON objects, mouse interactions, etc.
I start using the component in few part of my application but I needed to substantially modified the threed-viewer.html so I made a copy of the whole component ending up having duplicates that are hard to maintain.
All flavours of the component share 80% of the javascript code and bindings but they have substantial UI differences. So I had the though of create different 3 basic component (minimal javascript code) that I can inject into the threed-viewer.html using a selector and a variable to decide which template to load:
this does not compile as the html files have all the variables and bindings from the original components but they are not present in the typescript files.
Another solution could be to have a single html managed via ngIf but it will result in a long, messy, difficult to manage file. Is this the only option I have in Angular. Any other idea?
Thank you.
You can have a shared service and then add three different components but js code won't be duplicated as it will be in the service.
Use two way bindings in all 3 components using the service variables, functions and objects
I have did long time ago - the pages and article editor. Two different templates, same code.
I used articles component as "parent", and extended it to news editor.
Looks like this:
#Component({template: 'blah blah blah'}) export class parent {}
#Component({template: 'blah2 blah2 blah2'}) export class child extends parent {}
Hopefully this is the solution you were looking for.
Two different components, two templates, one code.
Of course, you can have the "parent" abstract class for both where you can save all methods you need.
It's OOP baby ;)
For fast searching elements by Selenium, I think it must be a simple way to set some attributes to html-elements, for example: transform React Component Key to data-attribute (if it is possible).
Of course I can writing id or data-attributes to my span, div and whatever in my components, but I can't do it with components of 3d-party libraries - this components may haven't props like "id", and I will have to wrap this components and then find they by tag or class...
Or maybe is plugin for webpack to set data-attributes to elements with component's names.
However, how you find elements in your react app render?
I think it's not a good idea find elements by class or tags
key transform like this:
<MyComponent key="SuperComponent" />
...
<div data-attr="SuperComponent">...</div>
or autoset attributes of component name like this:
<MySuperComponent />
...
<div data-attr="MySuperComponent">...</div>
From "Test Automation through Selenium" perspective it hardly matters if the HTML consists of id or data-attributes. While working with Selenium tests are written with the help of any effective <tag> and the associated attributes. However there is a preferred list of Locator Strategies as follows:
How to find elements in react app render?
The AUT (Application Under Test) being ReactJS based of-coarse the element will be having dynamic attributes. Locator Strategies can also be dynamic. You can find an example usage of Dynamic Locator Strategies in the discussion How to locate a button with a dynamicID
Finally, while Test Automation the fast moving WebDriver instance will be needed to be synchronized with the lagging browser. You can find a relevant discussion in Do we have any generic funtion to check if page has completely loaded in Selenium
What is the minimum example, if any, using the Polymer PWA (https://polymer.github.io/pwa-starter-kit/), to show correctly a vaadin-grid?
I tried many different combinations, but never a working one, with, often, this warning:
property-accessors.js:275 Polymer::Attributes: couldn't decode Array as JSON
Am I doing anything totally wrong?
Thanks
Andrea
Starting from the v5.2.0-beta1 we recommend using following Grid features:
column helper elements (vaadin-grid-filter-column, vaadin-grid-sort-column)
column convenience properties (path, header and text-align)
renderers for more complex cases where you previously used templates
See the example here: https://glitch.com/edit/#!/lying-blanket?path=app.js:29:42
https://lying-blanket.glitch.me/
Note: I'm using fetch API here for simplicity only, you can use XHR if necessary.
I'm using Polymer components with ClojureScript + Reframe (actually, at the moment, I have just one Polymer component working). My component is mostly stateless (a drawing tool for Dicom images), so it plays nicely with Reframe. I use HTML + callbacks to communicate with it. It works nicely, but I'm not using ClojureScript advanced compilation. I haven't used advanced compilation before and have some questions about its use:
As I understand, Polymer isn't compatible with Google Closure. Is that still the case?
If I'm using just HTML/callbacks to talk to the component, do I still have problems with name mangling? I suppose that I am safe with the HTML part, but am I going to have problems with the callbacks? Such as [component-x {... :on-mouse-down (dispatch-canvas-event editor-id)}]
What happens to the javascript portion of the WebComponent during compilation? Does it get changed, even if I don't call any function directly (just HTML/callbacks)?
If I do have to call a function in a component, any examples of how to write an Extern file for a Polymer component?
In my react projects I have been using ES6 modules for some time. In my react component I would use import:
import {f1,f2} from "./myLib";
In my polymer component I use a script tag:
<script src="./myLib.js"></script>
If I'm not mistaken, these are doing two totally different things. The script tag is polluting my global namespace for the whole app. The import isn't.
Question #1: Am I correct in my understanding of this?
Question #2: Is there a way to get something similar in polymer?
I have dozens of different polymer components. Some import conflicting libraries. Then, if I have a page that uses multiple components it seems like a crap shoot as to which version of the JS script I will get.
It is certainly possible to use ES6 modules with Polymer. First thing you will have to do is split the template and script. You can then go both ways
Add a script tag containing transpiled ES6 code to the element's html:
<dom-module id="my-elem"></dom-module>
<script src="my-elem.js"></script>
Use some kind of plugin to import HTML from ES6 code. This is, for example, possible with this plugin for SystemJS
import './my-elem.html!';
class MyElem extends HTMLElement {}
document.registerElement('my-elem', MyElem);
Then the difficult part is then transpiling. I'm not sure about other module loaders, but with JSPM+SystemJS it is easy to bundle as an Universal module. This way your element will be usable both by <link rel="import" href="bower_components/my-elem/my-elem.html"> and for importing from other ES6 code. In the former case any dependencies not bundled will have to live in the global scope. You could, however, place any such dependencies in your main html file. Just like many other elements are published.
If you're willing to give JSPM+SystemJS a try, please have a look at a blog post on my blog. I'm using TypeScript but for ES6 the general solution should be roughly the same.