Skip to content
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

RFC: Faster capHeight-baseline rendering in <Text> #43

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mmmulani
Copy link

This RFC discusses the bounding box, and a way to specify what type of bounding box you want.

@axe-fb
Copy link
Collaborator

axe-fb commented Oct 19, 2018

cc @rigdern - since he was interested in text areas !!

@Ashoat
Copy link

Ashoat commented Oct 20, 2018

I have a question which is only partially related, but I figured I'd ask.

Something that’s historically been a struggle for me in React Native has been measuring the height of a multiline Text for the purpose of calculating FlatList item height.

In classic iOS/Android there are ways to calculate this outside of the render path, and there are a couple of community-maintained native modules that hook into these native APIs. Outside of those, the only way to do this with pure JS (in Expo, for instance) is with multiple render passes. My current approach involves invisibly rendering all Texts in batches, and blocking the render of the FlatList until I have all the heights. This obviously isn’t good for performance.

Your proposal feels related to this problem since it obviates the need for a render pass for measuring aspects of text, but it's limited to a specific problem scope. I'm wondering if there's a way we could address the FlatList item height issue as well. (I'm also curious if there’s a better solution to the problem I described that I’m just not familiar with.)

@kelset kelset added the 💡 Proposal This label identifies a proposal label Oct 22, 2018
@mmmulani
Copy link
Author

chatted with @sahrens about it a bit, and we both agree that a general-purpose Text measurement API could be useful, especially in the FlatList case.

We think the better approach for that would be to wait for Fabric to expose synchronous layout APIs, as you probably want to know the overall size for a element, and possibly in relation to other elements

btw good to cross paths again :)

@Ashoat
Copy link

Ashoat commented Oct 23, 2018

That makes a whole lot of sense - Fabric will no doubt make that a lot easier. Thanks for looking into it!

And sorry for the distraction on this proposal. I haven't personally had a need for custom bounding boxes around text yet, but this declarative approach makes sense to me.

And nice to hear from you as well! :)

@cpojer
Copy link
Member

cpojer commented Feb 6, 2019

@mmmulani what is the status of this RFC?

@mjmasn
Copy link

mjmasn commented Feb 6, 2019

Am I right in thinking this would be a useful solution to implementing stuff like https://material.io/design/components/app-bars-top.html#specs where for example the title text is positioned based on its baseline being offset 20dp from the bottom of its parent view? Getting this to work is currently a bit of an approximation and the whole material spec uses text baseline for positioning 😞

@mmmulani
Copy link
Author

mmmulani commented Feb 6, 2019

@mjmasn this RFC would make it faster to render stuff like that but you can already do it by using onTextLayout. Check out the TextExample in RNTester.

@cpojer this is unimplemented for iOS and Android but would take 1-3 days effort for someone.

@cpojer
Copy link
Member

cpojer commented Feb 6, 2019

@mmmulani do you plan on implementing it or finding somebody to do it? I'm hesitant to merge RFCs if there is no clear owner for next steps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💡 Proposal This label identifies a proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants