Address #5047 - Open global create when a user logs in for the first time

[mateomorris]

Details

When a user opens New Expensify for the first time, the Global Create Menu should open automatically.

Fixed Issues

$ #5047

Tests

Ensure that menu opens for new users & existing users logging in for the first time since update

1. Sign in
2. Validate that menu opens
3. Refresh
4. Validate menu doesn't open

Ensure that menu doesn't open for existing users who the menu has already opened for

1. Sign in
2. Validate that menu doesn't open

QA Steps

Using a brand new account:

1. Sign in after signing up
2. Verify that the global create menu opens automatically

Using an existing account which hasn't seen the menu open automatically yet

1. Sign in
2. Verify that the global create menu opens automatically

Using the same existing account

1. Refresh the page
2. Verify that the global create menu doesn't open

Tested On

• Web
• Mobile Web
• Desktop
• iOS
• Android

Screenshots

Web

OpenGlobalCreate.mov

Desktop

Attached is an example of the menu not opening for an existing user, but not it opening for a new user.
I can't see a way to test for a new user on desktop because I can't replace the address in Electron (meaning I can't create a new account & click the signup link to open the desktop app). If necessary, I could create a url bar in Electron, but that would take some extra work.

Desktop.mov

Mobile Web

mobilewebdemo.mov

iOS

iosDemoOpenMenu.mov

Android

Incoming - still getting my environment set up

[mateomorris]

Looks like there's a weird issue on iOS causing the menu not to open on first load. Investigating now.

[mateomorris]

Here's a demonstration of the issue:

Screen.Recording.2021-09-13.at.12.50.21.AM.mov

The menu opens when you refresh the simulator, but not when the app first loads (which will presumably happen in production).

But I think I've zeroed in on what's causing it.

This is the only PopoverMenu in the app that has an issue rendering on first load [on mobile] because it's the only one inside drawerContent:

<BaseDrawerNavigator
    drawerContent={() => <SidebarScreen />}
    screens={[
        {
            name: SCREENS.REPORT,
            component: ReportScreen,
            initialParams,
        },
    ]}
    isMainScreen
/>

When it gets passed directly as a screen, it has no issue rendering on first load

<BaseDrawerNavigator
    screens={[
        {
            name: SCREENS.REPORT,
            component: SidebarScreen,
            initialParams,
        },
    ]}
    isMainScreen
/>

demo2.mov

The only workaround I've found is to set a timeout in SidebarScreen.js's componentDidMount, which makes me think it's a race condition.

    componentDidMount() {
       ...
        
        setTimeout(() => {
            this.toggleCreateMenu()
        }, 200) // Setting the timeout to 0 seconds (i.e. waiting for the tick) doesn't work
    }

But obviously that's... not ideal.

Since it seems like the issue is with react-native-modal (note that using the standard react-native modal didn't help) inside @react-navigation/drawer, I don't think the root issue can be solved within this codebase. My suggestion - besides reopening the issue - would be to go with the non-ideal workaround (which could very well break on different devices) or only automatically open the menu on desktop/web. For what it's worth, it strikes me as nonstandard behavior on mobile anyway.

[Beamanator]

Please keep semicolons on each line, and trailing commas :D Expensify style preference

[Beamanator]

@mateomorris thanks for the investigation into the issues on mobile! If your temporary workaround (using setTimeout) works fine on all platforms now (I'll test in a minute), maybe we can move forward with your workaround and create a new issue for what you're reporting. I'll look into this a bit today too to see if I can get anywhere

[Beamanator]

3 more little linting errors (we're close!)

[Beamanator]

Nice! Tests well, please feel free to report the issue regarding the race condition so we don't have to keep the setTimeout for iOS!

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[OSBotify]

🚀 Deployed to staging by @Beamanator in version: 1.0.97-1 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

[marcaaron]

(this may need to be moved if this NVP is used for anything else later)

This comment isn't really useful. Why are we thinking about what we might do with this later. Let's just focus on what we are using it for now because we don't know how else it would be used or why that would make a difference to the code here.

[marcaaron]

For some reason, the menu doesn't open without the timeout

This isn't really an acceptable solution and we should try to avoid adding things to the code that we don't understand.

[marcaaron]

Just one idea that I haven't tested but to get around the setTimeout could we instead check for a change to the prop in componentDidUpdate like this?

SidebarScreen.propTypes = propTypes;
export default compose(
    withLocalize,
    withWindowDimensions,
    withOnyx({
        betas: {
            key: ONYXKEYS.BETAS,
        },
        isFirstTimeNewExpensifyUser: {
            key: ONYXKEYS.NVP_IS_FIRST_TIME_NEW_EXPENSIFY_USER,
            initWithStoredValues: false, // Ensure we always use the value from the server
        },
    }),
)(SidebarScreen);

Then have a defaultProp of false for this value. Which will allow us to check the the NVP in the server and then decide to open the menu like this:

componentDidUpdate(prevProps) {
    if (!prevProps.isFirstTimeNewExpensifyUser && this.props.isFirstTimeNewExpensifyUser) {
        this.toggleCreateMenu();
        NameValuePair.set(CONST.NVP.IS_FIRST_TIME_NEW_EXPENSIFY_USER, false, ONYXKEYS.NVP_IS_FIRST_TIME_NEW_EXPENSIFY_USER);        
    }
}

[botify]

This has been deployed to production and is now subject to a 7-day regression period.
If no regressions arise, payment will be issued on 2021-09-22. 🎊

[OSBotify]

🚀 Deployed to production by @francoisl in version: 1.0.98-1 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

[Beamanator]

Discussed with @marcaaron , I'm removing DeployBlockerCash as this fix is needed for n6. I'll make a new issue to get to the bottom of the weirdness experienced here so we can remove the need for setTimeout