16 ms·

I started learning React for starting a large project a few months ago. I have not really liked the experience very much. One seems to still need to know all th

I started learning React for starting a large project a few months ago. I have not really liked the experience very much. One seems to still need to know all the JS/CSS/HTML I've been using for 10+ years but also a new stack on top of it, simultaneously. Hooks are one of the strangest features I've seen in a language yet. I doubt they will be a lasting paradigm outside of the React ecosystem. I like JSX a lot. The idea of reusable stateless components is totally on the right track. I've found React to be very hard to debug. I get stack traces that don't seem to start from any code I've written. I now somehow suspect that the next wave in the JS ecosystem will be doing something like microservices on the frontend - message passing between isolated webworkers? I ponder this because React has not, for me, achieved any level of enforcing a sane way of deciding which objects in memory belong to a given component. Something feels really wrong with the the React model of programming. Writing a project in React seems doubly frustrating - there's the challenge of a new stack and new programming model, but I don't seem to be getting anything for the trade: the code isn't easily debuggable, doesn't have a great upgrade and maintainability story, the app still has race conditions, memory leaks, browser incompatibilities, tightly coupled components. The problem seems to be that React only gently encourages, but does not enforce, any good practices.

quickthrower2 6y ago
You might want to watch this https://www.youtube.com/watch?v=i__969noyAM https://www.youtube.com/watch?v=i__969noyAM (2014) to see why React exists and the sort of problem it solves. But now in 2020 you have 2 reasons to pick React. One is because it's the right tool. The second is to do with the JS tech battlefield - you pick React because it won the front-end popularity fight, and is probably safe for the next 5 years, and you can hire React developers, and you can hire them knowing they will want to stay React developers etc. Yes all that BS! Also you might pick React for your own CV! Let's be honest!!
- FpUser 6y ago
  >"One is because it's the right tool. " Yeah sure. You choose the right tool because it it the right tool. >"The second is to do with the JS tech battlefield - you pick React because it won the front-end popularity fight" If we always pick "most popular" there will be only one left. >"you can hire React developers, and you can hire them knowing they will want to stay React developers etc." I guess some big companies might hire narrow scope developers (and throw those away when they the size of tool they were using changed from 9mm to 10mm). Me being more down to Earth I prefer to look at the resume and list of accomplished projects and hire persons who are creative and do not get fixated on a single thing. >"Also you might pick React for your own CV!" Sorry, no ;) I pick projects for money and being interesting. Using XYZ language/framework does not come as a reason into that picture for me.
  - quickthrower2 6y ago
    I agree with you on all these points! However the "market" behaves the way it behaves (in general), and we need to try to avoid the 99% of it.
    - FpUser 6y ago
      I like operating in niche markets. So far (fingers crossed) it pays my bills and frankly being independent I do not worry too much about common trends. Only what concerns me directly. Not that I am being ignorant, I constantly read stuff/play with it but as long as I can afford it I prefer to go the way I find suitable from my perspective. Do not give a hoot about some abstract everybody does this/that spoonfed by big companies.
- tartoran 6y ago
  I wouldn’t put all my eggs in one basket, things evolve rapidly on this front, 5 years is impossible to forsee
- yumindev 6y ago
  True
mikeryan 6y ago
Something is off with your transpiling set up if you’re not getting accurate stack traces. A “create react app” default setup will should have accurate stack traces out of the box. To your point about best practices React, at least at the beginning was not supposed to be the entire stack, by design you needed other libraries to deal with large portions of the web state and as such it could only control a small part of your stack. That being said with hooks and providers, it is gaining enough internal tooling to be almost “the whole stack” but still the philosophy remains.
- smallnamespace 6y ago
  What GP means is that the stack traces will often just point you to React’s runtime code. This is a general debugability problem that all runtimes have-you now need an understanding of how React’s implementation works to map the runtime’s state to what you’re attempting to do.
  - dragonwriter 6y ago
    > What GP means is that the stack traces will often just point you to React’s runtime code. I very rarely run into a case where that occurs, and almost never that doesn't involve ignoring one of the ESLint warnings that CRA sets up in its default settings. Now, getting the stack trace to only point you to some part of a component library's code seems more common.
    - jiofih 6y ago
      I run into this daily. There isn’t a single JS error in our monitoring that has a useful stack trace. It would have to extend another 30 layers down to start going into actual application components or code. They all look the same going through different bits of React internals.
      - TrevorLee 6y ago
        I click on my errors and they take me to the exact line of code that caused them.... basically the JS error throws the line number and file path and then my terminal setup makes it clickable. Usually it’s always the same error anyways. Something is undefined or typed wrong.
wbercx 6y ago
I too can't shake the feeling that hooks are off. I like JSX and the component model. In React and like-minded projects, I look at a stack trace and see that it starts at some kind of batch renderer. I can't tell "why", "how" or sometimes even "what" broke. The input part of it is completely lost. I work on a Backbone application where stack traces are much more obvious. They usually tell you the whole story. I find that juniors who were mostly exposed to React have a tendency to completely ignore stack traces, and am now wondering if they are just conditioned to them being unhelpful.
- unityByFreedom 6y ago
  > I too can't shake the feeling that hooks are off. Well the alternative to hooks is componentDidMount, componentDidUpdate, etc. It's a lot easier to sync state and UI when the logic for doing so can be put in one place.
  - ricksharp 6y ago
    I’ve been using hooks for a year, and they are awesome (once you get used to it). I can write the same component in 1/3 of the code in a functional style. The debugging story isn’t great if you expect to be able to use breakpoints. It’s all about putting console.log wherever really. The beauty comes in the speed of coding, I can move so fast that I always build a mock version of my api layer and can have the entire UI done rapidly.
    - gaoshan 6y ago
      You can throw in debugging statements (`debugger;`) when some hook doesn't seem to be hitting a breakpoint. Stops things just fine.
- acemarke 6y ago
  I worked on a Backbone app for several years (and still do, technically - we're about to do a final push to finish migrating it to React). I also liked the fact that you could step into Backbone code, and back out to app code on the other side. Backbone's source is small, and you can see exactly what it's doing. However... React is simply a fundamentally superior programming model, for a wide variety of reasons. I can treat React as a black box, knowing that if there's a problem in my UI, it's because of either the logic in my components, or the data those components are using for display. (Then there's things like being able to arbitrarily compose child components together and pass them props, vs randomly trying to attach subviews or something via umpteen different plugins.) I'll agree that seeing a stack trace with React library code isn't typically helpful. But, the error messages are usually sufficient to tell me what kind of an issue is going on, and point me to the right component or part of the tree to start debugging the real issue. Somewhat related to this, I put together an extensive post earlier this year called "A (Mostly) Complete Guide to React Rendering Behavior" [0] that digs into detail on how React's rendering actually works, as I've found that a lot of people seemed to be missing how some of the pieces of rendering fit together: [0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
iaml 6y ago
Best way to debug react is to do it via your IDE debug functionality, to enable debugger on caught errors (if you get errors in other code you usually can blackbox it) or to utilize `debugger;` command. Don't forget browser extension for cases where no error happens.
- bbaumgar 6y ago
  How can you apply this to debugging useEffect issues?
  - iaml 6y ago
    You can set breakpoint inside useEffect and it will work as expected, you can use something like if (somevar === 42) debugger; and you'll see all of the internal call stack and all variables in scope. moreover you can use the console to evaluate your code. Worth mentioning 99% of strange issues in react (in my experience) are caused by mutation or not declaring all deps in hooks.
rhizome 6y ago
I imagine all that is pretty easy to tolerate if Facebook is paying you a $ton to do so, and even more to invent it.
timothy-quinn 6y ago
The value of hooks became apparent to me after working with a very large react-redux application. It was so large and the forms had so many elements that the capture of data, testing, and subsequent state management in redux was enormous. It wasn't overly complicated from a technical perspective, but when there were forms with say 50-100 different inputs and dozens of state transitions, it was a mentally taxing experience every time to try to maintain the data model and state machine in my head when debugging or introducing changes. For me the introduction of hooks was amazing as it's allowed us to strip most of the redux state management in favour of managing state with hooks inside of functional components. We still use redux for global application state, but there are also hooks for interacting with that redux state too. We effectively went from class-based components in react-redux with say 500 LOC in each class, 500 LOC in each action file, 500 LOC in each reducer file, all the way down to about 700 LOC in each functional component file. I do agree though that debugging sucks. It's incrementally getting better, but it's got a long way to go.
- acemarke 6y ago
  FWIW, you should also switch to using our official Redux Toolkit package [0] if you haven't already. RTK is our recommended approach to writing Redux logic. It includes a number of utilities that build in our best practices, prevent common mistakes, and simplify most Redux use cases. Related to that, we've rewritten the Redux docs tutorials to teach use of Redux Toolkit and the React-Redux hooks API as the default, as well as using simpler patterns like structuring Redux logic as single-file "slices". See the new "Redux Essentials" [1] and "Redux Fundamentals" tutorials [2] for examples. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co... [2] https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-1-overview
  - hackerfromthefu 6y ago
    You should switch .. we've re-written .. does the re in react stand for rewrite? Not presented seriously, tongue in cheek only, but it's a serious concern!
stevebmark 6y ago
Hooks have unlocked a power in React and front end development we haven't seen before, that is going to lead to bigger things. I don't know if hooks are going to be the end state, but the ability to create reusable functionality encapsulated in a hook has solved a lot of problems we previously had of the awkwardness of sharing behavior across components.
- hackerfromthefu 6y ago
  Reusable encapsulated functionality for front end components has existed before in a number of front end frameworks, I can cite Delphi VCL and .NET Winforms as two I'm familiar with. Have a look at how tooltips are implemented in Winforms ..
cageface 6y ago
Hooks have a very nice synergy with Typescript. useEffect can be tricky to get right in some cases but overall a prefer writing in pure components with hooks over classes.
- richeyryan 6y ago
  Just a slight nitpick about components with hooks. They are neither pure nor functional. They are function components. We can still have pure components without hooks but function components are no longer pure by default. Its actually one of the downsides of the move to hooks. It used to be very obvious when you needed to worry about state and when you didn't. However the benefits of hooks outweigh that nicety in my opinion
Chris_Newton 6y ago
I like JSX a lot. The idea of reusable stateless components is totally on the right track. The latter is what I really liked about the early versions of React, back when it was seen as “the V in MVC”. The basic premise of having a declarative UI, so you only had to define what is rendered in terms of absolute state rather than relative transitions, was a good one. React’s virtual DOM mechanics made working that way reasonably efficient for most practical purposes. The rapid adoption in those early years is testament to how useful that combination of declarative+efficient really was. However, I feel like as time has passed, the emphasis in the community has shifted towards trying to shove more and more that isn’t view logic into the React/JSX parts of their code, and that has caused all kinds of unnecessary problems. At first it was as if, just because we had a tidy mechanism to write nested components easily using JSX, every little aspect of application behaviour was now supposed to be implemented as a component and shoved into the tree. This led to patterns like higher order components, and thence to more patterns trying to manage the added complexity introduced by having lots of non-rendering components wrapping everything. By this time, the inmates had taken over the asylum and any pretence of React being used primarily as a clean, declarative UI tool had been all but forgotten. The idea of managing application state separately and systematically was old long before React came along. Relational databases and ACID transactions had been a cornerstone of software architecture for decades by then, as had the idea of having a separate data model to hold and systematically update application state within desktop software. The early React community was clearly aware of these ideas as well, not just from the “V in MVC” description but also the idea of Flux and before long the Redux ecosystem. And yet, developers still often seemed to keep their application state within their React components instead, which predictably led to all the same problems that had once caused traditional GUIs to move away from retained mode and towards separate state management and immediate mode rendering in the first place. This in turn has led to interest from the React community in ideas like context, and today along with hooks we often see talk of replacing tools like Redux with React Context instead. It’s not just application state, either. We’ve seen more and more responsibilities pushed into React components over time. It doesn’t seem unusual to have those React components even dealing with communications to transfer state between the browser and the server now, along with all of the awkward mechanics like async fetching from APIs and cache management. Most recently, the talk is all about how great hooks are, because they let you consolidate or remove of lots of awkward logic that used to be spread through different lifecycle methods in class components. Sometimes, as with this article, the idea gets taken to an extreme. But I can’t help wondering how often anyone stops to ask whether 99% of that logic should ever have been tangled up with the rendering code of the application in the first place. Aren’t we in danger of regressing to big-ball-of-mud antipatterns, just using a big-tree-of-components instead this time around? How do you even test an application properly at scale if you’re forever tangling up your rendering logic, state management, client-server communications and who knows what else, and then obscuring much of it inside React components that end up being tightly coupled because they rely on a certain hierarchy to set everything up just right? React itself still seems like a useful tool for the same reasons as always, and functional components are a nice incremental improvement on the boilerplate that came with class components in the early days. But the grumpy old man in me can’t help feeling that a lot of the other “progress” in the React ecosystem has been more a series of missteps taken because those who don’t study history are doomed to repeat it. There is still a lot to be said today for using React as a nice, clean, reasonably efficient rendering library for your UI, and for keeping other concerns like state management and network communications separate and using the right tools for each job.
revskill 6y ago
Agree about the hard to debug problem with React. Especially in SPA routing, normal navigation works fine, but in some cases, SPA navigation breaks the new route just because SPA routing is not stateless somehow.
mrozbarry 6y ago
I've stated several times that hooks are awful, and the general response I get is "oh, you just don't get it," but the way they are implemented is not very functional, but I guess the point is that they are side effects. In terms of other things, JSX has nothing to do with stateless components, it's just a way to simplify writing `React.createElement(yourElementOrTagName, { ...props }, [ ...children ]);` And for debugging, the absolute best advice I can give is to build smaller components, and use something like storybook to demo/isolate behaviour and tinker with it. In general, react is a perfectly fine choice, though. I don't think it's any more strange than angular/vue/hyperapp/etc., but it is certainly lower level, which can feel less intuitive.

quickthrower2 6y ago

You might want to watch this https://www.youtube.com/watch?v=i__969noyAM https://www.youtube.com/watch?v=i__969noyAM (2014) to see why React exists and the sort of problem it solves. But now in 2020 you have 2 reasons to pick React. One is because it's the right tool. The second is to do with the JS tech battlefield - you pick React because it won the front-end popularity fight, and is probably safe for the next 5 years, and you can hire React developers, and you can hire them knowing they will want to stay React developers etc. Yes all that BS! Also you might pick React for your own CV! Let's be honest!!

FpUser 6y ago
>"One is because it's the right tool. " Yeah sure. You choose the right tool because it it the right tool. >"The second is to do with the JS tech battlefield - you pick React because it won the front-end popularity fight" If we always pick "most popular" there will be only one left. >"you can hire React developers, and you can hire them knowing they will want to stay React developers etc." I guess some big companies might hire narrow scope developers (and throw those away when they the size of tool they were using changed from 9mm to 10mm). Me being more down to Earth I prefer to look at the resume and list of accomplished projects and hire persons who are creative and do not get fixated on a single thing. >"Also you might pick React for your own CV!" Sorry, no ;) I pick projects for money and being interesting. Using XYZ language/framework does not come as a reason into that picture for me.
- quickthrower2 6y ago
  I agree with you on all these points! However the "market" behaves the way it behaves (in general), and we need to try to avoid the 99% of it.
  - FpUser 6y ago
    I like operating in niche markets. So far (fingers crossed) it pays my bills and frankly being independent I do not worry too much about common trends. Only what concerns me directly. Not that I am being ignorant, I constantly read stuff/play with it but as long as I can afford it I prefer to go the way I find suitable from my perspective. Do not give a hoot about some abstract everybody does this/that spoonfed by big companies.
tartoran 6y ago
I wouldn’t put all my eggs in one basket, things evolve rapidly on this front, 5 years is impossible to forsee
yumindev 6y ago
True

mikeryan 6y ago

Something is off with your transpiling set up if you’re not getting accurate stack traces. A “create react app” default setup will should have accurate stack traces out of the box. To your point about best practices React, at least at the beginning was not supposed to be the entire stack, by design you needed other libraries to deal with large portions of the web state and as such it could only control a small part of your stack. That being said with hooks and providers, it is gaining enough internal tooling to be almost “the whole stack” but still the philosophy remains.

smallnamespace 6y ago
What GP means is that the stack traces will often just point you to React’s runtime code. This is a general debugability problem that all runtimes have-you now need an understanding of how React’s implementation works to map the runtime’s state to what you’re attempting to do.
- dragonwriter 6y ago
  > What GP means is that the stack traces will often just point you to React’s runtime code. I very rarely run into a case where that occurs, and almost never that doesn't involve ignoring one of the ESLint warnings that CRA sets up in its default settings. Now, getting the stack trace to only point you to some part of a component library's code seems more common.
  - jiofih 6y ago
    I run into this daily. There isn’t a single JS error in our monitoring that has a useful stack trace. It would have to extend another 30 layers down to start going into actual application components or code. They all look the same going through different bits of React internals.
    - TrevorLee 6y ago
      I click on my errors and they take me to the exact line of code that caused them.... basically the JS error throws the line number and file path and then my terminal setup makes it clickable. Usually it’s always the same error anyways. Something is undefined or typed wrong.

wbercx 6y ago

I too can't shake the feeling that hooks are off. I like JSX and the component model. In React and like-minded projects, I look at a stack trace and see that it starts at some kind of batch renderer. I can't tell "why", "how" or sometimes even "what" broke. The input part of it is completely lost. I work on a Backbone application where stack traces are much more obvious. They usually tell you the whole story. I find that juniors who were mostly exposed to React have a tendency to completely ignore stack traces, and am now wondering if they are just conditioned to them being unhelpful.

unityByFreedom 6y ago
> I too can't shake the feeling that hooks are off. Well the alternative to hooks is componentDidMount, componentDidUpdate, etc. It's a lot easier to sync state and UI when the logic for doing so can be put in one place.
- ricksharp 6y ago
  I’ve been using hooks for a year, and they are awesome (once you get used to it). I can write the same component in 1/3 of the code in a functional style. The debugging story isn’t great if you expect to be able to use breakpoints. It’s all about putting console.log wherever really. The beauty comes in the speed of coding, I can move so fast that I always build a mock version of my api layer and can have the entire UI done rapidly.
  - gaoshan 6y ago
    You can throw in debugging statements (`debugger;`) when some hook doesn't seem to be hitting a breakpoint. Stops things just fine.
acemarke 6y ago
I worked on a Backbone app for several years (and still do, technically - we're about to do a final push to finish migrating it to React). I also liked the fact that you could step into Backbone code, and back out to app code on the other side. Backbone's source is small, and you can see exactly what it's doing. However... React is simply a fundamentally superior programming model, for a wide variety of reasons. I can treat React as a black box, knowing that if there's a problem in my UI, it's because of either the logic in my components, or the data those components are using for display. (Then there's things like being able to arbitrarily compose child components together and pass them props, vs randomly trying to attach subviews or something via umpteen different plugins.) I'll agree that seeing a stack trace with React library code isn't typically helpful. But, the error messages are usually sufficient to tell me what kind of an issue is going on, and point me to the right component or part of the tree to start debugging the real issue. Somewhat related to this, I put together an extensive post earlier this year called "A (Mostly) Complete Guide to React Rendering Behavior" [0] that digs into detail on how React's rendering actually works, as I've found that a lot of people seemed to be missing how some of the pieces of rendering fit together: [0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

iaml 6y ago

Best way to debug react is to do it via your IDE debug functionality, to enable debugger on caught errors (if you get errors in other code you usually can blackbox it) or to utilize `debugger;` command. Don't forget browser extension for cases where no error happens.

bbaumgar 6y ago
How can you apply this to debugging useEffect issues?
- iaml 6y ago
  You can set breakpoint inside useEffect and it will work as expected, you can use something like if (somevar === 42) debugger; and you'll see all of the internal call stack and all variables in scope. moreover you can use the console to evaluate your code. Worth mentioning 99% of strange issues in react (in my experience) are caused by mutation or not declaring all deps in hooks.

rhizome 6y ago

I imagine all that is pretty easy to tolerate if Facebook is paying you a $ton to do so, and even more to invent it.

timothy-quinn 6y ago

The value of hooks became apparent to me after working with a very large react-redux application. It was so large and the forms had so many elements that the capture of data, testing, and subsequent state management in redux was enormous. It wasn't overly complicated from a technical perspective, but when there were forms with say 50-100 different inputs and dozens of state transitions, it was a mentally taxing experience every time to try to maintain the data model and state machine in my head when debugging or introducing changes. For me the introduction of hooks was amazing as it's allowed us to strip most of the redux state management in favour of managing state with hooks inside of functional components. We still use redux for global application state, but there are also hooks for interacting with that redux state too. We effectively went from class-based components in react-redux with say 500 LOC in each class, 500 LOC in each action file, 500 LOC in each reducer file, all the way down to about 700 LOC in each functional component file. I do agree though that debugging sucks. It's incrementally getting better, but it's got a long way to go.

acemarke 6y ago
FWIW, you should also switch to using our official Redux Toolkit package [0] if you haven't already. RTK is our recommended approach to writing Redux logic. It includes a number of utilities that build in our best practices, prevent common mistakes, and simplify most Redux use cases. Related to that, we've rewritten the Redux docs tutorials to teach use of Redux Toolkit and the React-Redux hooks API as the default, as well as using simpler patterns like structuring Redux logic as single-file "slices". See the new "Redux Essentials" [1] and "Redux Fundamentals" tutorials [2] for examples. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co... [2] https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-1-overview
- hackerfromthefu 6y ago
  You should switch .. we've re-written .. does the re in react stand for rewrite? Not presented seriously, tongue in cheek only, but it's a serious concern!

stevebmark 6y ago

Hooks have unlocked a power in React and front end development we haven't seen before, that is going to lead to bigger things. I don't know if hooks are going to be the end state, but the ability to create reusable functionality encapsulated in a hook has solved a lot of problems we previously had of the awkwardness of sharing behavior across components.

hackerfromthefu 6y ago
Reusable encapsulated functionality for front end components has existed before in a number of front end frameworks, I can cite Delphi VCL and .NET Winforms as two I'm familiar with. Have a look at how tooltips are implemented in Winforms ..

cageface 6y ago

Hooks have a very nice synergy with Typescript. useEffect can be tricky to get right in some cases but overall a prefer writing in pure components with hooks over classes.

richeyryan 6y ago
Just a slight nitpick about components with hooks. They are neither pure nor functional. They are function components. We can still have pure components without hooks but function components are no longer pure by default. Its actually one of the downsides of the move to hooks. It used to be very obvious when you needed to worry about state and when you didn't. However the benefits of hooks outweigh that nicety in my opinion

Chris_Newton 6y ago

I like JSX a lot. The idea of reusable stateless components is totally on the right track. The latter is what I really liked about the early versions of React, back when it was seen as “the V in MVC”. The basic premise of having a declarative UI, so you only had to define what is rendered in terms of absolute state rather than relative transitions, was a good one. React’s virtual DOM mechanics made working that way reasonably efficient for most practical purposes. The rapid adoption in those early years is testament to how useful that combination of declarative+efficient really was. However, I feel like as time has passed, the emphasis in the community has shifted towards trying to shove more and more that isn’t view logic into the React/JSX parts of their code, and that has caused all kinds of unnecessary problems. At first it was as if, just because we had a tidy mechanism to write nested components easily using JSX, every little aspect of application behaviour was now supposed to be implemented as a component and shoved into the tree. This led to patterns like higher order components, and thence to more patterns trying to manage the added complexity introduced by having lots of non-rendering components wrapping everything. By this time, the inmates had taken over the asylum and any pretence of React being used primarily as a clean, declarative UI tool had been all but forgotten. The idea of managing application state separately and systematically was old long before React came along. Relational databases and ACID transactions had been a cornerstone of software architecture for decades by then, as had the idea of having a separate data model to hold and systematically update application state within desktop software. The early React community was clearly aware of these ideas as well, not just from the “V in MVC” description but also the idea of Flux and before long the Redux ecosystem. And yet, developers still often seemed to keep their application state within their React components instead, which predictably led to all the same problems that had once caused traditional GUIs to move away from retained mode and towards separate state management and immediate mode rendering in the first place. This in turn has led to interest from the React community in ideas like context, and today along with hooks we often see talk of replacing tools like Redux with React Context instead. It’s not just application state, either. We’ve seen more and more responsibilities pushed into React components over time. It doesn’t seem unusual to have those React components even dealing with communications to transfer state between the browser and the server now, along with all of the awkward mechanics like async fetching from APIs and cache management. Most recently, the talk is all about how great hooks are, because they let you consolidate or remove of lots of awkward logic that used to be spread through different lifecycle methods in class components. Sometimes, as with this article, the idea gets taken to an extreme. But I can’t help wondering how often anyone stops to ask whether 99% of that logic should ever have been tangled up with the rendering code of the application in the first place. Aren’t we in danger of regressing to big-ball-of-mud antipatterns, just using a big-tree-of-components instead this time around? How do you even test an application properly at scale if you’re forever tangling up your rendering logic, state management, client-server communications and who knows what else, and then obscuring much of it inside React components that end up being tightly coupled because they rely on a certain hierarchy to set everything up just right? React itself still seems like a useful tool for the same reasons as always, and functional components are a nice incremental improvement on the boilerplate that came with class components in the early days. But the grumpy old man in me can’t help feeling that a lot of the other “progress” in the React ecosystem has been more a series of missteps taken because those who don’t study history are doomed to repeat it. There is still a lot to be said today for using React as a nice, clean, reasonably efficient rendering library for your UI, and for keeping other concerns like state management and network communications separate and using the right tools for each job.

revskill 6y ago

Agree about the hard to debug problem with React. Especially in SPA routing, normal navigation works fine, but in some cases, SPA navigation breaks the new route just because SPA routing is not stateless somehow.

mrozbarry 6y ago

I've stated several times that hooks are awful, and the general response I get is "oh, you just don't get it," but the way they are implemented is not very functional, but I guess the point is that they are side effects. In terms of other things, JSX has nothing to do with stateless components, it's just a way to simplify writing `React.createElement(yourElementOrTagName, { ...props }, [ ...children ]);` And for debugging, the absolute best advice I can give is to build smaller components, and use something like storybook to demo/isolate behaviour and tinker with it. In general, react is a perfectly fine choice, though. I don't think it's any more strange than angular/vue/hyperapp/etc., but it is certainly lower level, which can feel less intuitive.