9 ms·

I've been using web components in production for a while now and it's great. Our front end "stack" consists of a single polyfill and Webpack. Use template lite

I've been using web components in production for a while now and it's great. Our front end "stack" consists of a single polyfill and Webpack. Use template literals for templating, so you don't even need handlebars/mustache anymore. Webpack lets you write SASS that is compiled directly to CSS and inserted in your shadow DOM with an ES6 import, so no more style sheets for anything but high level page layout. Everything is standards based web components written in vanilla ES6, transpiled for browser compatibility down to IE10. One major issue we've had though, which wasn't touched in this article, is inter-component communication among siblings. Sure you can just do a global event bus, and that works, but I've yet to see an elegant solution for this yet.

yesimahuman 8y ago
For inter-component communication, sounds like redux would be a big help for you. Polymer has a mixin you could use: https://github.com/Polymer/pwa-helpers/blob/master/connect-mixin.js https://github.com/Polymer/pwa-helpers/blob/master/connect-m.... You're not using Stencil, but if others do, it has a redux connector or a simpler state tunnel system for passing state to child components (https://stenciljs.com/ https://stenciljs.com/).
- interlocutor 8y ago
  No, don't use Redux everywhere. Most applications don't need to manage client-side state. State lives on the server. If your application lets the user edit stuff without immediately sending the update to the server then you may have state, otherwise you don't and you don't need a state manager.
  - mieseratte 8y ago
    Perhaps if your app is just a series of request-response style CRUD forms, at which point why bother using a front-end framework in favor of server-side templates / forms. Toss in jQuery if you want some AJAX. Tossing in Redux (or whatever Flux-like flavor of the day) is a low-effort, high-value add on top of React and obviates the possibility of some bat-shit data-passing situation that would make an OO inheritance junkie blush. If you're the sensitive to boilerplate type, there are some simple libraries to solve that issue. Unless you're tossing together a three component TODO list demo, not using Redux will just bite you in the ass a year down the line in maintenance costs as your application grows. This is really starting to remind me of the "Don't worry about the data model, just toss it in Mongo!" all over again.
    - petilon 8y ago
      Did you start developing apps, like yesterday? Patterns such as MVC have been around for decades and used in many different platforms such as web and mobile and did not need anything like Redux or Flux. Are there new problems that cropped up recently that needs Redux or Flux? It is youngster devs who haven't seen anything more than React that makes statements like "not using Redux will just bite you in the ass a year down the line".
      - mieseratte 8y ago
        No, but not respecting your data model will certainly bite you in the ass. Sweat now, or bleed later. When I see folks saying, "Oh just deal with it in the components" I have to assume either A) they're working on an extremely small, self-contained piece (which is fine) or B) they're not bothering to think about their data from the get-go.
        petilon 8y ago
        Bothering to think about your data from the get-go doesn't mean you need actions and reducers. We don't have a new problem today that didn't exist 10 years ago. iOS apps don't need actions and reducers, so why do web apps need them? When you have a hierarchy of components information should flow down that hierarchy. If each component grabs and updates info directly from the store you are violating the encapsulation of hierarchical components.
      - jbergens 8y ago
        Facebook developed flux since they had a lot of problems with MVC.
kwindla 8y ago
> One major issue we've had though, which wasn't touched in this article, is inter-component communication among siblings. Sure you can just do a global event bus, and that works, but I've yet to see an elegant solution for this yet. Would Redux potentially be a good fit? It's a "global event bus" kind of thing, but with a pretty clear information flow model and an increasingly large user community. (Both of which are good things, IMHO.)
- lhorie 8y ago
  Event bus is how things often ended up getting done in Angular 1, and definitely not something I'd want to maintain (because you end up with comefrom-hell type of issues). Redux feels like a step in the right direction conceptually with its centralized state bag, but I feel like it's a bit distracting (since it was primarily conceived to handle serializable actions for a very specific use case), and also doesn't have good patterns out of the box to organize side-effects (sagas kinda do, but people I've worked with are fairly divided on whether it works for them or not) Recently I've been thinking that a lot of the complexity around React+Redux comes from wanting testable state, but as it turns out, Jest can mock imports making the entire context shenanigans somewhat pointless - just import a global state bag. I've had pretty decent success with just having a naive global state bag, would love to hear about similar approaches
  - Torn 8y ago
    I've been using MobX (https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx) in my day job for a year now in a very large client-side app, and hands-down prefer it to redux. Initially I was wondering why we didn't have a centralised store, but once free from that mindset it allows you to keep observable data locally to where it's needed. Much nicer for encapsulation and separation of concerns. Far less boilerplate too, as MobX does some very smart usage & dirty checking for you. mobx-react also provides an @observer class annotation, which ends up working pretty magically - things re-render when they need to. If anyone's interested, here are some tutorials from the author: https://egghead.io/courses/manage-complex-state-in-react-apps-with-mobx https://egghead.io/courses/manage-complex-state-in-react-app...
- 8y ago
Touche 8y ago
Arguably siblings needing to communicate is "code smell". Is there a way to restructure so that this isn't needed?
- ry_ry 8y ago
  Some unnecessary downvoting occuring, go easy. In a discreet component architecture there is basically no reason for arbitrary siblings to know anything about each other - if there is common state to be shared it should be inhereted. Granted, in JS land that sometimes involves jumping through weird IoC hoops or cached callbacks, which are akward to say the least, but in the abstract an instance of a component should be concerned with its own behaviour, and possibly that of it's descendents by way of that behavior.
  - deleted 8y ago
    [deleted]
deckar01 8y ago
Vue discourages 2-way binding between components and instead suggests binding data down to children and requiring children to emit events up to their parents to request shared state mutation [0]. I'm not sure how elegant it is, but it seems logical to delegate the responsibility of state management to the components that originally provide the data. [0]: https://vuejs.org/v2/guide/components-custom-events.html#sync-Modifier https://vuejs.org/v2/guide/components-custom-events.html#syn...
- lhorie 8y ago
  The data-down, events-up architecture is fairly popular not just with Vue but React, Ember and other frameworks as well. The main criticism of it (at least in React-land) was that you ended up with a lot of noise from having to pass unrelated things up and down from intermediate components. This is what React context and higher-order components were meant to address when they were conceived.
interlocutor 8y ago
>> Use template literals for templating, so you don't even need handlebars/mustache anymore. You can do better than template literals. You can use TSX, which gives you compile-time verification for tags and attributes, in addition to JavaScript expressions. See: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder With TSX (which is JSX written using TypeScript, you get things like syntax coloring and indentation for tags, because HTML and JavaScript are both first-class citizens in TSX.
- anothergoogler 8y ago
  If I read parent's comment correctly, the notable thing was simplicity via few dependencies. I expect parent knows about J/TSX.
  - nojvek 8y ago
    Panel can use any hyperscript based templating language. Virtual-jade, tsx, jsx, just h() calls. It’s pretty flexible and thin.
    - anothergoogler 8y ago
      Never heard of hyperscript before today, thanks for the pointer.
- _sdegutis 8y ago
  I’ve only been using React for a few weeks but the comparisons on that page to React are FUD and the incompatibility with web components is just plain wrong and mixing them is covered here https://reactjs.org/docs/web-components.html https://reactjs.org/docs/web-components.html
  - petilon 8y ago
    From the page you linked: "Events emitted by a Web Component may not properly propagate through a React render tree." React components are brittle, that's not FUD. For example, CSS classes used by React components can clash with other React components, or with the page that includes them. What's FUD about that?
anothergoogler 8y ago
> Use template literals for templating, so you don't even need handlebars/mustache anymore. Are you using some template tag function that handles escaping? Seems risky to rely on manual escaping everywhere.
tdumitrescu 8y ago
> One major issue we've had though, which wasn't touched in this article, is inter-component communication among siblings. The way we typically handle something like this is by connecting components through a common ancestor. The default naive behavior of Panel apps is for linked components to share a "centralized state bag" (as one of the other comments calls it re: Redux), and updates to that state automatically cascade to all the components. It's a blunt, easy and lightweight way to propagate changes arbitrarily throughout an app, but it does get unwieldy as the state object gets big so we've ended up with some mechanisms for partial state-sharing to address this issue.
holmberd 8y ago
I've been using a similar approach for the last year, and I find that most problems are much easier to deal with because of less crud in the build flow. There is currently a W3C proposal for template instantiation that showcase some conveniences to deal with templates in components, could be good, could be bad. https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals... Most communication I solve by custom event dispatching or attribute callbacks, but there are the odd cases, especially regarding more advanced drag/drop, that still requires state at some level. Do you have any concrete example of inter-component communication to look at?

yesimahuman 8y ago

For inter-component communication, sounds like redux would be a big help for you. Polymer has a mixin you could use: https://github.com/Polymer/pwa-helpers/blob/master/connect-mixin.js https://github.com/Polymer/pwa-helpers/blob/master/connect-m.... You're not using Stencil, but if others do, it has a redux connector or a simpler state tunnel system for passing state to child components (https://stenciljs.com/ https://stenciljs.com/).

interlocutor 8y ago
No, don't use Redux everywhere. Most applications don't need to manage client-side state. State lives on the server. If your application lets the user edit stuff without immediately sending the update to the server then you may have state, otherwise you don't and you don't need a state manager.
- mieseratte 8y ago
  Perhaps if your app is just a series of request-response style CRUD forms, at which point why bother using a front-end framework in favor of server-side templates / forms. Toss in jQuery if you want some AJAX. Tossing in Redux (or whatever Flux-like flavor of the day) is a low-effort, high-value add on top of React and obviates the possibility of some bat-shit data-passing situation that would make an OO inheritance junkie blush. If you're the sensitive to boilerplate type, there are some simple libraries to solve that issue. Unless you're tossing together a three component TODO list demo, not using Redux will just bite you in the ass a year down the line in maintenance costs as your application grows. This is really starting to remind me of the "Don't worry about the data model, just toss it in Mongo!" all over again.
  - petilon 8y ago
    Did you start developing apps, like yesterday? Patterns such as MVC have been around for decades and used in many different platforms such as web and mobile and did not need anything like Redux or Flux. Are there new problems that cropped up recently that needs Redux or Flux? It is youngster devs who haven't seen anything more than React that makes statements like "not using Redux will just bite you in the ass a year down the line".
    - mieseratte 8y ago
      No, but not respecting your data model will certainly bite you in the ass. Sweat now, or bleed later. When I see folks saying, "Oh just deal with it in the components" I have to assume either A) they're working on an extremely small, self-contained piece (which is fine) or B) they're not bothering to think about their data from the get-go.
      - petilon 8y ago
        Bothering to think about your data from the get-go doesn't mean you need actions and reducers. We don't have a new problem today that didn't exist 10 years ago. iOS apps don't need actions and reducers, so why do web apps need them? When you have a hierarchy of components information should flow down that hierarchy. If each component grabs and updates info directly from the store you are violating the encapsulation of hierarchical components.
    - jbergens 8y ago
      Facebook developed flux since they had a lot of problems with MVC.

kwindla 8y ago

> One major issue we've had though, which wasn't touched in this article, is inter-component communication among siblings. Sure you can just do a global event bus, and that works, but I've yet to see an elegant solution for this yet. Would Redux potentially be a good fit? It's a "global event bus" kind of thing, but with a pretty clear information flow model and an increasingly large user community. (Both of which are good things, IMHO.)

lhorie 8y ago
Event bus is how things often ended up getting done in Angular 1, and definitely not something I'd want to maintain (because you end up with comefrom-hell type of issues). Redux feels like a step in the right direction conceptually with its centralized state bag, but I feel like it's a bit distracting (since it was primarily conceived to handle serializable actions for a very specific use case), and also doesn't have good patterns out of the box to organize side-effects (sagas kinda do, but people I've worked with are fairly divided on whether it works for them or not) Recently I've been thinking that a lot of the complexity around React+Redux comes from wanting testable state, but as it turns out, Jest can mock imports making the entire context shenanigans somewhat pointless - just import a global state bag. I've had pretty decent success with just having a naive global state bag, would love to hear about similar approaches
- Torn 8y ago
  I've been using MobX (https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx) in my day job for a year now in a very large client-side app, and hands-down prefer it to redux. Initially I was wondering why we didn't have a centralised store, but once free from that mindset it allows you to keep observable data locally to where it's needed. Much nicer for encapsulation and separation of concerns. Far less boilerplate too, as MobX does some very smart usage & dirty checking for you. mobx-react also provides an @observer class annotation, which ends up working pretty magically - things re-render when they need to. If anyone's interested, here are some tutorials from the author: https://egghead.io/courses/manage-complex-state-in-react-apps-with-mobx https://egghead.io/courses/manage-complex-state-in-react-app...
8y ago

Touche 8y ago

Arguably siblings needing to communicate is "code smell". Is there a way to restructure so that this isn't needed?

ry_ry 8y ago
Some unnecessary downvoting occuring, go easy. In a discreet component architecture there is basically no reason for arbitrary siblings to know anything about each other - if there is common state to be shared it should be inhereted. Granted, in JS land that sometimes involves jumping through weird IoC hoops or cached callbacks, which are akward to say the least, but in the abstract an instance of a component should be concerned with its own behaviour, and possibly that of it's descendents by way of that behavior.
- deleted 8y ago
  [deleted]

deckar01 8y ago

Vue discourages 2-way binding between components and instead suggests binding data down to children and requiring children to emit events up to their parents to request shared state mutation [0]. I'm not sure how elegant it is, but it seems logical to delegate the responsibility of state management to the components that originally provide the data. [0]: https://vuejs.org/v2/guide/components-custom-events.html#sync-Modifier https://vuejs.org/v2/guide/components-custom-events.html#syn...

lhorie 8y ago
The data-down, events-up architecture is fairly popular not just with Vue but React, Ember and other frameworks as well. The main criticism of it (at least in React-land) was that you ended up with a lot of noise from having to pass unrelated things up and down from intermediate components. This is what React context and higher-order components were meant to address when they were conceived.

interlocutor 8y ago

>> Use template literals for templating, so you don't even need handlebars/mustache anymore. You can do better than template literals. You can use TSX, which gives you compile-time verification for tags and attributes, in addition to JavaScript expressions. See: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder With TSX (which is JSX written using TypeScript, you get things like syntax coloring and indentation for tags, because HTML and JavaScript are both first-class citizens in TSX.

anothergoogler 8y ago
If I read parent's comment correctly, the notable thing was simplicity via few dependencies. I expect parent knows about J/TSX.
- nojvek 8y ago
  Panel can use any hyperscript based templating language. Virtual-jade, tsx, jsx, just h() calls. It’s pretty flexible and thin.
  - anothergoogler 8y ago
    Never heard of hyperscript before today, thanks for the pointer.
_sdegutis 8y ago
I’ve only been using React for a few weeks but the comparisons on that page to React are FUD and the incompatibility with web components is just plain wrong and mixing them is covered here https://reactjs.org/docs/web-components.html https://reactjs.org/docs/web-components.html
- petilon 8y ago
  From the page you linked: "Events emitted by a Web Component may not properly propagate through a React render tree." React components are brittle, that's not FUD. For example, CSS classes used by React components can clash with other React components, or with the page that includes them. What's FUD about that?

anothergoogler 8y ago

> Use template literals for templating, so you don't even need handlebars/mustache anymore. Are you using some template tag function that handles escaping? Seems risky to rely on manual escaping everywhere.

tdumitrescu 8y ago

> One major issue we've had though, which wasn't touched in this article, is inter-component communication among siblings. The way we typically handle something like this is by connecting components through a common ancestor. The default naive behavior of Panel apps is for linked components to share a "centralized state bag" (as one of the other comments calls it re: Redux), and updates to that state automatically cascade to all the components. It's a blunt, easy and lightweight way to propagate changes arbitrarily throughout an app, but it does get unwieldy as the state object gets big so we've ended up with some mechanisms for partial state-sharing to address this issue.

holmberd 8y ago

I've been using a similar approach for the last year, and I find that most problems are much easier to deal with because of less crud in the build flow. There is currently a W3C proposal for template instantiation that showcase some conveniences to deal with templates in components, could be good, could be bad. https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals... Most communication I solve by custom event dispatching or attribute callbacks, but there are the odd cases, especially regarding more advanced drag/drop, that still requires state at some level. Do you have any concrete example of inter-component communication to look at?