3 ms·

This seems almost exactly like all of React. These components do have state, just like a React component. If you're talking about how the state is changed, th

This seems almost exactly like all of React. These components do have state, just like a React component. If you're talking about how the state is changed, then now you're not talking about React. You're talking about redux, flex, etc. You may very well want something like that here too, but that's not because this isn't like React, it's because it is like React.

aljones 10y ago
https://github.com/facebook/react/issues/5052#issuecomment-145594782 https://github.com/facebook/react/issues/5052#issuecomment-1...
tolmasky 10y ago
A big part of React (and arguably the whole point of React), is the way in which state changes are handled and re-rendered. A React version of this progress bar element would simply have a render method, that when the state changed would simply be called again for another full-re-render of the element. The fact that this grabs individual elements and mutates them is about as far from React-style programming as you can get. Virtual DOM, tree-diffing, all of this is around a central concept that "immediate mode" programming reduces visual bugs, and is completely absent from custom elements. I'm not saying Custom Element are wrong, but they are absolutely different from React in a core and essential way.
mambodog 10y ago
Where's the part of React which allows me to return a new copy of what I want the HTML to look like, while only updating the changed elements of my view instead of totally blowing away the existing elements (the virtual DOM + reconcilitation part of React)? Also, where's the declarative event binding part? I'd also point out that the state tree (setState) is a part of React, and plenty of apps are just fine being built using only setState for state management (no redux/flux/mobx).
- Touche 10y ago
  You're right, custom elements don't do that, and it's not a goal of the custom elements spec (as far as I can tell) to promote any particular programming style. It's a low level spec. So showing the most low-level way to use it makes sense. Here's a library that combines custom elements with VDOM rendering: https://github.com/skatejs/skatejs https://github.com/skatejs/skatejs

aljones 10y ago

https://github.com/facebook/react/issues/5052#issuecomment-145594782 https://github.com/facebook/react/issues/5052#issuecomment-1...

tolmasky 10y ago

A big part of React (and arguably the whole point of React), is the way in which state changes are handled and re-rendered. A React version of this progress bar element would simply have a render method, that when the state changed would simply be called again for another full-re-render of the element. The fact that this grabs individual elements and mutates them is about as far from React-style programming as you can get. Virtual DOM, tree-diffing, all of this is around a central concept that "immediate mode" programming reduces visual bugs, and is completely absent from custom elements. I'm not saying Custom Element are wrong, but they are absolutely different from React in a core and essential way.

mambodog 10y ago

Where's the part of React which allows me to return a new copy of what I want the HTML to look like, while only updating the changed elements of my view instead of totally blowing away the existing elements (the virtual DOM + reconcilitation part of React)? Also, where's the declarative event binding part? I'd also point out that the state tree (setState) is a part of React, and plenty of apps are just fine being built using only setState for state management (no redux/flux/mobx).

Touche 10y ago
You're right, custom elements don't do that, and it's not a goal of the custom elements spec (as far as I can tell) to promote any particular programming style. It's a low level spec. So showing the most low-level way to use it makes sense. Here's a library that combines custom elements with VDOM rendering: https://github.com/skatejs/skatejs https://github.com/skatejs/skatejs