Hacker News Reader

Comment by aphextron | Hacker News Reader

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.

View on HN

>> 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

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.

If I read parent's comment correctly, the notable thing was simplicity via few dependencies. I expect parent knows about J/TSX.

Panel can use any hyperscript based templating language. Virtual-jade, tsx, jsx, just h() calls.

It’s pretty flexible and thin.

Never heard of hyperscript before today, thanks for the pointer.

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

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?

That's misunderstandong of the technology. React has nothing to do with styles, it manipulates DOM. Handling styles is up to you, and it's extremely easy to use CSS modules.

>> React has nothing to do with styles

That's one of its limitations.

React is a component technology and doesn't solve the problem of clashing styles, element ids and so on. Web components is a component technology that does.

No, it's not a limitation, it's called separation of concerns, I don't want my component framework interfering with the job of Webpack or application runtime. I want to use my preferred (also easy, standard, ...) solution.

> clashing IDs

React solves that one, not through namespacing though. You never need to use IDs with React.

> clashing styles

React gives you power to solve this one by your preferred solution. You can use expressions in your JSX, and thus it's very easy to do one of the following:

- Generate optimal global CSS stylesheet with no code repetition, generate classnames on the fly (https://github.com/typestyle/typestyle)

- Import your CSS file as a module using Webpack - classnames are guaranteed to be unique; additionally, similar approach as TypeStyle (global optimal stylesheet) can be set up

- Use just "inline" styles (preferably not really inlined in your JSX) since React will keep it updated for you as well

>You never need to use IDs with React.

If you don't care about accessibility then yes.l, but try using properly annotated aria attributes without appropriately scoped ids(which you can do in react, but it's not free).

Hmm, right now I truly don't (that's the business requirement :-/). I'll investigate, thank you.

Not doing anything about CSS isn't separation of concerns, it's just a leaky abstraction. Separation of concerns implies some work was done to achieve some level of decoupling that would otherwise be tighter.

In fact, the criticism that react components can have style clashes is precisely one of not having enough separation of concerns. The fact that there are numerous libraries to address that deficiency further indicates that react as a platform is severely affected by the underlying level of abstraction when it comes to styling.

It's fine to defend a technology you like but calling a weakness a strength does nobody any favors.

Styled-Components gives you efficiently “inlined” styles (creates unique CSS class used only by instances of your component) and doesn’t affect global CSS. It’s up to the developer to avoid polluting with global CSS and that’s honestly not very difficult.

According to https://custom-elements-everywhere.com/ React has a way to go for full support.

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#syn...

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.

> 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.)

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

I've been using 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-app...

Check out https://github.com/Polymer/pwa-starter-kit/wiki. It uses Redux and LitElement (https://github.com/Polymer/lit-element)

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

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.

> 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.

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-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/).

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.

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.

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".

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.

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.

Facebook developed flux since they had a lot of problems with MVC.

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...

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?

> 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.

Reply on news.ycombinator.com