Page MenuHomePhabricator

[native] Maintain spoiler reveal state on message tap
AbandonedPublic

Authored by rohan on Nov 7 2022, 4:28 AM.
Tags
None
Referenced Files
F3112266: D5541.id18152.diff
Thu, Oct 31, 5:02 PM
Unknown Object (File)
Sun, Oct 27, 2:16 PM
Unknown Object (File)
Sun, Oct 20, 6:40 PM
Unknown Object (File)
Mon, Oct 14, 10:44 PM
Unknown Object (File)
Sun, Oct 13, 9:50 PM
Unknown Object (File)
Sat, Oct 12, 7:42 AM
Unknown Object (File)
Thu, Oct 10, 10:56 AM
Unknown Object (File)
Tue, Oct 8, 2:48 PM

Details

Reviewers
atul
ginsu
ashoat
Summary

This is the final step of https://linear.app/comm/issue/ENG-2072/maintain-the-spoiler-state-upon-opening-textmessagetooltipmodal, where messages will retain their 'revealed' state when tapped to reveal the tooltip. With this diff, spoilers for native should now be fully functional, with two remaining tasks to just handle notifications and message previews.

Depends on D5539

Test Plan

Tested the states being retained both visually by revealing specific spoilers and then tapping a message, and also by logging the newly created objects to track the expected behavior.

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

rohan edited the test plan for this revision. (Show Details)
rohan attached a referenced file: F225076: Spoilers.mp4. (Show Details)
Harbormaster returned this revision to the author for changes because remote builds failed.Nov 7 2022, 4:36 AM
Harbormaster failed remote builds in B13193: Diff 18099!
rohan requested review of this revision.Nov 7 2022, 4:53 AM

Bypassing Android CI since it currently has ongoing problems

In D5541#164089, @rohan wrote:

Bypassing Android CI since it currently has ongoing problems

(When you get a second can you run git pull --rebase && arc diff to retrigger Android CI with latest changes)

atul requested changes to this revision.Nov 8 2022, 7:11 AM

Same feedback in D5539 about using React.useMemo instead of React.useState for holding onto style

native/markdown/markdown-spoiler.react.js
30–35

Since the style is an "output" of the state we should use a React.useMemo instead of React.useState that changes in response to changes in state.

That keeps things declarative and we don't have to imperatively call setStyleBasedOnState anytime the style should change.

This revision now requires changes to proceed.Nov 8 2022, 7:11 AM

Rebase, resolve conflicts, and use React.useMemo for spoiler style

Logic makes sense, just one question inline

native/markdown/markdown-context.js
12 ↗(On Diff #18290)

I am guessing this new line was an accident

atul requested changes to this revision.Nov 14 2022, 2:17 PM

Two things to be addressed before land-able

  • Clean up spoilerIdentifier naming/type/handling
  • Stop using styleBasedOnSpoilerState in subsequent logic... styles should be an "output" not an "input"
native/chat/inner-text-message.react.js
105 ↗(On Diff #18290)

Let's rename this messageContextValue just to be a bit more specific

105–107 ↗(On Diff #18290)

Can we use React.useMemo here to avoid unnecessarily re-computing the contextValue object?

native/markdown/markdown-context.js
12 ↗(On Diff #18290)

Yeah let's remove this newline to keep git history clean

native/markdown/markdown-spoiler.react.js
26 ↗(On Diff #18290)

Can we instead call this something like spoilerIdentifier so it's more descriptive?

What are we trying to achieve with the casted prefix? Should we be typing identifier as a number?

I'm guessing it's typed as string | number | void because that's what key is typed as?

If that's the case, is it fine for castedIdentifier to equal identifier if parseInt fails/is falsey? Or would that break things? I'd assume using void as an object key would lead to some broken behavior.

39 ↗(On Diff #18290)

We don't want to be using styles in our logic like this. Can we use the same castedIdentifier && spoilerRevealed?.[messageID]?.[castedIdentifier] conditional?

This revision now requires changes to proceed.Nov 14 2022, 2:17 PM
native/markdown/markdown-spoiler.react.js
26 ↗(On Diff #18290)

Sure, rename will come in the revision.

As for the casted prefix, it's just a way to identify that it's not the original identifier typed as string | number | void - instead, it's now a number instead of a string. Though a better naming convention would probably be parsedSpoilerIdentifier since we're calling parseInt instead of casting it.

To your other point, state.key is typed as string | number | void so it has to have the same type (identifier), though I agree - I think I better check would be:

const { text, spoilerIdentifier } = props;

const parsedSpoilerIdentifier = spoilerIdentifier ? parseInt(spoilerIdentifier) : -1;

Rebase on previous diff in stack (should be successful)

This revision is now accepted and ready to land.Nov 15 2022, 3:39 PM

After adding MessageContext.Provider to InnerTextMessage, there is no reason that it needs to stay in TextMessage, which renders InnerTextMessage inside of itself anyways. Let's make sure we don't have two components in the same hierarchy setting MessageContext

Update to use messageKey and remove extra MessageContext from
TextMessage

ashoat requested changes to this revision.Nov 22 2022, 6:11 AM

Let's abandon this diff... see my comment in D5515

This revision now requires changes to proceed.Nov 22 2022, 6:11 AM

Abandoning since this can easily just be done in D5515, as pointed out by @ashoat. I'll include it there when I'm able to put out a revision to that diff