[jkaplan]

There are for sure lots of bad ways to use React, and lots of bad React developers. I actually had a very poor experience with React my first project using it.

But that's true for any framework (or lack thereof.) It's definitely possible to find good React patterns too. My 2nd project with React was a great experience, and was infinitely more maintainable and reusable than the framework-free frontends I had worked on.

Sounds like you've worked in really bad React projects (and/or really good non-React projects). All I can say is that my experience has been different! Redux + Redux Toolkit (https://redux-toolkit.js.org/) helped me and my team establish React patterns that were organized, concise enough, and performant -- although we did still have to tinker and try some things out until we found the patterns that worked for us. Hope it helps!

[kristopolous]

Here's things that are super simple to do with Javascript but extraordinarily difficult in react:

* a function your code can access

* data your code can access

* a dom node you can access

The very core parts of basic programming have been slaughtered and perverted in some kind of repulsive overengineering porno show.

I've worked 3 months on something that should have literally taken 2 days. React is giant sack of bullshit that's made it take months.

Instead of managing say a global object there's this sheer utter insanity of redux store. Something that I could explain in 10 words now takes 9,525: https://www.valentinog.com/blog/redux/

The pythonic notion of "we're all adults here" has been replaced with "we're all completely utterly incompetent children here that need safety locks on everything". I no longer know what works.

I'm actually astounded, I'm not joking in the slightest, in any way whatsoever that

   var a = 10 + 5;

still works and I'm not forced to do something like:

    let a = [...new Array(10).fill(0), ...new Array(5).fill(0)].length;

as a workaround.

I am quite literally shocked by this. Just thinking that this is still possible made me actually shout in happiness at my desk. I really just did that.

I wish I was being sarcastic. I'm not. React breaks programming that much. At that fundamental of a level. It's that profoundly bad.

Coding in react is like if you wanted to get out of bed and take a shower but then find out your town has been carpet bombed and you're sitting underneath piles of collapsed concrete. So first you need to survive the day, get rescued, clear out the rubble, then rebuild everything, then you can go take the shower. Shit's so much easier this way!!!

No.

No it fucking is not.

Just no.

This vile framework is the most vulgar code in an already repugnant front-end javascript ecosystem. It's utterly shameful.

[rw3iss]

Amen! Have been waiting for a react replacement for ages. Hate using it for all these same reasons. Use preact, but mostly same issues.

The fact that they change the seemingly every few months, and have the entire framework scattered around 3-4 different libraries that are always changing is annoying enough.

Oh you want to set the class of the html element? We're gonna rename that to className cause it's easier to read and and we can.

Functional components and hooks become a ridiculous mess too, in any more than basic scenario.

[kristopolous]

Here's another example. Say in javascript I want to navigate to a page 'login', here's a way to do it.

    window.location = 'login';

And there I go!

In react, well it really depends on what version. If I'm doing pre-hook (pre 16.18 or so) classes, first I need to make sure my constructor brings in props that I call a super on.

Huh?

No no stay with me. Then I have a this.props.history object and I push a new entry on to the stack like so

this.props.history.push('login');

Remember to make sure you use the fat-arrow to pass the this reference downward and that you export your class using withRouter. Effectively here's the replacement code:

    import React from 'react';
    import {withRouter} from 'react-router';
    Class A extends React.Component {
      constructor(props) {
       super(props);  
      }  

      fn() {
       this.props.history.push('login');
      }
    }

    export default withRouter(A);

And even then you may still have to "debug" this because it may "break" for inexplicable reasons. Because "In order to make use of history in the App component use it with withRouter. You need to make use of withRouter only when your component is not receiving the Router props,

This may happen in cases when your component is a nested child of a component rendered by the Router or you haven't passed the Router props to it or when the component is not linked to the Router at all and is rendered as a separate component from the Routes."

Again, we are replacing:

    window.location = 'login';

That is our only goal here

How is this easier then the first one? It isn't.

What problem has been solved? None.

Does it take less time? No.

Is this less typing? Less code? No.

Less complexity? No.

Are difficult things less difficult? No.

Fragile things more robust? No.

No none of this. It runs away from more reusable, self-contained, portable code as fast as possible. It gets in a rocket car and fires up the engines to go Mach 1 in the wrong direction. It's a giant tangled spaghetti dish of the worst anti-patterns in software engineering as a requirement for it to work.

[kristopolous]

For future readers, a flagged dead sibling comment said this

> Poor child. Wait until you have to build a sufficiently complex web app. Global variables are never the answer

"never the answer" is a Fundamentalist Orthodoxy.

Look at those words, "fundamentalist" and "orthodoxy".

When they are the answer and are needed then instead of a basic global thing some bizarre fundamentalist mind palaces get built. There's say "a singleton object that expose shared properties through a getter/setter pattern" or some other word salad to avoid using the word "global" and avoid making the code look like a global.

So weird rules get piled on, maybe some ornate calling convention.

These people dress up a global and disguise it in a sufficiently large enough costume so their fundamentalism doesn't get offended.

It's simply blind dogmatism and utterly indistinguishable from any other cult-driven purity test.

The ceremony is a necessary delusion so they can maintain some imaginary tribal membership to some fiction of "senior developer" they have constructed out of bad advice and empty platitudes by other misdirected self-assessed experts.

It's like the anti-climate-change or anti-vaccine people who think they are smarter than everyone; ignorance breeds a confidence that only progresses the pursuit of greater ignorance. Like astrology, these imagined worlds are far richer and more complicated because they have to construct something that follows arbitrary rules and disagrees at a fundamental level with basic realities to prop up mythical narratives holding their tribes together.

What a way to build things.

[acemarke]

Glad to hear that RTK is working well for you!

Out of curiosity, what sort of "tinkering" did you find yourself doing, and what sort of patterns did you end up with?

[jkaplan]

High-level, we wanted to minimize the need to "jump around" to multiple files or multiple places in a file to make a single change to an action (and also just minimizing the amount of boilerplate generally).

If I'm remembering, createSlice() got us most of the way, but async actions still needed an extra declaration (and maybe types? we were using TypeScript), which couldn't be placed next to the createSlice reducers, since they're in-lined. I can't remember if we ended up popping the reducers out into their own functions so they could be next to the createAsyncThunk call, or if that created too much of a typing headache and we just dealt with having async action creators declared at the top. (We also tried just using createReducer directly, but iirc the typing was just extra work compared with createSlice.)

**

Only partially-related to RTK, but the other thing we had to tinker with a bunch was performance. RTKs default use of immer helped a lot, and I believe we also ended up using createSelector (or perhaps the Reselect API directly) in a few places. We also had to learn to make extensive use React.memo and React.PureComponent. Redux dev tools were incredibly helpful for figuring all of this out.

*

Anyway, hope that's useful/interesting! RTK made a big impact in my day-to-day React/Redux development, from "ugh so much boilerplate I feel stuck" to "I can make changes reasonably quickly." Hope to see it continue to improve!

[acemarke]

You should be able to write thunks in the same file as `createSlice`, usually in front of the `createSlice` call, and then use the `extraReducers` "builder callback" syntax inside the slice to handle the various actions dispatched by the thunk. See the example here:

- https://redux-toolkit.js.org/usage/usage-with-typescript#typ...

And yeah, `createSelector` _is_ the Reselect API, just re-exported.

You might want to also take a look at our upcoming "RTK Query" API that will be in Redux Toolkit 1.6, which should be out in the next couple days. It's a data fetching and caching layer built specifically for Redux usage. The preview docs are here:

- https://deploy-preview-1016--redux-starter-kit-docs.netlify....

[jkaplan]

Ah yes. We did end up using extraReducers, but didn’t love that the thunks and their corresponding reducers had to live in separate parts of the file. (For me at least, mentally simpler to have an action and it’s reducer close together.)

This looks cool, thanks for passing along! I’m actually starting a new project now, and deciding what my state management / caching layer should be, so great to know this is an option.