Rename experimental useEvent to useEffectEvent

[sebmarkbage]

We originally had grand plans for using this Event concept for more but now it's only meant to be used in combination with effects.

It's an Event in the FRP terms, that is triggered from an Effect. Technically it can also be from another function that itself is triggered from an existing side-effect but that's kind of an advanced case.

The canonical case is an effect that triggers an event:

const onHappened = useEffectEvent(() => ...);
useEffect(() => {
  onHappened();
}, []);

[acdlite]

I'll let others weigh in but this name works for me

[poteto]

No notes about the name, I think it makes sense to me.

It's just internal but just for consistency it might be worth grepping for UseEvent as well (eg enableUseEventHook wasn't renamed) since it looks like there's still a few leftovers that were missed in the rename.

[gaearon]

but now it's only meant to be used in combination with effects.

Should it be legit to call it from an event handler?

Edit: I guess you mean yes:

Technically it can also be from another function that itself is triggered from an existing side-effect but that's kind of an advanced case.

[sizebot]

Comparing: 4dda96a...2d97961

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	=	154.58 kB	154.58 kB	=	49.01 kB	49.01 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	+0.02%	156.51 kB	156.53 kB	=	49.65 kB	49.65 kB
facebook-www/ReactDOM-prod.classic.js	=	533.71 kB	533.75 kB	=	95.04 kB	95.04 kB
facebook-www/ReactDOM-prod.modern.js	=	518.81 kB	518.85 kB	=	92.85 kB	92.85 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against 2d97961

[HansBrende]

@sebmarkbage the RFC's "basic example" is:

function Chat() {
  const [text, setText] = useState('');

  const onClick = useEvent(() => {
    sendMessage(text);
  });

  return <SendButton onClick={onClick} />;
}

Are you saying this won't work anymore because onClick is not called in a useEffect? Or is there something I'm not understanding about the terminology "kind of an advanced case" since this is supposed to be the basic example?

[sebmarkbage]

That RFC is defunct. This is different.

[HansBrende]

@sebmarkbage to clarify: so we will still need to use use-event-callback for the above use-case I mentioned? useEffectEvent won't cover it?

[gaearon]

The scope of the new RFC will be specifically aimed at solving the Effects case. If you find use-event-callback helpful for other reasons you can keep using it for those. We wanted to decouple the Effects problem (which is very clear) from the rendering optimizations (to which there are many possible solutions, and where there isn't a clear winner yet). We will be exploring rendering optimizations separately.

[HansBrende]

@gaearon follow-up question then: I'm trying to write a userland hook that would as closely as possible approximate the original (stable) semantics since they are extremely useful for a lot of projects I'm doing. Do you think this would work (specifically: assigning in render pre-React 18)?

const throwingShim = () => {throw new Error()}

// if concurrent mode is not supported, assign state to ref in render to avoid
// "the pitfall present in the userland versions where one component's effect 
// can observe the previous version of another component's state."
const useCopyStateToRefEffect = React.startTransition !== undefined ? useLayoutEffect : fn => fn();

export const useEvent = 

  // as defined by https://github.com/facebook/react/blob/main/packages/shared/ExecutionEnvironment.js
  !canUseDOM ? 
  
  // "when server rendering, useEvent will return the same throwing shim for all calls"
  () => throwingShim : 
  
  // client implementation
  (fn) => {
    const ref = useRef([fn, (...args) => ref[0](...args)]).current;
    useCopyStateToRefEffect(() => {
        ref[0] = fn;
    });
    return ref[1];
  }

[gaearon]

I would not recommend such drastic behavior differences. An 18-only shim relying on useInsertionEffect seems reasonable to me.

[HansBrende]

@gaearon thanks for the tip! Something like this? Tweaking the above as follows:

const useCopyStateToRefEffect = React.startTransition !== undefined ? useInsertionEffect : fn => fn();

Note: I can't make it 18-only since I'm working on a library that supports either 17 or 18 as a peer dependency. Do you see any pitfalls with the above approach? It certainly feels like a hack, but I'm scratching my head as to what could possibly break (can't think of anything myself).

[gaearon]

If you're using 17 and 18 I'd say just do it in in a layout effect.

[HansBrende]

@gaearon that's certainly a possibility, but was hoping to avoid "the pitfall present in the userland versions where one component's effect can observe the previous version of another component's state" to the greatest extent possible.

So I'm curious: what other pitfalls do you envision with the approach listed above (using useInsertionEffect with concurrent mode, no effect otherwise)? There must be some reason you are not recommending this approach?

[HansBrende]

@gaearon as an aside: if React itself were to expose some manner of this useCopyStateToRefEffect (either accepting an arbitrary function, or simply a ref and a state), that would be an extremely powerful building block that would make these types of userland hooks actually possible. It would be useful, not just building useEvent hooks, but also, for example, updating Context values that are not supposed to trigger a re-render (e.g. if only used in callbacks). Has this been discussed (and if so, where?) Should I create an issue to propose this?

[karlhorky]

@sebmarkbage are there any ideas of a targeted stable version of react for this new useEffectEvent to be included in?

I assume it's not far enough along to be included in react@18.3.0, but maybe something around 18.5.0? Or is this going to require a breaking change and only become available in 19.0.0 or 20.0.0?

[gaearon]

Hi @karlhorky, we don't schedule features for concrete minor numbers in the future. We hope to get this out in one of the future minors (maybe the next one) but if we need to release something else in between, it might end up being a different minor. I don't think we currently plan to release a major in between.

[michaelphines-stripe]

This meshes with my intuition that often the underlying issue with useCallback deps is actually an issue with deps within useEffect of the component the callback is passed as a prop to. However, I think if useEffectEvent is constrained to usages within useEffect, the implementation can be much simpler than the previous useEvent.

The reason is that useEffect already has the up-to-date closure semantics of useReducer referenced in the original 2018 issue that useEvent was trying to replicate. The implementation details of useEvent were specific to the useCallback use case, which was special because React is not in control of when the callback is run. When constrained to usage within effects of the same components, the extra details are unnecessary.

These two rules together are what simplify things for us:

• Only call Effect Events from inside Effects.
• Don’t pass Effect Events to other components or Hooks.

It seems to me that if you follow all the rules of useEffectEvent, what you are doing is tantamount to just ignoring a dep. In fact, useEffectEvent needs no implementation at all! All useEffectEvent needs to do is return its argument and exist as a hint to the linter to ignore the missing dep. It may also have its own linter rules. However, if it's ever anything more than that, it's just providing unnecessary functionality that is only useful when misused.