Context scoping clarification

[luisorbaiceta]

Hi Radix team!

First of all I would like to congratulate you for the amazing job you have done so far, this library really makes the difference in every aspect.

As I said here, I'm planning to invest some time helping, so I'm trying to study every implementation and component that you provide. But I'm having a hard time figuring out how are you handling contexts.

Seems that there is an scoping system, but I'm having a hard time understanding its goal. My only guess so far has been that is used for unification and clarity but I don't know If this is really the intention.

Thanks in advance and have a great week!

[jjenzz]

@luisorbaiceta Thank you. Really pleased that you're having a poke around and look forward to seeing what you contribute!

Radix Primitives API is intentionally very open allowing for all sorts of compositions. For example:

<AlertDialog.Root>

  <Dialog.Root>
    <Dialog.Trigger />
    <Dialog.Content>
      <AlertDialog.Trigger /> {/* note the alert trigger in dialog content */}
    </Dialog.Content>
  </Dialog.Root>

  <AlertDialog.Content />
</AlertDialog.Root>

An issue arises here though...

The AlertDialog is a Dialog composition under the hood with additional functionality bound to meet AlertDialog requirements. This means that AlertDialog.Root is also a Dialog.Root so provides both DialogContext and AlertDialogContext.

Due to the way React Context works, the composition above would mean the AlertDialog.Trigger (also a Dialog.Trigger) would useContext(DialogContext) and wind up retrieving the context from Dialog.Root instead of AlertDialog.Root. Therefore, clicking the AlertDialog.Trigger would toggle the Dialog.Content.

The scoping ensures that AlertDialog.Trigger context is scoped to AlertDialog parts and doesn't accidentally retrieve context from another component composed of similar parts. It does this by creating a new context that it passes to its Dialog internally via the __scopeDialog prop, which Dialog then passes to all of its useContext calls.

There are many advantages to compound components but this is one of the disadvantages unfortunately. If our consumers re-composed one of our components to build out their own separate patterns and then used them together like the above example, they would have similar issues.

It would be good to raise this with the React team tbh as they might have better ideas for solutions. Otherwise, we could always try to document our scoping API for consumers to use if they hit this issue themselves.

Anyway, hope that helps a little. I'm happy to answer any additional questions you might have on all this because it's a bit of a mind bender 😅

[benoitgrelard]

How would you do that though? the context is already encapsulated inside Dialog.

[jjenzz]

@TheEhsanSarshar what you describe is what the context scoping does. AlertDialog has its own context which it passes to the Dialog that it renders internally, and then the dialog uses that context instead. without this, the dialog would use its own DialogContext and that's where the bug arises.

[byteab]

yea I see
I mean what if we pass a scope string to the <MyProvider scope={"AlertDialog"}/> and useMyContext("AlertDialog") and then it pick/create -> pick; from a map of scopeName: Conext. just to avoid complexity here. and make the API easier

function createContext() {
     const scopedContexts: { [scope: string]: Context } = {}
     const DefaultContext = React.createContext()
     const Provider = (scope) => {
           if(scope) {
              // pick from the array if exists, otherwise create a scoped Context and store it in array
           } else {
               // return DefaultContext.Provider
           }
     }
     const useMyContext = (scope) => {
         // use same logic as in Provider
     }
}  

please correct me if this solution is wrong

[DVGY]

@byteab looks good. This is what you have done in tamagui scoped context ?

[DVGY]

@jjenzz Your explanation is nice. I went a step ahead and changed the Avatar component to use normal createContext.
It seems to be working fine. I think there are some cases or patterns where normal createContext might fail. Can someone help me understand thoseI wanted to reproduce those? By doing this makes me a better developer. Thanks

// Psuedu code

// Create a normal context
const Avv2atarContext = createContext<Avv2atarContextValue>({} as any)

type ImageLoadingStatus = 'idle' | 'loading' | 'loaded' | 'error'

type Avv2atarContextValue = {
  size: SizeTokens
  imageLoadingStatus: ImageLoadingStatus
  onImageLoadingStatusChange(status: ImageLoadingStatus): void
}

export const Avv2atarProvider = ({
  children,
  size,
  imageLoadingStatus,
  onImageLoadingStatusChange,
}) => {
  return (
    <Avv2atarContext.Provider value={{ size, imageLoadingStatus, onImageLoadingStatusChange }}>
      {children}
    </Avv2atarContext.Provider>
  )
}

// Inside my AvatarImage and AvatarFallbackImage I use like this below 

const context = useAvv2atarContext()

//This is how my AvatarComponent looks like 

const Avv2atar = withStaticProperties(
  React.forwardRef<any, Avv2atarProps>((props: Avv2atarProps, forwardedRef) => {
    const { size = '$true', ...avatarProps } = props

    const [imageLoadingStatus, setImageLoadingStatus] = React.useState<ImageLoadingStatus>('idle')
    return (
      <Avv2atarProvider
        size={size}
        imageLoadingStatus={imageLoadingStatus}
        onImageLoadingStatusChange={setImageLoadingStatus}
      >
        <Avv2atarFrame size={size} {...avatarProps} ref={forwardedRef} />
      </Avv2atarProvider>
    )
  }),
  {
    Image: Avv2atarImage,
    Fallback: Avv2atarFallback,
  }
)

I use the component like this

<Avv2atar circular size="$8">
              <Avv2atar.Image
                accessibilityLabel="Nate Wienert"
                src="https://images.unsplash.com/photo-1531384441138-2736e62e0919?&w=100&h=100&dpr=2&q=80"
              />
              <Avv2atar.Fallback delayMs={600} backgroundColor="$blue10" />
</Avv2atar>