4 ms·

I've just started playing with React and my general opinion is that it's a very 'Facebook' project. Lots of restrictions on what you can do and when keeping al

by kruhft 11y ago

I've just started playing with React and my general opinion is that it's a very 'Facebook' project. Lots of restrictions on what you can do and when keeping all of the coders in line with what you're supposed to be doing and following the 'Facebook' way of programming. I'm sure it's great for writing traditional crud apps, but anything outside of the box that it wasn't intended is a major pain requiring major hacks just to get around it's ideas of data protection and timing. I'm sure there are plenty that like this rigidity, but for me, I'll pass.

tptacek 11y ago
This is the weirdest argument I've ever heard against React, and, as someone who does a fair bit of React work, I try to pay attention to all those arguments.
- kruhft 11y ago
  Just my experience. Obviously not one that's common, but I was also doing something quite a bit different than most people that use it, I'm sure.
  - HeyImAlex 11y ago
    What were you doing?
    - kruhft 11y ago
      Writing a 'driver' to integrate my low level UI component library to be usable with React. My major issue was the 'rule' that a parent can't access the 'state' of it's children; this turned a 2 hour job into a 3 day job for me just trying to find a way to get access to this state through all of the lifecycle callbacks while instantiating children at the same time. When asked in #reactjs, they said that if you need access to a child's state you should put it into the parent, which makes sense but not in my case. There is a natural way of hiding working 'upwards' through the chain, but I can't say I've seen it ever work downwards like in React, and I found that rather frustrating and difficult to work around.
      - ktRolster 11y ago
        > this turned a 2 hour job into a 3 day job for me > just trying to find a way That basically summarizes my entire career with CSS/HTML/Javascript. "Oh, the page you made looks great! Can you just move that image 10 pixels to the left?" Spend two days hitting my head on the desk trying to figure out why it won't align correctly "Oh, the page you made looks great! Except in IE and the version of Chrome on Android 4.0.3" Spend two days trying to fix those browsers without breaking the others
      - dsp1234 11y ago
        One of react's core tenets is unidirectional data flow. Trying to use it in a bidirectional way is... painful. There is also a struggle with state vs props. The quick version is that state is internal to a component and is changeable directly by it, and props are given out by the parent and are not directly changeable. Generally the way the bidirectional issue is solved is by closing the loop via dispatchers and stores. The child components send out actions to the stores, which then flow down through the parent, back in to the child. Turning what used to be a bidirectional flow to a unidirectional flow (sometimes at the cost of a bit of boilerplate for pre-existing components). I guess the real question is, what is the use for the parent to be able to see the 'state' (the child components internal state)? The answer to that question (in my limited experience) has often been either 'to trigger an event (ex: save a form)' or 'so the parent can make some other rendering decision'. Both of which I've generally been able to solve via a flux implementation and possibly changing a 'state' into a 'prop' in the child (where the child gets a prop, some action is taken, and instead of changing state internally, an event is dispatched to the store with the new data, and the parent rerenders the child with the new 'prop'). But ultimately, hack it how you need. It's your code after all.
      - AgentME 11y ago
        Put ref properties on the child components. Put public methods on the child components. You can then access the refs from the parent in the parent's componentDidMount or componentDidUpdate methods.
        kruhft 11y ago
- 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...
- kruhft 11y ago
  I don't see how a desire for flexibility (hackability) is a weird argument. But I do see why React works this way to keep the hacking to minimum; unfortunately I needed to 'hack' react to do what I was doing and found it's use of readonly variables and state setting and availability during the lifecycle process to be highly frustrating.
badthingfactory 11y ago
React is actually a poor choice for traditional CRUD apps in my opinion. React is at its best when you have a large amount of state to manage.

by kruhft 11y ago

tptacek 11y ago

This is the weirdest argument I've ever heard against React, and, as someone who does a fair bit of React work, I try to pay attention to all those arguments.

kruhft 11y ago
Just my experience. Obviously not one that's common, but I was also doing something quite a bit different than most people that use it, I'm sure.
- HeyImAlex 11y ago
  What were you doing?
  - kruhft 11y ago
    Writing a 'driver' to integrate my low level UI component library to be usable with React. My major issue was the 'rule' that a parent can't access the 'state' of it's children; this turned a 2 hour job into a 3 day job for me just trying to find a way to get access to this state through all of the lifecycle callbacks while instantiating children at the same time. When asked in #reactjs, they said that if you need access to a child's state you should put it into the parent, which makes sense but not in my case. There is a natural way of hiding working 'upwards' through the chain, but I can't say I've seen it ever work downwards like in React, and I found that rather frustrating and difficult to work around.
    - ktRolster 11y ago
      > this turned a 2 hour job into a 3 day job for me > just trying to find a way That basically summarizes my entire career with CSS/HTML/Javascript. "Oh, the page you made looks great! Can you just move that image 10 pixels to the left?" Spend two days hitting my head on the desk trying to figure out why it won't align correctly "Oh, the page you made looks great! Except in IE and the version of Chrome on Android 4.0.3" Spend two days trying to fix those browsers without breaking the others
    - dsp1234 11y ago
      One of react's core tenets is unidirectional data flow. Trying to use it in a bidirectional way is... painful. There is also a struggle with state vs props. The quick version is that state is internal to a component and is changeable directly by it, and props are given out by the parent and are not directly changeable. Generally the way the bidirectional issue is solved is by closing the loop via dispatchers and stores. The child components send out actions to the stores, which then flow down through the parent, back in to the child. Turning what used to be a bidirectional flow to a unidirectional flow (sometimes at the cost of a bit of boilerplate for pre-existing components). I guess the real question is, what is the use for the parent to be able to see the 'state' (the child components internal state)? The answer to that question (in my limited experience) has often been either 'to trigger an event (ex: save a form)' or 'so the parent can make some other rendering decision'. Both of which I've generally been able to solve via a flux implementation and possibly changing a 'state' into a 'prop' in the child (where the child gets a prop, some action is taken, and instead of changing state internally, an event is dispatched to the store with the new data, and the parent rerenders the child with the new 'prop'). But ultimately, hack it how you need. It's your code after all.
    - AgentME 11y ago
      Put ref properties on the child components. Put public methods on the child components. You can then access the refs from the parent in the parent's componentDidMount or componentDidUpdate methods.
      - kruhft 11y ago
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...
kruhft 11y ago
I don't see how a desire for flexibility (hackability) is a weird argument. But I do see why React works this way to keep the hacking to minimum; unfortunately I needed to 'hack' react to do what I was doing and found it's use of readonly variables and state setting and availability during the lifecycle process to be highly frustrating.

badthingfactory 11y ago

React is actually a poor choice for traditional CRUD apps in my opinion. React is at its best when you have a large amount of state to manage.