[Feature]: How about change AsyncBoundaryProvider(@toss/async-boundary) to ResetErrorBoundaryProvider(@toss/error-boundary)?

How about change AsyncBoundaryProvider(@toss/async-boundary) to ResetErrorBoundaryProvider(@toss/error-boundary)?

Package Scope

async-boundary, error-boundary

• Add to an existing package

Overview

Current AsyncBoundaryProvider is not scoped AsyncBoundary, I think it is just designed only for reseting resetKey ErrorBoundary

AS-IS: AsyncBoundaryProvider(@toss/async-boundary)

interface AsyncBoundaryProvider {
  resetKey: number;
  reset(): void;
}

const AsyncBoundaryContext = createContext<AsyncBoundaryProvider | null>(null);

interface Props {
  children: ReactNode;
}

export function AsyncBoundaryProvider({ children }: Props) {
  const [resetKey, reset] = useResetError();

  return <AsyncBoundaryContext.Provider value={{ resetKey, reset }}>{children}</AsyncBoundaryContext.Provider>;
}

export function useAsyncBoundaryContext() {
  return useContext(AsyncBoundaryContext) ?? { resetKey: null, reset: () => {} };
}

Describe the solution you’d like

If I can edit, I want to change AsyncBoundaryProvider to ResetErrorBoundaryProvider

TO-BE: ResetErrorBoundaryProvider(@toss/error-boundary)

const ResetErrorBoundaryContext = createContext({
  resetKey: 0,
  reset: () => {},
});
if (process.env.NODE_ENV !== 'production') {
  ResetErrorBoundaryContext.displayName = 'ResetErrorBoundaryContext';
}

interface Props {
  children: ReactNode;
}

export function ResetErrorBoundaryProvider({ children }: Props) {
  const [resetKey, reset] = useResetError();

  return <ResetErrorBoundaryContext.Provider value={{ resetKey, reset }}>{children}</ResetErrorBoundaryContext.Provider>;
}

export function useResetErrorBoundaryContext() {
  return useContext(ResetErrorBoundaryContext);
}

Additional context

1. More intuitive return type of useContext

AS-IS(ReturnType<typeof useAsyncBoundaryContext>)

union type is not intuitive.

import { expectType } from 'tsd';
expectType<AsyncBoundaryProvider | { resetKey: number; reset(): void; }>(useAsyncBoundaryContext()) // not intuitive, not essential union type 

TO-BE(ReturnType<typeof useResetErrorBoundaryContext>)

infer just one type like below picture

import { expectType } from 'tsd';
expectType<{ resetKey: number; reset(): void; }>(useResetErrorBoundaryContext()) // intuitive, just essential type 

2. add displayName Context only on development mode

we can check displayName, ResetErrorBoundaryContext.Provider on react-devtools only for development mode

const ResetErrorBoundaryContext = createContext({
  resetKey: 0,
  reset: () => {},
});
if (process.env.NODE_ENV !== 'production') {
  ResetErrorBoundaryContext.displayName = 'ResetErrorBoundaryContext';
}

3. How about ResetErrorBoundaryProvider.children can use reset easily like this

If I can’t use useContext, for example in Class Component or HTML like button or div, It will be helpful

ResetErrorBoundaryProvider

export function ResetErrorBoundaryProvider({ children: Children }: Props) {
  const [resetKey, reset] = useResetError();

  const node = typeof Children === 'function' ? <Children reset={reset} /> : Children;

  return <ResetErrorBoundaryContext.Provider value={{ resetKey, reset }}>{node}</ResetErrorBoundaryContext.Provider>;
}

Use Case

<ResetErrorBoundaryProvider>
  {({ reset }) => (
	<button onClick={reset} /*  <-- error reset 해야 하는 부분 */ />
	<AsyncBoundary /* <-- suspense + error boundary로 감싸져야 하는 부분 */
	    pendingFallback={<TableSkeleton title="상세내역" row={10} />}
	    errorFallback={({ error, reset }) => (
	      <ErrorAlert theme="yellow" error={error} message="다시 시도해주세요." onResetError={reset} />
	    )}
	>
      <DataViewer />
    </AsyncBoundary>
  )}
</ResetErrorBoundaryProvider>

Can I change AsyncBoundaryProvider like this? this will be BREAKING CHANGE, so I want to check it before starting code

[HoseungJang]

About renaming AsyncBoundaryProvider to ResetErrorBoundaryProvider, I think the current naming is appropriate.

Because I think AsyncBoundaryProvider is not just for resetting errors, and it provides controls for AsyncBoundary. Currently there is only the control to reset errors but I think any other controls could be added in the future.

And the naming AsyncBoundaryProvider is more clear because developers can intuitively see what they exactly reset:

const asyncBoundary = useAsyncBoundaryContext();
asyncBoundary.reset(); // resets only AsyncBoundary of `@toss/async-boundary`


const { reset } = useResetErrorBoundaryContext();
reset(); // resets error boundary but..

---

1. How about ResetErrorBoundaryProvider.children can use reset easily like this

I think this pattern is far from the concept of context provider. It looks like context consumer.

[raon0211]

Yes, I think @manudeli’s opinion is right. Resetting errors should be a responsibility of @toss/error-boundary, not @toss/async-boundary. Creating ErrorBoundaryProvider and making AsyncBoundaryProvider to use it seems to be the right way. (Can you refactor this and add a test case? – we also might do this)