Use contextBridge?

[natew]

Found this: https://github.com/pmndrs/its-fine#usecontextbridge

Think we could make this work with this library to avoid the context clearing issue? I could try out a PR

[gorhom]

good suggestion, i will look into , but feel free to submit a CR and i'll look into it this weekend

[gorhom]

@natew thanks for the suggestion, the library seemed to expose the internal contexts, but there is something wrong with passing values

Screen.Recording.2023-09-16.at.13.56.46.mov

[gorhom]

i think i found the issue with the memoized bridge that it returns https://github.com/pmndrs/its-fine/blob/main/src/index.tsx#L221-L233 the equality check does not run a deep equality check which causes the return memoized value to be static and never change.

[CJY0208]

I found this library while making a RN modal component. I noticed that its implementation method is very similar to my library react-activation(implements Vue keep alive in React).

Due to the movement of the virtual DOM, they both encountered the problem of context discontinuity. The approach of react-activation to this problem is to leave a consumer that listens to the context at the position of transferring the virtual DOM, and transfer all captured context content along with the virtual DOM to the outside. At the position of rendering the virtual DOM, the provider is rebuilt based on the captured context content.

This approach seems to have similarities with useContextBridge, hoping it could be of some help to this library.

[JanithaR]

Found this: https://github.com/pmndrs/its-fine#usecontextbridge

Think we could make this work with this library to avoid the context clearing issue? I could try out a PR

What is the "context clearing issue" you are talking about here? Can we not consume a context from a component wrapped by a portal or something else? I ran into that issue in a rather old React Native code base. I can't gain access to contexts outside the portal and trying to figure out how to do.

[bryanmylee]

@JanithaR You've described the issue exactly. Because the portal content is being rendered in a different part of the virtual DOM tree, it does not actually get "enclosed" by the context. Therefore, any calls to useContext or Consumer won't receive the correct context values.

You can use useContextBridge to forward and reconstruct all context values across the portal boundary, but there are some issues with reactivity.

[souyahia]

Hey @gorhom , so in our app we are facing a similar issue where we have to have some React contexts declared under the BottomSheetModalProvider component, thus making it so that some of our contexts are not accessible from within the BottomSheetModal contents.

After taking a look at this PR, and at the source code of its-fine, we came up with the following solution :

const ContextPortal = createContext<Map<Context<any>, any> | null>(null);

interface ContextPortalProviderProps {
  portal: Map<Context<any>, any>;
}

export const ContextPortalProvider = ({
  portal,
  children,
}: PropsWithChildren<ContextPortalProviderProps>) => {
  return (
    <ContextPortal.Provider value={portal}>{children}</ContextPortal.Provider>
  );
};

type ContextWithValue<T> = [Context<T>, T];

export function useContextPortalProvider(contexts: Context<any>[] = []) {
  /**
   * If you are using React 19, you can directly use the "use" function like this :
   * ```
   * const values: ContextWithValue<any>[] = withContexts.map((Context) => [
   *   Context,
   *   use(Context),
   * ]);
   * ```
   * Until then, we have to call the useContext hook inside a for loop. This is ugly, but
   * it works and it is kinda safe since the context array is not supposed to change, so
   * the order / number of hooks called will not change either.
   */
  const values: ContextWithValue<any>[] = withContexts.map((Context) => [
    Context,
    useContext(Context),
  ]);

  const portal = useMemo(
    () => new Map(values),
    [...values.map(([_, value]) => value)],
  );

  return { portal };
}

export function useContextOrPortal<T>(context: Context<T>): T {
  const value = useContext(context);
  const portal = useContext(ContextPortal);

  if (value) {
    return value;
  }

  return portal?.get(context) ?? null;
}

And then we then have a wrapper with the bottom sheet modal component like this :

interface BottomSheetModalWrapperProps extends BottomSheetModalProps {
  withContexts?: Context<any>[];
}

const BottomSheetModalWrapperComponent = (
  { withContexts, children, ...props }: BottomSheetModalProps,
  ref: ForwardedRef<BottomSheetModal>,
) => {
  const { portal } = useContextPortalProvider(withContexts);

  return (
    <BottomSheetModal ref={ref} {...props}>
      <ContextPortalProvider portal={portal}>{children}</ContextPortalProvider>
    </BottomSheetModal>
  );
};

export const BottomSheetModalWrapper = forwardRef(BottomSheetComponent);

Obviously the code is a bit simplified in this example, but using this logic, we can then use our bottom sheet modals like this :

export const MyCustomBottomSheet = () => {
  return (
    <BottomSheetModalWrapper withContexts={[MyContext, MyOtherContext]}>
      ...
    </BottomSheetModalWrapper>
  );
};

And this way, we are able to expose custom contexts through our bottom sheet modals without any issue. The only potential downside of this approach is that we are declaring a single context that exposes the required contexts to the bottom sheet children. This means that when ONE portalled context changes, every subscriber of every portalled context will be re-rendered. For our custom use case this is completely fine but it is something worth mentioning. We could avoid this by having on portal provider for each portalled context, but this is very hard to do while also keeping the memoization of the bottom sheet content (every solution we tried induced a mount / remount of the bottom sheet content on every context change), so we chose the other option instead haha.

The withContexts prop is probably not ideal to add into the bottom sheet library, but I thought maybe this approach could be useful for react-native-portal