-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please export textAncestor
context
#495
Comments
1 task
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Introduction
In React Native, everything inside a first
<Text>
component behaves differently to everything outside (further<Text>
elements apply annotations rather than defining a container, loose strings are allowed as children,Views
are positioned as nested views and some layout styles no longer take effect, rules around focusability and the application of accessibility props changes, etc etc).Internally, React Native uses
textAncestor
context to find out if there is a<Text>
further up the tree and to judge if this contextual flip has taken place.There are some cases where it would be extremely useful for library authors and app developers to also be able to access this context, and see if a component is being rendered inside or outside of
<Text>
.Details
Block-level
Text
and inline nestedText
behave very differently; and inline nestedView
s also behave somewhat differently. There are several cases where it would be useful for a component author to be able to doconst isNested = useContext(textAncestor)
and make choices based on how their component's top level children are being rendered.Here are a few example cases I've encountered where this would have been very useful:
<Text>
only when necessary, simplifying styling.Discussion points
I can't see any negatives to exporting
textAncestor
context. Its API is incredibly simple so in theory should be very stable: its value istrue
if there's a<Text>
up the tree,false
if not. I understand that many internal utilities are best kept private so their evolution doesn't get held back by the need to minimise breaking changes to public APIs buttextAncestor
is so simple, this doesn't seem to be an issue.I accept that many of the uses of
textAncestor
are not common, but also, they are the sorts of uses that can't be worked around any other way currently.The text was updated successfully, but these errors were encountered: