[Tracking] Expensify/App cleanup + style guide + README improvements

[marcaaron]

Problem

Expensify/App, Onyx, and our JS styles are inconsistently enforced in the Expensify/App repo. This can happen for many reasons, but one obvious one is that we just haven't written down in our style guide clear examples.

Why is this important?

Incorrect patterns will create more incorrect patterns and general confusion about the "right way" to make a change or implement a feature. Every Expensify contributor should ideally have what they need to be able to champion our code styles and philosophies when reviewing any contribution (internal or external). But this can be difficult without a clear guide to refer to.

Solution

Let's do a quick audit of various things that need clarification and clean them up by creating an issue for each best practice.

The assignee will:

1. Figure out why we have chosen to do things this way
2. Update the style guide with a clear explanation and make sure that it can easily be linked to (if necessary)
3. Update the Expensify/App codebase to eliminate any inconsistencies

Here's a list of things that need to be addressed and can be broken out into other issues:

• Cleanup usages of null coalescence operator #5985
• Cleanup Optional chaining #5986
• Cleanup usages of Onyx directly inside a view #5998
• Fix all inline named exports. Export everything at the bottom of a file. #6011
• Remove usages of compose() with only a single method #6000
• Cleanup component's displayName properties so that functional components all have it and class components do not #6002
• Clean up propTypes imports not usIng camelCase #6004
• Cleanup native array methods prefer _ #5989
• Cleanup any promise chains off of actions inside views #6092
• [HOLD] Cleanup usages where early return is preferred #5995
• No props destructuring for functional components #6250
• Eliminate dependency cycles #6251
• Standardize on import * as Something when modules only have named exports #6072
• Make sure that we are always using Onyx.merge() over Onxy.set() except for when absolutely necessary

Feel free to suggest other things to this list!

[johnmlee101]

Can this be aided with any linting rules?

[tgolen]

We should definitely try to use linting rules whenever necessary, but for a vast majority of these, there are no lint rules for them.

[marcaaron]

I like the idea of looking into some custom lint rules for things like using an array method instead of _. Especially if they direct you to the style guide to also learn why we prefer to do things one way over another. I don't have much experience with writing them so maybe others have ideas on if it's practical.

[kidroca]

There are existing eslint rules for

• prevent null coalescing operator: https://eslint-plugin-es.mysticatea.dev/rules/no-nullish-coalescing-operators.html
• prevent optional chaining: https://eslint-plugin-es.mysticatea.dev/rules/no-optional-chaining.html

There are rules against using native array methods like foreach, filter, map, reduce and so on. Though then won't be able to suggest to use _ instead

Here are some more rules that I think match Expensify current convention

• no get/set https://eslint-plugin-es.mysticatea.dev/rules/no-accessor-properties.html
• no async https://eslint-plugin-es.mysticatea.dev/rules/no-async-functions.html

[kidroca]

Regarding "Make sure that we are always using Onyx.merge() over Onxy.set() except for when absolutely necessary"

This is not just an Expensify/App problem, every future consumer of Onyx can have the same problem as mixing merge and set can lead to race conditions: #5930

In that case IMO it would be best to expose only one method for updating Onyx: #5930 (comment)

[kidroca]

• [HOLD] Cleanup usages where early return is preferred #5995 - Shopify have a custom rule prefer-early-return: https://github.com/Shopify/web-configs/blob/main/packages/eslint-plugin/docs/rules/prefer-early-return.md

[kidroca]

• Cleanup any promise chains off of actions inside views

To prevent this the action should not return a promise
Cleaning up the chain or ignoring the promise of a promise returning method (an async method) is considered an anti pattern as it leads to swallowed errors (Unhandled promise rejection). Many editors would warn you about it, if the promise is handled and the user should not be interacting with it - it should not be exposed to the user.

[roryabraham]

Perhaps out-of-scope, but I've found that there's a lack of consistency in the order in which modules are imported. I would love to impose the sort-imports ESLint rule, and perhaps even absolute import paths.

Also we should nix lodashGet and consistently use _.get instead – one fewer dependency 😄

Edit: eslint-plugin-import seems like maybe a better option than sort-imports

[marcaaron]

@kidroca Thanks for those insights! I think some of those eslint rules definitely make sense for us to add.

mixing merge and set can lead to race conditions

That's a good point. I guess we can keep discussing on that issue, but sounds like the race condition issue might not change whether we should prefer set() or merge(). I think the point we want to make with that one is mostly that we should use whichever is more appropriate.

To prevent this the action should not return a promise

This gets a little tricky sometimes since when actions are referenced by other actions we sometimes need them to return promises, but I like where that idea is going. Probably in those cases we are missing opportunities to move more logic to the API layer.

[marcaaron]

nix lodashGet and consistently use _.get instead – one fewer dependency

@roryabraham that's come up a few times so I think we should just do it!

[marcaaron]

Related to all this I was trying to come up with a graphic to maybe help give a high overview of the app architecture.
Thoughts on adding something like this to the readme? Any changes I should make?