4 ms·

You can't use external component which depends on MyCustomButton 1.0 and then use MyCustomButton 2.0 in the rest of your app (this is called dependency hell and

You can't use external component which depends on MyCustomButton 1.0 and then use MyCustomButton 2.0 in the rest of your app (this is called dependency hell and it is no issue for google because of their monorepo design so it basically does not exists at all for them but IT IS issue for me and probably even for you) Sometimes, there are things you can't express in templates and then it gets really hacky (vdom costs you some performance but it's more powerful) HMR is dead-simple because the fw already does diffing You can implement vdom in few dozens LOC so maybe it's not that hard

nkkollaw 9y ago
Thanks for your comment, but I'm still a little confused, though. > You can't use external component which depends on MyCustomButton 1.0 and then use MyCustomButton 2.0 in the rest of your app (this is called dependency hell and it is no issue for google because of their monorepo design so it basically does not exists at all for them but IT IS issue for me and probably even for you) Can you do that with React? The only way I can think of to do that (both in React and Polymer) would be to rename the component, or pass an api-version prop. As for the rest, lots of acronyms I'm not aware of :-) P.S.: are you Polish? If yes, where do you live..? I'm in Wrocław.
- 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 ago
    I 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 ago
      There'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 ago
    To 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.

nkkollaw 9y ago

Thanks for your comment, but I'm still a little confused, though. > You can't use external component which depends on MyCustomButton 1.0 and then use MyCustomButton 2.0 in the rest of your app (this is called dependency hell and it is no issue for google because of their monorepo design so it basically does not exists at all for them but IT IS issue for me and probably even for you) Can you do that with React? The only way I can think of to do that (both in React and Polymer) would be to rename the component, or pass an api-version prop. As for the rest, lots of acronyms I'm not aware of :-) P.S.: are you Polish? If yes, where do you live..? I'm in Wrocław.

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 ago
  I 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 ago
    There'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 ago
  To 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.