HN Theater @HNTheaterMonth

> React is a child of the Flux architecture philosophy

FWIW, this isn't actually the case.

React was first announced in 2013:

- https://en.wikipedia.org/wiki/React_(JavaScript_library)

The "Flux Architecture" was first announced a year later, in 2014:

- https://youtu.be/nYkdrAPrdcw

React's original influences were things like Facebook's internal PHP-based UI definition layers:

https://reactjs.org/blog/2016/09/28/our-first-50000-stars.ht...

That would definitely explain why facebook.com still has had the exact same unread messages counter bug from 2014 that they used as a case-study for the React/Flux announcement video[1]. They just don't care.

[1]: https://www.youtube.com/watch?v=nYkdrAPrdcw&t=887s

https://m.youtube.com/watch?v=nYkdrAPrdcw#

32 minutes in.

It formalizes how data is created, accessed and modified. Instead of multiple places trying to modify some specific data ad-hoc and with possible collisions/changes, now you have a mores strict way of dealing with data.

Basically the Flux architecture. See from 10:20:

https://www.youtube.com/watch?v=nYkdrAPrdcw

⬐ aenero

I see what you're saying here, and actually agree at some level.

But there is always an alternative, IMHO. If the project has a good code structure and follow equally good coding standards and review process, using simple un-opinionated/flexible libraries would not be a liability with "scale" (in terms of team/project size).

And there's one advantage of simpler approaches for growing teams: faster/easier onboarding. Let's face it, even good React/Redux developers can understand simpler code faster.

Just an alternative thought. But I completely get your point.

⬐ runawaybottle

Ok, so what are the actions/reducers nonsense about?

I’m just not seeing the argument here, and I’ve been on multiple redux applications on teams of various sizes. We always seem to create layers of indirection to do the simplest possible state update.

We adopted Dan Abramov’s mental model, and my god, it was a labyrinth.

⬐ acemarke

You might want to read my "Tao of Redux" posts and Dan's "You Might Not Need Redux" post, which explain why Redux was designed the way it is:

- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

- https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

Ultimately, it's about putting a deliberate separation between "what happened" in the UI and "how the state is updated", writing as much of your state update logic as pure functions, and being able to use that indirection to enable tracing state updates over time via the DevTools.

Also note that our official Redux Toolkit package is now the standard recommended way to write Redux logic, and it simplifies most of the Redux code you'll write:

https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

⬐ runawaybottle

I think you guys should take a more honest retrospective on an age old topic of ‘Intent versus Impact”.

The truth of the story was that community was desperately looking for a solution to global state to avoid prop drilling. No amount of technical virtuosity, or cop outs to a half assed flux architecture that fundamentally mimics model-view-controller or a pub/sub pattern will be satisfiable to anyone with critical thinking ability.

The kids had one job, get some global state available to the app, and they managed in their bravado to pack in ‘addons’, or in sales terms, they ‘up-sold’, that $40 hdmi cable along with your new $1600 television.

Dan packaged his extra bullshit (the reducer pattern) over to a desperate group that had nowhere else to turn for a global state solution. Celebrity and hero worship was one of the premier sins in all of this. The guy didn’t know what the fuck he was doing and no one called him out on it.

Certainly we are not going to marvel at the fact that he is a React core developer. Bad ideas are bad ideas, regardless of the current class that ordains it.

For this, I am depressed, and will continuously antagonize the Redux team for the damage they caused the entire community.

The Redux team owes a debt. Rewrite your library so that the api is 5 lines at max. Replace your conceptions, seek forgiveness for the sin, and let it rest. Until then, don’t peddle your Frankestein ever again anywhere, you all had plenty of time in the limelight and quite frankly - you weren’t good enough.

Like what is the redux-toolkit? Do you guys lack the conviction to decide what the api is or isn’t?

With all that said, if you don’t understand what I’m saying, then mapDispatchToProps or mapsTateToFuckYou, connect everything to nonsense, and I suppose in your new bullshit, createSlice to shut up already. You guys can’t write an api if your life depends on it. And I swear to god, if I hear about the stupid Ducks pattern ... I just can’t anymore.

Anyways, I’d prefer never to punch down if I can avoid it. The redux/abramov/constituents of the react community became the Zeitgeist of the Javacript community. Paragons. And no one stood up to them and behind the bullshit is a clusterfuck of shitty apps. You guys ain’t a small agenda, and I expect the fight to continue.

⬐ acemarke

I'm genuinely sorry that you're angry enough to rant like this. You might want to look into some therapy or something - that kind of anger can't be healthy.

In the meantime, we're going to keep working to support our users. Who, based on the vast amount of feedback we've gotten over the last couple years, _are_ happy with the directions we're going.

⬐ runawaybottle

If that’s the closest thing I’ll get to a sorry for Redux existing, I’ll take it.

⬐ runawaybottle

Just rewrite the library. Take out actions and reducers. I like the useState hook, use a proxy object to look at function name and auto generate ‘actions’ if you must. Build in Reselect, Thunks, and Immer (don’t let this become something people have to tack on), hide these implementations from sight. Forget that the original creators of the library every existed. Commit yourselves to celibacy by not creating anymore new ideas (createSlice) and use regular words found in the dictionary (preferable words programmers use, like ‘function’ and avoid stuff like ‘rootReducer’ and ‘dispatch’).

Just do the right thing.

I don't think it's intentional. Facebook has had this bug for several years. Interestingly one of the reasons they created react/flux was to fix it: https://youtu.be/nYkdrAPrdcw (15 minute mark)

⬐ jazzyjackson

Well the notification icons still don't retain state no matter what device I'm on, as in, I can check my notifications, determine that nothing exciting happened, and open the app 10 minutes later and have a red icon for the same notifications.

Sometimes I wonder what 1,000 programmers do all day

⬐ fourthark

We had our most annoying chat bug happen over and over. Users would get an unseen count and there would be no unseen messages behind it. And everyone's sort of used to seeing one of these numbers, click on it, you get something new behind it. That's exciting. But when they get that number, they click and there's nothing there, or they refresh the page and it's gone, that's really annoying. That's really frustrating... And it wasn't like we wouldn't fix the problem. We would always fix some particular edge case. But this problem would keep coming back just because the whole system was fragile.

2014. And still not fixed. Either flux/react does not automatically fix the problem, or the fix never made it to the app. Or dark patterns.

You're right, it was Flux. I'll have to dig around for it. Edit: https://www.youtube.com/watch?v=nYkdrAPrdcw

⬐ elliotec

Thanks for the follow up!

⬐ minism

Oh wow, I remember watching that, it's crazy to revisit that talk after so many years.

Redux and Flow are somehow branded as alternatives to MVC, when they are precisely MVC (store=model, dispatcher/reducer=controller, etc). It seems that Facebook (and many others) implemented MVC very poorly and pretended to abandon it instead of admitting they just did it better on the next attempt.

If anything, the success of redux simply reinforces the fact that MVC is a very useful pattern for UI applications. But, it bothers me that newer developers might be persuaded by the anti-MVC branding.

⬐ mpweiher

So glad I am not the only one!

What I found interesting was that the original developer(s) of react.js seems a lot more up-front about this:

https://omny.fm/shows/future-of-coding/1-1-how-reactjs-was-c...

Of course, the whole idea of, in-theory, re-creating the UI at every refresh cycle is not part of MVC, so that is new and interesting. Considering all the work that has to be done to undo that abstraction (as it doesn't really match reality), I am not sure how useful it actually is.

https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

⬐ underwater

Flux dispatcher are not really like controllers. They don't allow for any business logic. The stores are like combined controller/models, though.

A key design feature of Flux is that many unrelated (or related) stores can respond an event, and that there is a defined lifecycle for handling events. I don't believe those really map to MVC.

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: https://www.youtube.com/watch?v=nYkdrAPrdcw

If you're talking about Redux specifically -- I agree with you. I think it's ugly and confusing.

⬐ moretti

Redux is not an implementation of Flux. These two blog posts explain the main differences: https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab2... https://code-cartoons.com/a-cartoon-intro-to-redux-3afb77550...

⬐ danesparza

I stand corrected. Thanks for these posts!

⬐ acemarke

Redux absolutely _is_ an implementation of the Flux Architecture. I've described it as "Flux taken to its logical conclusion". If you read my post "The Tao of Redux, Part 1 - Implementation and Intent" [0], I quote several comments and pieces of early documentation that back up Redux's Flux heritage. Redux inherited the idea of plain action objects with a `type` field, action creators, and the concept of "dispatching"

[0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

I wonder if the criticism that the Flux team at Facebook has directed at two-way data binding is also applicable to Meteor. Jing Chen is her intro of Flux (https://www.youtube.com/watch?v=nYkdrAPrdcw&list=PLb0IAmt7-G...) says that two-way data binding creates a major challenge for scaling applications because views can trigger changes in data, and data changes can trigger cascading changes in views, which makes it very difficult to predict the behavior of the app as a whole. Wouldn't Meteor face the same challenges?

In other words, if you believe that the Flux design pattern (which involves a central dispatcher as the only entity capable of updating the data) is sound, shouldn't you stay away from Meteor's model when building large applications? Or am I missing something?

⬐ kfinley

I don't believe Meteor has two-way data binding. You have to update the model manually using events[0].

0: https://docs.meteor.com/#/full/eventmaps

⬐ imslavko

Two way data-bindings are not a Core feature and they are implemented in packages. My favorite one is this: http://viewmodel.meteor.com/

⬐ dmak

That's an interesting point. I find two-way binding to be very convenient, but I wonder if the industry is moving towards a one-way bind solution (at least it seems like a common theme with most front-end frameworks).

⬐ jlu

You are not.

⬐ liscovich

This is quite surprising to me. I know that Pete Hunt -- one of the authors of ReactJS -- and one of the main proponents of using it in conjunction with Flux, gave a talk at Meteor Devshop 11 earlier this year (http://youtu.be/Lqcs6hPOcFw?t=48m7s), and didn't say a word about the problems associated with two-way data binding. To me that would seem to be the elephant in the room. Is that because he treats Meteor as a framework for prototyping and smaller scale apps?

⬐ sbking

Meteor doesn't use two-way data binding. You have template instances, which are wrapped domranges based on handlebars templates that call helper functions (one way binding). You then have event handlers for templates that you assign to class selectors, which will be delegated to each template instance that is created. You then manually change the data within event handlers.

Video seems to start discussion of Flux just after the 10 minute mark.

Direct Link: http://youtu.be/nYkdrAPrdcw?t=10m21s

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.

⬐ jamesgpearce

Yeah, we should have embedded it to skip me, for sure :)

⬐ shaohua

Jing did an amazing job explaining Flux. She should do a lot of more of those talks.