Hacker Way: Rethinking Web App Development at Facebook

I'll try one last time: > Sorry none of this makes any sense to me. If you're not familiar with the MVC variants (MVVM, MVP, MVI, MOVE)[0][1] we should start there. Next you should read through some common mistakes of Backbone.js like applications [link] and some criticisms of MVC on HackerNews in 2012[0]. Finally if you haven't before these talks, they are the ones that sold me on React: - [link] - [link] - ▶ this video [0] [link] [1] [link]

in “React is 10 years old” · View on HN

If you have state changes within your render cycle, then you can't write pure functions anymore, you have a stateful class. And if you have a stateful class, then React can't control when you render, because it can't know when you update a variable. So the onus is on you to decide when your component needs to re-render. This is extremely easy to screw up. You will end up in scenarios where the UI does not match the underlying state, just because the two have gone out of sync. React inverts the MVC paradigm and says "no, you don't get to decide when to render." So if you want to update state, React will manage that for you and queue up the render. With React, your UI and state literally cannot go out of sync (except for refs), and all the data dependencies are managed for you. Facebook gave a great talk on Flux architecture vs MVC ten years ago that you should check out here: ▶ this video > what's the point of the setXXX() functions? Why not just make them constant explicitly Look at the code again: it is explicitly constant! `const [myState, setMyState] = useState(0)`. `myState` is a const, and will literally not change its value for the entire render cycle. There is no mutable state to manage, no race conditions. You just tell React what to render based on what the value is now, and React injects the current value for you. The first time, `myState` is 0 since that's the initial value. Every subsequent render, React will give you the latest value. You can pretend everything is con

in “React 19” · View on HN

Exactly, this is the same as saying Redux has two methodologies, the "setter system" and the "event system"; since it wasn't that well documented initially doesn't mean that the setter way was ever recommended (it's not). In fact if you watched the Flux youtube talk, something highly recommended to learn the philosophy behind Redux, it was pretty clear. Edit: here's the video (from 10:20) ▶ this video

in “React is 10 years old” · View on HN

Redux is an implementation of Flux. I don't use Redux, but the original Facebook engineering announcement videos helped me understand React and Flux tremendously: ▶ this video If you're talking about Redux specifically -- I agree with you. I think it's ugly and confusing.

in “How to optimize React applications that use Redux” · View on HN

Video seems to start discussion of Flux just after the 10 minute mark. Direct Link: ▶ this video EDIT: So far, the video is much more helpful to me in terms of bringing the concepts of Flux to life. Jing does a terrific job explaining in my opinion.

in “Flux Application Architecture” · View on HN

> React is a child of the Flux architecture philosophy FWIW, this isn't actually the case. React was first announced in 2013: - [link] The "Flux Architecture" was first announced a year later, in 2014: - ▶ this video React's original influences were things like Facebook's internal PHP-based UI definition layers: [link]

in “UIs are not pure functions of the model (2018)” · View on HN