[HOLD for payment 2023-10-10] [$1000] Task description label stays on top

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Click on FAB -> Click Assign Task
2. Add some Title & Description -> Click Next
3. On Confirm Task screen, Click on Description to update description
4. Clear description -> Click on Next button
5. You will now again be on Confirm Task page (with Empty Description)
6. Click back button -> See Description label floating

Expected Result:

Description label should be placed inside textfield if it’s empty

Actual Result:

Description label is floating over textfield (as it has some text in it, but there is no data inside textfield )

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.36-3
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

RPReplay_Final1688399438.mp4

XXFM1942.1.MP4

Expensify/Expensify Issue URL:
Issue reported by: @DinalJivani
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1688400346545699

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~017f8f2919130b85b3
• Upwork Job ID: 1678898666441887744
• Last Price Increase: 2023-08-04

[melvin-bot]

Triggered auto assignment to @michaelhaxhiu (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[kushu7]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Task description label stays on top

What is the root cause of that problem?

App/src/components/TextInput/BaseTextInput.js

Lines 25 to 39 in 7e908b1

	const inputValue = props.value || props.defaultValue || '';
	const initialActiveLabel = props.forceActiveLabel || inputValue.length > 0 || Boolean(props.prefixCharacter);
	const [isFocused, setIsFocused] = useState(false);
	const [passwordHidden, setPasswordHidden] = useState(props.secureTextEntry);
	const [textInputWidth, setTextInputWidth] = useState(0);
	const [textInputHeight, setTextInputHeight] = useState(0);
	const [prefixWidth, setPrefixWidth] = useState(0);
	const [height, setHeight] = useState(variables.componentSizeLarge);
	const [width, setWidth] = useState();
	const labelScale = useRef(new Animated.Value(initialActiveLabel ? styleConst.ACTIVE_LABEL_SCALE : styleConst.INACTIVE_LABEL_SCALE)).current;
	const labelTranslateY = useRef(new Animated.Value(initialActiveLabel ? styleConst.ACTIVE_LABEL_TRANSLATE_Y : styleConst.INACTIVE_LABEL_TRANSLATE_Y)).current;
	const input = useRef(null);
	const isLabelActive = useRef(initialActiveLabel);

Problem is we don't update refs and values on Focus of screen.
When value removed by other page and we go back TaskDetails page stay mounted. thus BaseTextInput doesn't know it has to update label position. it just calculate on Mount currently.

What changes do you think we should make in order to solve the problem?

I found a good solution.
We already have this useEffect that is responsible for activating/deactivating

App/src/components/TextInput/BaseTextInput.js

Lines 186 to 198 in cd09dc9

	const hasValueRef = useRef(inputValue.length > 0);
	// Activate or deactivate the label when the focus changes:
	useEffect(() => {
	// We can't use inputValue here directly, as it might contain
	// the defaultValue, which doesn't get updated when the text changes.
	// We can't use props.value either, as it might be undefined.
	if (hasValueRef.current || isFocused) {
	activateLabel();
	} else if (!hasValueRef.current && !isFocused) {
	deactivateLabel();
	}
	}, [activateLabel, deactivateLabel, inputValue, isFocused]);

We can just update hasValueRef using props.value changes using useEffect.
but we can't just directly update it, we have to check if inputValue is not equal to defaultValue and also check if props.value has any value.

     const hasValueRef = useRef(inputValue.length > 0);

    useEffect(() => {
        const hasValue = !!props.value
        if (inputValue !== props.defaultValue || hasValue) {
            hasValueRef.current = props.value && props.value > 0;
        }
    }, [props.value, inputValue, props.defaultValue])

It will activate/deactivate label properly

Video

vid.mov

What alternative solutions did you explore? (Optional)

We can use useFocusEffect hook to reAdjust label position by comparing previous and current ref value.

useFocusEffect(useCallback(() => {
// return early if ref and prop value is same or input is focused
    if (isLabelActive.current === initialActiveLabel || isFocused) return;
    hasValueRef.current = inputValue.length > 0;
    isLabelActive.current = initialActiveLabel
    if (initialActiveLabel) {
        activateLabel();
    } else {
        deactivateLabel();
    }
    // eslint-disable-next-line react-hooks/exhaustive-deps
}, [initialActiveLabel, inputValue,isFocused]))

[bernhardoj]

@hannojg maybe can take a look at this one too. We previously fixed this label issue here

[hannojg]

Yes thx for pinging me, I will look in a few hours into this!

[hannojg]

Looking into it now

[hannojg]

I do think I found a clean solution (note: I am the author of the original PR that caused the regression 😅 ):

Proposal

Please re-state the problem that we are trying to solve in this issue.

In our code we use uncontrolled and controlled TextInputs (i.e. providing a value prop or not). A recent change to our BaseTextInput component caused a regression where a controlled component wouldn't deactivate its label when the prop value has been reset to being empty (and the text input blurred).

What is the root cause of that problem?

Currently we are deciding on whether to deactivate the label based on two criteria:

• The text input isn't focused anymore
• We capture whether we have an input value in a ref, when TextInput#onChangeText gets called

In the second criteria lies the root cause. When we update the TextInputs value by the value prop onChangeText won't get called. Hence, when clearing the input with the value prop, the hasValueRef is still true.

What changes do you think we should make in order to solve the problem?

Right now we have a useEffect that only triggers when the focus of the text input changes.
We extend that useEffect to also run when the value prop changes. When we detect that the value prop is empty and we have no focus, we will deactivate the label.

Before we were thinking we can't use the value prop in the useEffect because we wouldn't know whether the component is controlled or not, and thus could break the behaviour for uncontrolled text inputs. We need to consider both possibilities for having a value. The final result will look like this:

// We capture whether the input has a value or not in a ref.
// We need this information in case the component
// is uncontrolled (i.e. no value prop is supplied)
const hasValueRef = useRef(initialValue.length > 0);

const inputValue = props.value || '';
const hasValue = inputValue.length > 0 || hasValueRef.current;

// Activate or deactivate the label when either focus changes, or for controlled
// components when the value prop changes:
useEffect(() => {
    if (hasValue || isFocused) {
        activateLabel();
    } else if (!hasValue && !isFocused) {
        deactivateLabel();
    }
}, [activateLabel, deactivateLabel, hasValue, isFocused]);

This change also makes the code cleaner as now we can get rid of this useEffect:

App/src/components/TextInput/BaseTextInput.js

Lines 171 to 182 in a6ae94d

	useEffect(() => {
	// Handle side effects when the value gets changed programatically from the outside
	// In some cases, When the value prop is empty, it is not properly updated on the TextInput due to its uncontrolled nature, thus manually clearing the TextInput.
	if (inputValue === '') {
	input.current.clear();
	}
	if (inputValue) {
	activateLabel();
	}
	}, [activateLabel, inputValue]);

What alternative solutions did you explore? (Optional)

I had a look at the previous two proposals. Here are my notes (please note that they are meant completely judge free, we are just striving for the best possible solutions, and your guys' proposals were a great help in finding the final solution I came up with, so big thanks here 🙌 )

• @ginsuma Proposal: The proposal didn't really worked in my testing for fixing the issue, as setValue which gets called from onChangeText doesn't gets called necessarily when the value prop gets changed from the outside.
• @kushu7 Proposal: I think this could work, however it would leave other cases unhandled. Also giving a base text input knowledge about the current navigation focus feels somehow wrong and adds too much outside knowledge to a simple component in my opinion.

Screen.Recording.2023-07-06.at.10.51.29.mov

[melvin-bot]

Looks like something related to react-navigation may have been mentioned in this issue discussion.

As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js files should not be accepted.

Feel free to drop a note in #expensify-open-source with any questions.

[melvin-bot]

@michaelhaxhiu Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@michaelhaxhiu Still overdue 6 days?! Let's take care of this!