5 ms·

It's certainly a weird phrasing of an argument. However, it seems reasonable that some programmers will not like the specific style of structure that react esp

by dsp1234 11y ago

It's certainly a weird phrasing of an argument. However, it seems reasonable that some programmers will not like the specific style of structure that react espouses. Specifically the top-down push of data through parent-child component relationships. Specifically, if you are working with a lot of third party components that are not react based, it can be hard (or a lot of boilerplate) to contain them within react applications.

ergothus 11y ago
But you certainly can NOT do that. You can write "smart" components that each talk to the necessary store(s) and make decisions. As your project grows, you'll come to see WHY small, dumb components are helpful, and how the top-down view manages the scope of rerendering. You can come around to the espoused best practices organically.
- dsp1234 11y ago
  You can come around to the espoused best practices organically. As I said before, it's reasonable that some people are not going to like these particular best practices, and that in some instances it's going to get in the way. As a concrete example, I just put up a form that is basically just a SSR datatables.net table and a save button. Adding react into the mix is literally unnecessary, and just adds boilerplate/extra code for no gain. In other words, it gets in the way. So I chose not to use it.
- apalmer 11y ago
  You can but fundamentally, if you dont buy into the fundamental guiding principles that a framework is based on, you probably shouldn't use the framework. Its like saying lets use angular but not limit DOM manipulation in directives, build fat controllers that include direct requests to the server and business logic because all the service boiler plate is annoying and makes the application harder to reason about, and add objects directly to the global object because angulars dependency injection based on string values is error prone, not DRY, and kinda fool hardy, not use data binding because of the performance issues... yeah those may be valid points, but if you buy into that you should just drop angular and use backbone or something else...
tlrobinson 11y ago
I've actually found it surprisingly easy to wrap 3rd party libraries in thin React components once you figure out the lifecycle methods and findDOMNode().
- kruhft 11y ago
  That's what I thought until I actually tried. findDOMNode was the first thing I found and then I thought it would be trivial, but the problems of passing child state up to the parent left me befuddled for days.
guscost 11y ago
> the top-down push of data through parent-child component relationships This is a conventional approach when working with the DOM, since the XML is organized as a tree. Plus it happens to work nicely with their intended data flow pattern. But you make an interesting point, what about UIs that don't fit nicely into the document paradigm? Are there cases where it would be better to organize UI components in a graph, for example? > if you are working with a lot of third party components that are not react based, it can be hard (or a lot of boilerplate) to contain them within react applications. In my experience integrating third-party UI components has been much easier than I would have guessed. The difficulty has not really been in wiring the React parts to the component's API, but in making a stateful third-party component behave in a stateless fashion.
tptacek 11y ago
Sorry, that obviously isn't one of my better comments, and other commenters have done a much better job than I did reacting to the original argument. What I'm objecting to isn't the idea that React's ideas aren't for everyone, or perfect for every application, but rather that React's issues somehow stem from some kind of Facebook-y need for "control". That's an especially weird claim to make given how simple and open-ended React (by itself) is.

by dsp1234 11y ago

ergothus 11y ago

But you certainly can NOT do that. You can write "smart" components that each talk to the necessary store(s) and make decisions. As your project grows, you'll come to see WHY small, dumb components are helpful, and how the top-down view manages the scope of rerendering. You can come around to the espoused best practices organically.

dsp1234 11y ago
You can come around to the espoused best practices organically. As I said before, it's reasonable that some people are not going to like these particular best practices, and that in some instances it's going to get in the way. As a concrete example, I just put up a form that is basically just a SSR datatables.net table and a save button. Adding react into the mix is literally unnecessary, and just adds boilerplate/extra code for no gain. In other words, it gets in the way. So I chose not to use it.
apalmer 11y ago
You can but fundamentally, if you dont buy into the fundamental guiding principles that a framework is based on, you probably shouldn't use the framework. Its like saying lets use angular but not limit DOM manipulation in directives, build fat controllers that include direct requests to the server and business logic because all the service boiler plate is annoying and makes the application harder to reason about, and add objects directly to the global object because angulars dependency injection based on string values is error prone, not DRY, and kinda fool hardy, not use data binding because of the performance issues... yeah those may be valid points, but if you buy into that you should just drop angular and use backbone or something else...

tlrobinson 11y ago

I've actually found it surprisingly easy to wrap 3rd party libraries in thin React components once you figure out the lifecycle methods and findDOMNode().

kruhft 11y ago
That's what I thought until I actually tried. findDOMNode was the first thing I found and then I thought it would be trivial, but the problems of passing child state up to the parent left me befuddled for days.

guscost 11y ago

> the top-down push of data through parent-child component relationships This is a conventional approach when working with the DOM, since the XML is organized as a tree. Plus it happens to work nicely with their intended data flow pattern. But you make an interesting point, what about UIs that don't fit nicely into the document paradigm? Are there cases where it would be better to organize UI components in a graph, for example? > if you are working with a lot of third party components that are not react based, it can be hard (or a lot of boilerplate) to contain them within react applications. In my experience integrating third-party UI components has been much easier than I would have guessed. The difficulty has not really been in wiring the React parts to the component's API, but in making a stateful third-party component behave in a stateless fashion.

tptacek 11y ago

Sorry, that obviously isn't one of my better comments, and other commenters have done a much better job than I did reacting to the original argument. What I'm objecting to isn't the idea that React's ideas aren't for everyone, or perfect for every application, but rather that React's issues somehow stem from some kind of Facebook-y need for "control". That's an especially weird claim to make given how simple and open-ended React (by itself) is.