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

451–460 of 574 posts

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

#451

Post by esprehn »

phailhaus wrote: post #226
esprehn wrote: post #176

Earlier quoted context omitted.

That didn't require the meta language and rules of hooks though, they could have added this.addEffect(callback, deps) or something to class components. To preserve back compat they could have added a new base class you inherit from to get access to new APIs. Most of hooks could have been done incrementally on top of classes.

Imagine trying to debug a component that both has lifecycle methods and reactive hooks? That would be a total nightmare, especially when the same state is being updated in both places (because that would have to be allowed). Going all-in on hooks means that there are two distinct, independent ways of writing components, and you never have to deal with interactions between the two. I also don't think this would be pos…

Only if you're constrained by the existing API of hooks. Preact signals is a good example of how class components could have been improved with reactivity:

https://twitter.com/_developit/status/1567272951136788481

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

#452

Post by dragonwriter »

3vidence wrote: post #132
bornfreddy wrote: post #100

Earlier quoted context omitted.

Fair enough. Though, the first question is - why does the component do so many things? Do they all need to be in a single component or can you break them apart? For the cases when this is not possible, I agree, useEffect works better than classes lifecycle methods. But do you really want a system which caters to a small percent of use-cases at the expense of readability in others? And the improvement, to my eyes, is…

An issue I have with hooks are the names. "useEffect" is one of my least favorite function name in any library. What am I using? What is the effect?

> What am I using?

The effect.

> What is the effect?

The state-modifying (and thus side-effect-producing, or simply “effectful”) function passed as the first argument to useEffect.

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

#453

Post by rukuu001 »

daveguy wrote: post #355
throwaway0asd wrote: post #173

Earlier quoted context omitted.

I just use vanilla JS on the front-end just like I do with Node. I have never understood why people find state management challenging. I suppose its because they are stuck in a framework or MVC mindset where everything is a separate component and each must have separate state models that must be referenced frequently and independently. I just put all my state data in one object, save it on each user interaction, and…

> I suppose its because they are stuck in a framework or MVC mindset where everything is a separate component and each must have separate state models that must be referenced frequently and independently. I just put all my... Then you exactly describe MVC... > state data in one object, This is your model. > save it on each user interaction, This is your controller. > and use it only on page refresh. This is your view…

Yes I was confused by this. It’s MVC, but without React’s benefit of having the GUI update without a page refresh.

edit - fwiw I too am another heartbroken React dev

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

#454

Post by michaelsalim »

molszanski wrote: post #149

Hmm… let me be frank about my experiences with React. I’ve been using React heavily for far over 6 or 7 years. React is amazing. And what I see is that people find so many ways to shoot themselves in the foot. At the same time, I understand that batteries-not-included approach will lead to that result. First of all, people get out of their skin and try to make it a complicated and entangled mess. In programming, ther…

Fully agree with you. I think the issue is that people think about React imperatively. "When I press this button, it should do X" or "This input should update Y".

And then people start adding unnecessary useState or useEffect to their demise.

It's hard to blame them honestly. When React is one of the first thing you learn, you don't know the other possibilities. Many probably haven't used any framework outside it. And most probably don't know what problems React help solve.

And when they start developing, they solve problems by using what they know: The React tutorial that taught them to use useState and useEffect for every state and logic.

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

#456

Post by rk06 »

dtagames wrote: post #114
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…

Yes and I'm surprised no one has mentioned Lit or bare metal web components in this convo. I'm starting a large TS project at the AAA game studio where I work (my day job, not DTA) and it wasn't hard to choose to avoid React or Vue or Angular. Lit is the anti-framework because it isn't a framework. Once you remove all the cruft, you can spend a lot more time writing the code that you want to write and, doing so in th…

Because lit is too bare metal to qualify as a js framework. Does it have good solutions for router or state management? Last time i checked: No.

That is why it is not discussed that much. If you need to write components, then lit may work for you, but whoever wants to ise those components would prefer a js framework.

Also, lit is from Google. which makes it worse as Angular is from Google as well

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

#457

Post by mjr00 »

babyshake wrote: post #296
taeric wrote: post #240

Earlier quoted context omitted.

It really is hard to understate how damaging the half-finished ideas in the code base can be. To the point that I often prefer to stay on something I don't like, if I'm not positive I can finish moving completely off of it.

> It really is hard to understate how damaging the half-finished ideas in the code base can be. People get promoted for all the shiny new things they do, not for the discipline they show in only focusing on what really matters.

> People get promoted for all the shiny new things they do, not for the discipline they show in only focusing on what really matters.

Depends on the company and its values. I've been in companies where engineers who don't care about the business/customers were promoted by other engineers who don't care about the business/customers, and yeah, promotions were getting handed out for engineers who did a hacky prototype integration with the latest & greatest NoSQL Big Data GraphQL Blockchain OSS project while solving no actual problems. I've also been other places (Amazon) where customers really are front and center, and spending time on cool engineering projects that serve no customer purpose meant absolutely nothing when you wrote up your promotion doc.

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

#458

Post by rk06 »

rhodysurf wrote: post #174
jitl wrote: post #11

Maybe I’m a React apologist, but this list of complaints seems mostly self-inflicted. > Form libraries are portly maintained or documented The two-way data binding in Svelte saves ~4 lines of reusable hook function but doesn’t come close to covering defaults, validation, errors, dependent fields etc - all of that is essential complexity. Write your own form field hook. The state model for a form is simple - what is a…

To emphasize the dependency tracking part: being able to control when you want hooks to run is really powerful. Automatic isn’t always better

"Being able to write in assembly is really powerful. Higher level lang like java isn't always better"

Sure. but it is better for 99% tasks. And remaining 1% can be achieved via other APIs

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

#459

Post by earthboundkid »

corytheboyd wrote: post #190

I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each oth…

If you read Programming As If People Mattered from 1992, the frontend mess was true then too.

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

#460

Post by vore »

chrisco255 wrote: post #440
vore wrote: post #428

Earlier quoted context omitted.

Huh? react-hooks/exhaustive-deps does exactly that: it statically infers dependencies and is very noisy if you forget one, and the React team recommends that you always have it on. In fact, the React docs have this to say, right in the documentation for useEffect ( https://reactjs.org/docs/hooks-reference.html#conditionally-... ): The array of dependencies is not passed as arguments to the effect function. Conceptual…

The useEffect dependency array defines the values for which you want the effect function to trigger any time those values change. It is not always the case that you want an effect to trigger for every value used inside of an effect. Sometimes you only want an effect to run once (i.e. the empty array passed as deps). Sometimes a value changes too frequently to list as a dependency: https://reactjs.org/docs/hooks-faq.h…

The documentation you linked itself says to structure your code such that you are not taking dependencies inappropriately, not to omit bona fide dependencies from the dependencies array:

    Specifying [count] as a list of dependencies would fix the bug, but would cause the interval to be reset on every change. Effectively, each setInterval would get one chance to execute before being cleared (similar to a setTimeout.) That may not be desirable. To fix this, we can use the functional update form of setState. It lets us specify how the state needs to change without referencing the current state:
Post reply on HN