3 ms·
It's just like if you wanted some-datepicker.js which depended on jquery1.1 but the rest of your code was jquery1.8 Polymer suffers from this because they are
by cztomsik 9y ago
It's just like if you wanted some-datepicker.js which depended on jquery1.1 but the rest of your code was jquery1.8
Polymer suffers from this because they are registering global custom element - just like when jquery registered itself as global $
React components does not register themselves anywhere so this problem does not exists at all.
It doesnt matter for google simply because they are not using anything else outside of google and everything is running from master, they really have one big "git-like" repository with all their projects and everything is always up-to-date (and it's a lot of work to not break anything)
You probably know HotReload already - it refreshes the browser if you make any change.
HMR (hot module replacement) is one step further, it will update the page without refreshing - so forexample you can click the button, and then make changes in modal, and those will get re-rendered - it is also possible to retain form-state...
P.S. Czech, Brno :)
- nkkollaw 9y agoI see. Is this the only pitfall? I'm used to using stuff that depends on other global components (like Bootstrap, for instance, and its non-prefixed classes), and people just solve this with correct naming practices.
- cztomsik 9y agoThere's also dependency on shadowdom, which has to be polyfilled in ms edge. Other than that, I think Polymer is getting better but it still feels (subjective) a lot like research project.
- ergo14 9y agoTo clarify the custom element registration is part of standard made by browser vendors - it is not something specific to polymer WebComponents. Specification allows you to register only one version of element.