Hacker News Reader

Comment by nawgz | Hacker News Reader

I mean, that's just bad development though. You can write React with literally 0 external libraries and have a fully-fledged state management solution built-in.

The same folks who fail to understand that and just recklessly add dependencies aren't going to craft a nice static HTML site with smart, minimal, performant JS; they just don't have the chops for clean solutions. The medium barely matters.

View on HN

I disagree. Making a good site with React takes more effort than not making bad site otherwise. Also because it’s fashionable React (and similar frameworks like Angular or Vue or Ember) are used in places where they don’t belong and it stinks.

I just am saying, someone with clean HTML/CSS/JS knowledge who abuses React to the degree you're implying just sounds like a strawman to me.

Frameworks shield from footguns like unpredictable DOM modifications all over the place put one over the other.

I was there when AngularJS was still this revolutionary new framework and back then any sufficiently sophisticated form would eventually become unmaintainable.

Wait.. no. There is enough information out there that suggests that React's Context should not be considered a replacement for Redux. Just think about having multiple contexts and derived state - there would be scenarios where your view layer would be unnecessarily coupled with stateful logic or other undesired patterns.

> think about having multiple contexts and derived state - there would be scenarios where your view layer would be unnecessarily coupled

Can you expand on this?

I have created entire applications which are operating off of a single React context, and then also created some generic components which themselves expose a provider to their managed subtree. I have not faced any issues or "coupling" between these layers; I just pass props from the top-level context to the top of another subtree / component, and it works as I would expect.

I don't rely super heavily on derived state, but I find useEffect and useMemo to both be quite simple and effective when I need side effects or to memoize a piece of derived state to prevent throttling.

What situations am I missing that introduce these issues you talk about? How does Redux solve them more cleanly?

I'm just speaking from my own experience where we had an redux app with 30-40 reducers operating on quite a lot (100-200) of dynamic attributes in those objects and approximately the same amount of attributes that are initialized just once and don't change over the lifespan. I can't imagine using a single context for it all. We used thunks heavily, of course. I would prefer to look at the code to better understand how we approached problem solving in each case. Also, have you ever had to invest a good chunk of time to solve performance issues in any of those projects? We did.

Reply on news.ycombinator.com