[AskJS] What small JavaScript pattern made your React code cleaner?

[u/chuttadi2007]

[u/LessAd8002]

I started pulling out all the API calls into a separate file with named functions and it cleaned up components so much. Before that my useEffect blocks were getting ridiculous with all the fetch logic just sitting there

Also early returns in components instead of nesting conditions everywhere, that one took me way too long to figure out

[u/Reashu → u/LessAd8002]

I'm usually a big proponent of early returns, but unfortunately they don't work so well with hooks so it takes some extra care in React.

[u/CommercialFair405 → u/Reashu]

If you use render props, you can put logic in a component, and the rendering logic in the component that would do the early return as usual.

[u/azhder → u/CommercialFair405]

That's basically hooks with memo, but provided by React by default with components being memoized based on the props. It's always a nice pattern to separate logic in HOC and presentation in the wrapped component.

[u/Reashu → u/CommercialFair405]

Separating logic (and fetching) from rendering is something I'd certainly like to see more of in React - and just putting it in a hook isn't enough because that still has the rendering component in control of everything. 

[u/NervosaX → u/LessAd8002]

I would suggest not calling them in the components at all - use something like react query!

[u/Dubstephiroth]

Notes and very rough documentation has made it easier visualise the flow of data through the project... and writing dumb components with no logic at all..

[u/sylvant_ph]

I ain't sure if my examples match precisely your description, but once in a while I feel the need and benefit of using IIFE(Immediately Invoked Function Expressions - had to google the abbreviation) and currying. The first can scope down a more complex condition a bit, and the second can allow some sort of slight dependency injection. With IIFE you can both keep the logic inline, yet have it split down into readable segments, instead of forcing it into complex ternary operators.

[u/catladywitch → u/sylvant_ph]

And then they're easy to extract (maybe wrap them into a custom hook if they touch state) if you need to reuse them. That's a good one, I'm taking note!!

[u/effnd]

I usually extract any data-handling logic from React components into separate functions, and then wrap them in hooks when needed. If you rewrite the components (perhaps even in a different framework), these parts of the code won't have to change

[u/valbaca]

TanStack, let it handle the state of data calls, errors, retries, loading state, etc.

Seriously, adding this during a React migration cut down like 60% of the hand-coded network logic our website was doing and found several issues with the old logic.

[u/Character-Blood3482]

Not the js's or react's specifically thing but I like to return { data, error } for any functions that including try-catch. So that who ever use that function can if/else on the error to process futher more.

[u/catladywitch → u/Character-Blood3482]

as functional as js and react have become over the years, I really wish it was easy to move to Result-based apis for error management instead of the glorified call/ccs that try/catch blocks provide, but it'd require such a massive rewrite of everything i guess monadic handling of stuff beyond Promises and kinda useEffect is gonna remain a Rust/Scala/OCaml/Haskell/F# thing, plus pattern matching in JavaScript has been on the ECMAScript list for ages anyway

[u/dustofdeath]

Regardless of the framework - i would say it's the separation of business logic/API and rendering that improves messy code.

2nd would be reduction of if-if else-else spam. Reordering function structure can eliminate most of these with the use of returns.

[u/ndev42]

The biggest one for me was stopping treating components as the place where everything happens. Once I moved everything else out (API calls into their own layer, business logic into plain functions or hooks) the components basically became declarative and boring to read. Which is exactly what you want!

The other thing that sounds dumb but genuinely helped was just making more components. If you've got a conditional block rendering a chunk of UI, that's probably its own component. Smaller components means each one has less reason to be complicated in the first place.  

[u/azhder]

If you understand only S from SOLID, you can already write a lot cleaner code.

[u/Verzuchter]

Probably the most profound impact was, moving to angular because it's more popular here in Europe. I now develop frontends like I develop backends and it has made shifting so much easier.

Felt like a world has been opened to me.

[u/eindbaas]

Components are about orchestrating the ui, meaning a lot of logic and business logic does not belong in a component.

[u/lookarious]

Pull out logic from React components to anything that scales properly, for us it was MVVM (MobX)

[u/Alert-Caregiver-7421]

this tracks with my experience pretty closely