Initial implementations of spans

[cubuspl42]

Summary:

This is the initial implementation of "spans", the feature tracked in #42602.

Changelog:

[INTERNAL] [ADDED] - Initial implementation of spans

Test Plan:

[cubuspl42]

@NickGerleman

This PR includes bits based on your feedback from:

• Extract the typeface-finding logic to findEffectiveTypeface #42704
• Refactor TextFragmentList into AttributedString #42701

1. Would you take a look at these commits...

• 1762362 (Introduce SpanFragment and SpanAttributes)
• 08ddbff (Support display: inline style)
• 7f2467e (Draw spans on Android)

...and give me some high-level feedback? I'm especially interested if there is any chance at all that this direction could lead to the feature being merged.

2. I know that this PR is big. Do you have any ideas of how this could be split into chunks in a way that any of them would be considered acceptable on its own?

3. This is a Fabric-only implementation. Would it be acceptable for a new feature to be Fabric-only, or do all features have to support the legacy Paper renderer?

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	17,988,480	+53,419
android	hermes	armeabi-v7a	n/a	--
android	hermes	x86	n/a	--
android	hermes	x86_64	n/a	--
android	jsc	arm64-v8a	21,346,691	+53,407
android	jsc	armeabi-v7a	n/a	--
android	jsc	x86	n/a	--
android	jsc	x86_64	n/a	--

Base commit: 767330f
Branch: main

[cubuspl42]

@cipolleschi

We had an opportunity to discuss the public API of AttributedString in this PR:

• De-duplicate the logic for counting attachments #42596

Would you find a moment to take a look at this commit...

• 1762362 (Introduce SpanFragment and SpanAttributes)

...? It significantly changes the API and implementation of AttributedString and its befriended classes. Would such change be considered acceptable when its purpose is implementing a new valuable feature?

[cipolleschi]

Hi @cubuspl42, thanks for the effort!
Unfortunately, this PR is too big to be reviewed properly in one go, and it requires different layers of knowledge on the various technologies of the frameworks.

If we want to increase the chances of landing this, I suggest to split it in smaller pieces. Ideally, we can have:

• a PR for the shared code
• a PR for iOS
• a PR for Android
• a PR for JS.

Also, due to how our systems works, we might have to land the native code some days before the JS code.

[react-native-bot]

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[react-native-bot]

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[react-native-bot]

This PR was closed because it has been stalled for 7 days with no activity.