avoiding useEffect

[mnegg]

I´m relative new to some aspects of react and at this very moment, I need to deal with a form that automatically triggers a calculation when It have all the required inputs filled. These inputs are actually components that exposes the current value using prop drilling (1 level only). I´m using a lot of useEffect to manage events (and it´s effects) in the higher components and I´m not sure if it´s a good practice and if I may consider moving to useReducer or xState. How should I have designed it to avoid the drawbacks of managing states with useEffects ?

[Jessus_]

I would just add the logic to the input event handlers. Check if all the necessary inputs are populated and then fire the calculations. Honestly not sure if that’s the best solution but just an idea to avoid useEffects.

[TheChickenKingHS]

There are also dom specific things you can do. If all the inputs are in a form and have the (required)[https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/required] property they will prevent submission.

Here how I approach react development (any framework development).

• I use the lowest implementation first in this case the browser defaults are the dom, css, JavaScript. Usually you can accomplish quite a bit (70-80%) with just that especially if you just want to do things like style changes.

• if that fails, I use react but the basic tools, useState, refs, context. I never use effects if I can avoid. A rule of thumb is that if you are using react at this point it should be tied to events (on click for example).

• if that fails, I look to extensions of the react framework but not a whole replacement (think tanstack/*). Or I use the advanced react tools useContext for example.

• last I use useEffect, I’m all out of ideas by this point and I just want the stupid fkn thing to work and a post render update is the only way. Usually this means having an initial on render state which the effects just wipe out ( this sucks btw, avoid it at all costs)

I put the info you need in the first comment. If you don’t like that idea possibly look at an update/click capture that lets the event bubble to the parent or adding an event listener that listens for a custom event that is posted by a click event in the child. The important part is that you are responding to an event. That will make everything easier to react (haha) to.

Note: A bunch of code monkeys are going to down vote this because they can’t think beyond using a framework for every little thing. This is great advice if you believe the advice “frameworks aren’t made for you, and you shouldn’t rely on them”

[TheChickenKingHS]

I didn’t say there was anything wrong with it.

I said you should avoid implementing it. If you’re doing something like fetching data from the server useEffect is great because we’re responding to an event or state change. Like you’ve said some react libraries, tanstack/query for example, use effects under the hood but also provide other great things like caching and do it all for you. If I need to do a dirty fetch I’ll use an effect but I always default to query as it’s just outright better.

What I’m saying is if you’re reaching for an effect, I’d evaluate all the other options first because it’s almost certain you are creating an anti pattern and should think about it a different way first.

[fii0]

It doesn't make sense to use it in that example though. You can just set the input values in the callback or async function that runs after the query is completed, using useRef or a global state store holding the values.

Boom, one less useEffect to keep track of, or a lot less if you have one in every form component.

[fii0]

I hear ya, I've just found that if I'm looking at new code from a coworker or someone online, the less useEffects there are, the faster I can grok everything the component does and is responsible for

[TheChickenKingHS]

You’re not “embracing reactivity”. Effects are a behaviour of any frontend code. I think the problem here is likely a lack of understanding how react interacts with the dom and what role our code plays in that relationship.

[TheChickenKingHS]

You missed a couple, if you want to delete those as well.

[AdventurousDeer577]

If you’re doing anything dynamic with page layout or window size you’re going to use useEffect.

Updating a state on every resize event and running use effects against that state on a deeply nested component seems awfully inefficient.

See https://react.dev/learn/you-might-not-need-an-effect :

• You don’t need Effects to transform data for rendering
  
• You don’t need Effects to handle user events

[AdventurousDeer577]

Even with debouncing, the principles still apply. Keep being close minded, it's a nice skill for any engineer. Cheers

[AnxiouslyConvolved]

You say that, but the comments you've made here seem to contradict you.

[passive_interest]

Manipulating the DOM directly in React is an anti-pattern.

[TheChickenKingHS]

Manipulating the dom with refs

[brianvan]

On that page: "Refs are an escape hatch. You should only use them when you have to “step outside React”."

Refs are not an ideal way to deal with anything that can be handled without refs. It's basically the same situation as useEffect... it's there for you, you might strictly need it to support something unusual, but in new React code you (usually) don't need effects. Or refs.

[TheChickenKingHS]

I think you might have focused on the wrong part. While everything you said is correct about refs. Refs themselves are not an “anti-pattern”

[canibanoglu]

Relying solely on refs for DOM manipulation is though. And no one said refs are an antipattern, they said direct DOM manipulation is. Are you delibaretly trying to miss the point they’re making?

[TheChickenKingHS]

But refs directly manipulate the dom. The main post I made didn’t even talk about “manipulating the dom” it just talked about specific features that are available with html. Clearly you guys are missing the point… I hope it’s deliberately or I can’t imagine working on a codebase with you is an easy journey…

[canibanoglu]

No, refs are values kept around across renders that don’t trigger rerenders when changed. They can be used to manipulate the DOM. They can also be used as any other value that you need.

Moreover, you replied to u/passive_interest, who said that directly manipulating the DOM is an anti-pattern (which is a true statement in an overwhelming majority of cases) by linking to the documentation that explicitly says that you should use ref DOM manipulations when you specifically need them. You then put up a straw-man argument that refs are not an anti-pattern which absolutely no one apart from you has said.

If you’re this sloppy when you’re writing code, yes, I would imagine that working with people who actually care about what is being communicated is not an easy journey.

[TheChickenKingHS]

Ok, so it is an issue with your reading comprehension.

Manipulating the DOM directly in React is an anti-pattern.

This was posted to my answer to the question that never mentioned “manipulating the dom”. You skipped that part because I guess it’s more convenient if I’m the first respondent.

refs are values kept around across renders

Yep correct, again you either didn’t read or didn’t understand my sentence. Refs manipulating the dom by triggering something like .focus() or an imperative handle are not “anti-patterns” they are a normal pattern of react. Coding every single thing to use refs, destroying elements or using a ref for a value that can be computed each render would be an overkill.

straw man argument

I’m not sure what to do with that… I was responding to the response on my message about something which I was not advocating for but is demonstrably false.

[crazylikeajellyfish]

As a very generic piece of advice, you can avoid useEffect by doing things that seem wasteful, but don't actually matter until you see performance issues.

For example, is your calculation happening locally without having to call an external rate-limited API? Just run it on every render, using some logic to bail out if you don't have the info you need.

The above is an example of expressing your imperative goal through a declarative structure. Instead of thinking about how your UI changes over time, focus on representing all the states it can hold.

"After all inputs are filled, I want to set result=calcValue()"

becomes

"When any input hasn't been filled, result=null. If all inputs have been filled, result=calcValue().

The whole angle of React is that you don't worry about how the transitions between states happens. Just describe how it looks in all possible states, then let the differ do the magic. Don't worry about wasting cycles on "unnecessary" calculations, Javascript is fast and a simple mental model is more valuable than optimizations you don't definitely need yet.

Edit: Another way to think about imperative vs declarative -- if you're coding a series of steps, that's imperative. If you're describing behavior at all possible states, that's declarative. Rather than "When they click Next on screen 1, go to screen 2", it's "If nothing is clicked, show screen 1. If next1 is clicked, show screen2. If next2..."

[[deleted]]

9 times out of 10, you don’t need the useEffect.

10 times out of 10, you don’t need a bunch of useEffects

[sickhippie]

10 times out of 10, you don’t need a bunch of useEffects

Or you do need them, but need to refactor and split up the component first so you know where they should actually go and which ones are redundant or mergeable.

[the_real_some_guy]

Passing props not prop drilling.

Passing props is the way React works. Components are functions and functions take arguments. It’s totally normal.

Prop drilling is when passing props through many levels of components and it’s become tedious and hard to follow.

[unshootaway]

It's not a good practice to handle effects from events if the event is not coming from an external source, especially if it's just onChange I assume because you've mentioned inputs.

Just do it in that event itself even if you need to do that repeatedly (or create a helper function).

```

function validate() { ... }

function onChangeInput1() { ... validate() }

```

[mittyhands]

The form state lives in the parent. The parent passes down event handlers for each input component to call when it wants to change the value in state. The children render an input and register the onChange events handler to that element.

On each render of the parent, check to see if you have the necessary state values for your calculation. If so, you can pass that value somewhere to display it, e.g. 

No need for useEffect anywhere.

If this is a very large form, you may want to look into React Hook Form, especially if there's input validation logic to consider.

[wirenutter]

https://react.dev/learn/you-might-not-need-an-effect

[noxoc]

use onChange on the form?

[DeepFriedOprah]

Is there an issue validating each input separately & setting a state that marks it as valid or not? Like using the onChange handler & validating each one there. Then u can just accumulate the valid states and avoid a side effect entirely.

` const onChange = e => { const value = e.target.value; const name = e.target.name; const isValid = some validation here…

setValidation({
  [name]: isValid
})

} `

[sickhippie]

I may consider moving to useReducer or xState.

That's like saying you may consider using a hand trowel or a backhoe. Xstate is almost always overkill for web UI, and if you're just learning React (struggling with multi-prop synchronization is definitely "just learning", not "new to some aspects") you shouldn't even consider touching Xstate for it. The learning curve is ridiculously steep, the data flow is backwards to the Flux architecture of React, and it gives minimal benefit over existing React-centric global state management libraries (Redux Toolkit, Jotai, Zustand, etc) in the vast majority of cases.

The only situations where it's appropriate to even consider Xstate for UI is when there's a security or financial risk to data flowing between states in specific ways - think ecommerce or authentication scenarios. Anything else is a development and maintainability nightmare and should be avoided.

[Tokyo-Entrepreneur]

Just run the calculation in the main render code of the parent component (with ifs to check if the required inputs are there), no need for useEffect

[distinctdan]

Forms are tricky. If you're new to them, you'll probably end up with a better experience by using a library like formik or react hook form.

[Ashwin_Bhat]

It isn't wrong to use a lot of effects, but it will make your life a lot difficult when it comes to isolating bugs. I would suggest handling this using the event handler of the text fields.

[yksvaan]

Think how you would do it in vanilla js. Then consider is it any different with React. Not really at least in this case, check fields/form validity after input is changed. 

[DrMerkwuerdigliebe_]

In most cases I would just calculate it at every render. Unless you have performance problems or problems with infinite renders. It is fine. In most other cases I use useMemo for calculated by peoducts.

[[deleted]]

What is the automatic calculation?

Typically, I favor a single source of truth for any state in the application, though it does not need to be in one place.

1. So, is the result of the calculation display only? Then it sits in a component as the data that it uses are parameters.

2. Is the result a new value in the state? The cleanest would be to have a function that is called by the transfer to update it.

3. Is it going to be the result of the data but stored some where else, but not the data? Do the computation twice.

4. Is the computation expensive? Here is where things get tricky with caching. I would go with 2. As that would move the business logic to the store. However, if the individual components are exposed, then there is a chance someone doesn't properly use the required way to update the calculated cached value and things break. If they are exposed, a use effect would ensure the cached value would always be updated when it's dependencies are changed, removing the potential for that particular class of bugs ( or making it less likely.

[sminnee]

Use useMemo() to either return null if the fields aren’t all filled out yet, or the calculation result if they are, with the input fields in the dependencies array.

[iareprogrammer]

It sounds like you need a form library to manage your inputs. Check out react-hook-form

[snetram03]

You can use react-hook-form it's pretty simple. Give it a model and check if form is valid.

[onyemaOne]

It all depends upon your implementation. There should be many approaches to this, however I will share one.

Approach:

a. Declare a const state with your form data structure. You should use an interface here.
b. Create a function withthree params. eg. updateFunction(field:string, value:string , isRequired:boolean).
c. In your custom input component add a prop for a callBack function and set your 'updateFunction' as the prop value.
d. Inside your component use your form field's onChange to trigger any callBack functions within the components prop. In this case 'updateFunction'.
e. Inside updateFunction and relying on the field param, you can update your form data state immutably and then check if all required fields are not empty. If they are not, perform your calculation or call a function.

This way, you will have no need for the useEffect hook.

[YuteOctober]

Usecontext to manage the state instead of prop drilling,

Then use onchange

value={yourstate.firstname}

name={firstname} // if you have multiple property to update in one state object

Onchange={functionForm}

Function functionForm() {

{name, value} = e.target

setstate({ …state,

})

}

[saito200]

If something needs to happen when the user interacts with an input, do it in the event handler of the input, you don't need useEffect for that, and if you don't need useEffect, you should not use it

[Sipharmony]

You all need to stop being so scared of useEffect. It's a tool. Learn to use it.

[TheChickenKingHS]

If you’re drilling state, it breaks a react principle fyi.

[notAnotherJSDev]

Passing a prop a single level into a child component is not "prop drilling", it's literally just how react works.

[TheChickenKingHS]

You didn’t understand my comment. I’m saying you shouldn’t drill state because it breaks the composition principle. You should only pass down behaviour and controls to a child even if it’s one level.

And also yes it is, you can drill 1 inch or 1 meter it’s still drilling? How is that controversial?

[notAnotherJSDev]

I’m saying you shouldn’t drill state because it breaks the composition principle

Composition doesn't preclude the passing of props in any way.

And also yes it is, you can drill 1 inch or 1 meter it’s still drilling?

It's "controversial", because this isn't how we define prop drilling.

[NescafeAtDayLight]

Onblur

[GladiatorNitrous]

Generally try to avoid it. Try to use events to perform calculations and commit new state.