Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React I love you, but you're bringing me down

marmelab.com

Post reply on HN
Print view View original

121–130 of 574 posts

Re: React I love you, but you're bringing me down

#121

Post by padseeker »

If you are using that many refs you built it wrong - from the React documentation (https://reactjs.org/docs/refs-and-the-dom.htmlhttps://reactj...

"There are a few good use cases for refs:

  Managing focus, text selection, or media playback.
  Triggering imperative animations.
  Integrating with third-party DOM libraries.
  Avoid using refs for anything that can be done declaratively.
...

Don’t Overuse Refs:

  Your first inclination may be to use refs to “make things happen” in your app. If this is the case, take a moment and think more critically about where state should be owned in the component hierarchy. Often, it becomes clear that the proper place to “own” that state is at a higher level in the hierarchy. See the Lifting State Up guide for examples of this."
If you are using refs to talk to your child inputs you've made a mistake. React talks about RAISING THE STATE - for complex forms you need to make all of your inputs controlled, you need to manage the state at the highest level. You need to push those changes down to child components, none of them should have their own state.

React gives you some nice tools to handle most common use cases but you can still make less than optimal decisions.

Re: React I love you, but you're bringing me down

#123

Post by 3vidence »

nonethewiser wrote: post #46

I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

I overall agree. I use functional style programming a lot but for some reason hooks have always confused me. The component classes generally make sense to me and map onto other paradigms like flutter, vue, etc.

Sure methods like componentDidMount are a mouthful but I found it much more explicit

Re: React I love you, but you're bringing me down

#124

Post by azangru »

ravenstine wrote: post #21
qprofyeh wrote: post #4

One could argue that it's not that React can't handle increasingly complex situations for you and that's why you spend more time on them, but that frontend as a craft has evolved due to React having solved the easy parts and has raised the bar, and therefore these complex situations belong to the next breeding site wherein the community is arguing about new solutions all the time, at the current time. It's healthy to…

What React does is no longer novel. People have both cloned React and have made other libraries/frameworks that accomplish the same thing differently or even faster in some cases. Frontend craft has also become too complex in general. We really need to step back and decide whether all this fucking shit around SPA, SSR, route splitting, transpiling, everything-as-a-type, "me too" features between frameworks, overempha…

> React takes us forward in the sense that most of us don't want to go back to direct DOM manipulation

There was recently a demo of what a Todo MVC app might look like if written in vanilla JS with today's apis. It looks fairly decent; I could see myself going back to something like that:

https://frontendmasters.com/blog/vanilla-javascript-todomvc/

Re: React I love you, but you're bringing me down

#125

Post by simon83 »

I was a huge React fan myself but when I started to use Vue and its Composition API one year ago I had tears of joy in my eyes. You have a setup function that is executed exactly once. Inside this setup function you setup your life cycle callbacks, reactive state variables and so on. This is how I wish React + Hooks should have been. Nowadays I won't even accept projects that use React anymore, exactly because of all the pain points OP mentioned.

SolidJS is following the same principle like Vue + Composition API. I think Svelte is also in the same boat. This kind of pattern is so much easier to use and reason about. React Hooks become really painful and annoying really fast.

Re: React I love you, but you're bringing me down

#126

Post by dsiegel2275 »

throwaway284534 wrote: post #10

As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React. For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to…

We have had success in migrating away from React, and in fact away from client-side code altogether by building more and more of the UI of our Elixir/Phoenix backed application in Phoenix LiveView. There are still some parts of system that really need to be client-side code powered (a WYSIWYG HTML editor, for example) but now our default choice for new UI is LiveView.

Re: React I love you, but you're bringing me down

#127

Post by bobbylarrybobby »

wpietri wrote: post #93
jwlake wrote: post #82

Earlier quoted context omitted.

I use functional components only for things without state. If anything has state I use class components because otherwise you go mad. ;)

Could you say more about this? I'm not a React user, but to me one of the OO fundamentals is "object = behavior + state". What you're saying sounds so obviously correct to me that I guess there's something pretty weird going on in React-land?

Yes, there is something very weird indeed. Functional components are called every time they're rendered (that's not weird). But they have to maintain state between calls; they can't start over again fresh for each call/render (still not weird). So how do they do this? `const [state, setState] = useState(initialValue)`. You might look at that and think, I see useState being called, so it must be called on each render, so state is still not being preserved between calls.

But here's the weirdness. useState knows whether it's already been called for a given component; this is how it tracks state. The first call returns the state (the initial value) and a setter. Subsequent calls -- occurring after the first render -- do not return these objects anew, but instead reach into a per-functional-component store and return the values that already exist there. Calling the setter doesn't set the state in the body; rather, it updates the value in the store, then triggers a re-render.

If you're wondering just how react knows how to match up calls to useState between renders, it doesn't really. It simply matches them up based on the order they're called in. For that reason, you have to always call exactly the same useState calls on each render -- no putting some in an if statement or a variable length for loop, otherwise they'll be out of sync.

There are a bunch of other "hooks" for use in functional components, but they all work basically the same way: place some data in the functional component's store, then set up re-render (which, again, just means calling the component's function again) to occur when certain data changes.

Re: React I love you, but you're bringing me down

#128

Post by nophunphil »

egeozcan wrote: post #39
nophunphil wrote: post #18

Earlier quoted context omitted.

I’m also a developer and tech lead who’s been working with React since the beta. Agreed with all your points about React. I’m not sure I would say Svelte and Solid are a farther step off the “just JavaScript” path than React given JSX though. I haven’t tried Solid, but Svelte has already paid considerable dividends for our team. Frontend feature development pace is faster, the code is generally leaner, and the develo…

I'm also a TL (which makes me a teaspoon here in Germany, which I like more than the tech lead title). I understand how the development can be faster with Svelte, but ecosystem argument really hits home. You'd get to 80% with Svelte perhaps much faster than React, but that missing library for, say, drag-and-drop makes that last 20% itself plus "hey let's develop our own drag-and-drop library in-house which should be…

All excellent points. Yes, the package ecosystem has been a pain point.

We’ve turned this into a slight positive by pushing the business to allow us to make open source contributions. The developers seem to enjoy this a lot, and hopefully our work helps others in the space.

Re: React I love you, but you're bringing me down

#129

Post by colordrops »

throwaway284534 wrote: post #10

As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React. For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to…

Been using various web component frameworks in enterprise level projects and have been very happy with them (Polymer, Lit, other custom frameworks as well). The nice thing is that since they are standards based you know that they will be around for the long haul and will have a more measured evolution.

Re: React I love you, but you're bringing me down

#130

Post by AlwaysRock »

BilalBudhani wrote: post #97
nonethewiser wrote: post #46

I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

I ditched React soon after they released hooks, mainly because I couldn't relate to the tradeoff React roadmap was taking from there. They went in a different direction from that point onwards, it seem like whatever code you write will become obsolete with the new set of best practices in the next release cycle. More importantly, I realized React is trying to tame Facebook level of problems and hence their design dec…

I don't have a strong opinion either way but if you left React because you are frustrated with code becoming obsolete and picked up Hotwire, a significantly smaller framework, arnt you likely to run into the same problem if Hotwire doesnt end up being the next big framework?

In 5 years if no one else is using Hotwire then your code is obsolete, no?

I liked working in next.js in the past but my company was already talking about Nuxt.js when we hadnt even fully converted to next. Feels like jumping ships from a ship with some major flaws, but will continue to float for x+ years, onto a lifeboat that may or may not make it another 500 feet before sinking.

Post reply on HN