[Feature]: ErrorBoundary onError -> onCatch (BREAKING CHANGE)

[manudeli]

Package Scope

@suspensive/react

Description

If ErrorBoundary has shouldCatch and the React Component method has componentDidCatch, isn't it better to name onError as onCatch?

Callback passed by onError prop is only called when an Error caught by shouldCatch is caught. changing prop name is a breaking change, so I'm considering whether to reflect it in v4.

Possible Solution

No response

etc.

No response

[coauthors[bot]]

People can be co-author:

Candidate	Reasons	Count	Add this as commit message
@manudeli	https://github.com/toss/suspensive/issues/1783	1	Co-authored-by: manudeli <[email protected]>
@gwansikk	https://github.com/toss/suspensive/issues/1783#issuecomment-3407094812	1	Co-authored-by: gwansikk <[email protected]>

[gwansikk]

Well, here's what I think. I agree with the onCatch proposal. I think it aligns better both in terms of naming and context with the current shouldCatch in ErrorBoundary. However, I can't think of a clear reason why we must change the name right now.

How would users perceive it if we simply change the name? They might expect a new feature or question the intention behind the change. I'm curious what exactly we are hoping to achieve. I also think there's an advantage that users of the most downloaded package, react-error-boundary, can use it naturally. (Of course, the difference in prop names isn't huge, but it's still nice that they wouldn't need to read extra documentation.)

Or (just a personal thought, suggestion), how about changing shouldCatch to shouldError? I think it aligns with the behavior of onerror used in JS/HTML, such as EventTarget.onerror or <img />'s onerror. It’s consistent with the concept of "setting a callback that runs when an error occurs," and from the perspective that we are defining what we consider an “error,” I think shouldError is also worth considering.