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

React Labs: What We've Been Working On – February 2024

react.dev

Post reply on HN
Print view View original

121–130 of 130 posts

Re: React Labs: What We've Been Working On – February 2024

#121

Post by sunaurus »

baobabKoodaa wrote: post #111
selfmodruntime wrote: post #104

Earlier quoted context omitted.

I do not get that class components are in any way simpler. Before, you had to think about explicit configuration states during the components entire lifecycle. Now, you just... don't?

Previously everything was explicitly in your code. Now everything is done with "magic" outside your code. You're saying that this is better because now I "don't have to think about it". But I do! When something doesn't work, you have to figure it out. It's easier to debug code that you can see and reason with, and more difficult to debug a black box that behaves in mysterious and unexplainable ways. What you're proba…

That's interesting. My feeling is that things became MORE explicit with hooks, not less, so I'm quite confused still.

> What you're probably thinking is "it's faster to write a TODO example app with hooks". That's not really relevant for actual software development.

For me, that's not the case at all. I think with hooks, it's easier to reason about what values are actually used during what renders.

Re: React Labs: What We've Been Working On – February 2024

#122

Post by sesm »

Rapzid wrote: post #117
sesm wrote: post #38

Earlier quoted context omitted.

MobX re-introduces all push-reactivity problems that React removes.

Can you elaborate on this? React's in-built reactivity system via props and context are certainly push. I'm not even aware of a pull-based reactivity system.

React developers wrote about this here: https://legacy.reactjs.org/docs/design-principles.html#sched...

Let me try to explain this differently:

A typical reactive framework architecture (RX, Knockout, etc) looks like this

Events -> Observables -> Computed values -> Subscriptions -> DOM updates

It aims to provide a targeted DOM update in response to event as soon as possible, but it has several major disadvantages:

1. Batching and prioritizing capabilities either don't exist, or are limited and generic, in particular by default they are not tied to UI structure, because the framework itself doesn't want to be aware of UI structure, it just wants the framework user to provide event sources and write update targets manually.

2. Computed values are computed if corresponding subscriptions are active. In contrast, React hides state propagation logic inside the component tree, so the computation happens only when components are actually rendered.

Issue 1 is not relevant for MobX-React case, because React is doing UI update batching and prioritisation. But issue 2 is very real, especially when using React Router. I had multiple cases where Computed values were computed at unexpected point in time and used observable values that were not initialised, while corresponding React components were not even visible on the screen.

Re: React Labs: What We've Been Working On – February 2024

#123

Post by lakpan »

acemarke wrote: post #113
lakpan wrote: post #66

Earlier quoted context omitted.

React is fine, but what is going on with RTK? So. Much. Boilerplate.

Hi, I'm a Redux maintainer. I'm kind of confused by your comment in a couple ways. I'm not sure why you're jumping to discussing Redux here - we're a completely separate project from React, and nothing about the parent comment mentioned Redux. That said, we specifically created and designed RTK to _eliminate_ boilerplate, so I'm not sure what "boilerplate" you're referring to here. Could you give some specific exampl…

I’m neither a React nor Redux developer, but I work on React codebases. The code I see for simple changes is super verbose compared to what it would look like with simple hooks. I don’t know if it’s just my coworkers that suck at it.

Re: React Labs: What We've Been Working On – February 2024

#124

Post by satvikpendem »

omeid2 wrote: post #119
satvikpendem wrote: post #84

Earlier quoted context omitted.

I'm assuming you mean `useReducer` with `useContext`, but note that they are not a replacement for Redux: https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

That article makes a lot of hand-wavy assertion and makes up strange definitions. userReducer, specially with useContext does absolutely replace Redux and provide mechanism for state management. The article is, in short, just wrong.

The main point is here: https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

Context updates all components while Redux and similar state management tools, because they live outside of React, do not. That's the main reason to use true state management tools over context. If you have a relatively small application or you don't care about that, continue using context. The article is also by a Redux core maintainer so you might call that biased but they know what they're talking about, since they're privy to React design decisions much more than regular users.

Re: React Labs: What We've Been Working On – February 2024

#125

Post by acemarke »

lakpan wrote: post #123
acemarke wrote: post #113

Earlier quoted context omitted.

Hi, I'm a Redux maintainer. I'm kind of confused by your comment in a couple ways. I'm not sure why you're jumping to discussing Redux here - we're a completely separate project from React, and nothing about the parent comment mentioned Redux. That said, we specifically created and designed RTK to _eliminate_ boilerplate, so I'm not sure what "boilerplate" you're referring to here. Could you give some specific exampl…

I’m neither a React nor Redux developer, but I work on React codebases. The code I see for simple changes is super verbose compared to what it would look like with simple hooks. I don’t know if it’s just my coworkers that suck at it.

Redux will never be the _absolute_ shortest way to write updates - it intentionally adds a level of indirection (the concept of "dispatching actions").

That said, we specifically created Redux Toolkit to drastically simplify standard Redux usage patterns. Sadly, despite it being the default way to write Redux apps for several years now, there's still a lot of legacy Redux code that isn't following our recommended patterns.

See our "Migrating to Modern Redux" guide for details:

- https://redux.js.org/usage/migrating-to-modern-redux

as well as the "Style Guide" best practices page:

- https://redux.js.org/style-guide/

Re: React Labs: What We've Been Working On – February 2024

#126

Post by nickisnoble »

sesm wrote: post #102
bilekas wrote: post #87

Earlier quoted context omitted.

> Because nothing beats immediate-mode-style API in terms of code clarity. This is not React these days at all. Maybe when it was just an actually useful library. Not a hope now. > It became the most popular in the landscape where all kinds of other frameworks existed It became popular because it was simple, when it was simple. Then they did what all JS developers do. Find a problem for a solution.

Did you write React with class-based components? Do you think CWM/CWU/CWRP is better than useEffect, or constructor/setState is better than useState?

Yes, because those methods were actually obvious and said what they did.

Hooks are very non obvious / full of gotchas, and made react code no longer "just javascript".

Re: React Labs: What We've Been Working On – February 2024

#127

Post by baobabKoodaa »

sunaurus wrote: post #121
baobabKoodaa wrote: post #111

Earlier quoted context omitted.

Previously everything was explicitly in your code. Now everything is done with "magic" outside your code. You're saying that this is better because now I "don't have to think about it". But I do! When something doesn't work, you have to figure it out. It's easier to debug code that you can see and reason with, and more difficult to debug a black box that behaves in mysterious and unexplainable ways. What you're proba…

That's interesting. My feeling is that things became MORE explicit with hooks, not less, so I'm quite confused still. > What you're probably thinking is "it's faster to write a TODO example app with hooks". That's not really relevant for actual software development. For me, that's not the case at all. I think with hooks, it's easier to reason about what values are actually used during what renders.

> For me, that's not the case at all. I think with hooks, it's easier to reason about what values are actually used during what renders.

Hmmh. Can you provide me an example of what would've been "unclear" if the value was just state in a Class component?

Re: React Labs: What We've Been Working On – February 2024

#128

Post by omeid2 »

satvikpendem wrote: post #124
omeid2 wrote: post #119

Earlier quoted context omitted.

That article makes a lot of hand-wavy assertion and makes up strange definitions. userReducer, specially with useContext does absolutely replace Redux and provide mechanism for state management. The article is, in short, just wrong.

The main point is here: https://blog.isquaredsoftware.com/2021/01/context-redux-diff... Context updates all components while Redux and similar state management tools, because they live outside of React, do not. That's the main reason to use true state management tools over context. If you have a relatively small application or you don't care about that, continue using context. The article is also by a Redux core main…

> Context updates all components.

All the components that consume it. Not the whole tree under the provider.

Re: React Labs: What We've Been Working On – February 2024

#129

Post by satvikpendem »

omeid2 wrote: post #128
satvikpendem wrote: post #124

Earlier quoted context omitted.

The main point is here: https://blog.isquaredsoftware.com/2021/01/context-redux-diff... Context updates all components while Redux and similar state management tools, because they live outside of React, do not. That's the main reason to use true state management tools over context. If you have a relatively small application or you don't care about that, continue using context. The article is also by a Redux core main…

> Context updates all components. All the components that consume it. Not the whole tree under the provider.

It is the whole tree, actually. That's one reason I don't use context.

Re: React Labs: What We've Been Working On – February 2024

#130

Post by omeid2 »

satvikpendem wrote: post #129
omeid2 wrote: post #128

Earlier quoted context omitted.

> Context updates all components. All the components that consume it. Not the whole tree under the provider.

It is the whole tree, actually. That's one reason I don't use context.

That is simply not true. Only via a Consumer or useContext hook do you subscribe to hooks.

It is well documented and implemented like so.

https://react.dev/reference/react/useContext > useContext is a React Hook that lets you read and *subscribe* to context from your component.

Emphasise mine.

Post reply on HN