Feature-Request: Add body() method

[hepiyellow]

In all platforms (adapter), there is a body.
But in each platform getting the body element is different.

Some component, render stuff to the body (Modals, Popovers with Portal), and need to expose drivers that can query the body, and abstract inner implementation.

@GabiGrin Is this legitimate?

[jonathanadler]

+1

[GabiGrin]

@jonathanadler what's your use case?
isn't this feasible for modals / popovers?

[jonathanadler]

@jonathanadler what's your use case?
isn't this feasible for modals / popovers?

@GabiGrin !! how are you feeling?? 😁

So yeah, actually we're using this pattern, but as I understand we need to pass "theOuterWorld" driver ourselves.
I guess my thought was, that instead of wrapping the body in a Unidriver in each library, it could be something we get from this library as a helper.

[jonathanadler]

@GabiGrin

The use-case for this is when one driver uses another driver that accepts an outerWorld.

For instance, if we have an input component that has a tooltip, and we want to have a getTooltipContent method in the input driver.
What we would like to do is use the Tooltip's already existing driver (which accepts theOuterWorld), in order to get its content.
This means that the input will also need to accept theOuterWorld unidriver.
But that's something we would prefer to not expose to our consumers.

To put it in code, it would look like this:

export const inputDriver = (wrapper: UniDriver, theOuterWorld: UniDriver) => {
  const tooltipDriver = createTooltipDriver(wrapper.$('tooltipSelector').getNative(), theOuterWorld);
  return {
    ...
    getTooltipContent() {
      return tooltipDriver.getContent();
    }
    ...
  }
}

This means our consumers will need to create a "body" unidriver when they use our testkits.
(what we actually do is we pre-wrap our testkits with theOuterWorld driver, which means we effectively create a "body" unidriver for all our testkits).

I think the body is pretty much a constant and can be reached in all environments
So I really think that this can be very useful to maintain one in this library.

In addition, these types of components usually use a portal which is outside of the wrapper element passed to the driver.