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.

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

> 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

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.

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

It’s pretty flexible and thin.

[0]: https://vuejs.org/v2/guide/components-custom-events.html#syn...

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

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

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

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.

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.

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.

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.

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?

Are you using some template tag function that handles escaping? Seems risky to rely on manual escaping everywhere.