Use faster implementation for merging

[Szymon20000]

The whole problem is described here Expensify/App#11185

On Android merging takes a lot of time
I Initially thought that maybe it's caused by slow loads implementation but after looking more deeply into the problem it looks like require takes in lodash a lot of time. Have no idea how because it should be required only once and later not take time at all but it's not the case. Maybe some circular dependencies?

I used the latest react-native-onyx package .18 with recent fixes like getting rid of merging items of array one by one. But it seems to no solve the problem.

Details

Related Issues

GH_LINK

Automated Tests

Linked PRs

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[Szymon20000]

@iwiznia Could you take a look as you recently optimised the same part?

[mountiny]

@Szymon20000 You will also need to sign the CLA in this repo as well!

Regarding the JSDoc, lets update the indentation as you can see here, for example https://github.com/Expensify/App/blob/da6e3aac5b64154e1d87c261f34829e097c7b433/src/libs/ReportUtils.js#L388-L393

ie the next line has one whitespace at the start of the line. Thanks!

[Szymon20000]

I have read the CLA Document and I hereby sign the CLA

[mountiny]

@Szymon20000 I am also thinking if we should update the Docs for the functions, they always just copy what the function name is so it is not very useful. So we should either expand on it (why it is there/what it is used for - which would be handy imho) or remove them as they dont add any value as its current form

[mountiny]

We have some failing test still:
Onyx › Cache Service › merge › Should do nothing to a key which value is undefined``

[mountiny]

Thanks! Lgtm!

[tgolen]

The code looks good, but I think the ESlint warnings need to be cleaned up better. The only time an eslint rule should be disabled is when there is a business reason for it (like performance). Otherwise, you should try to follow them rather than disable them.

[tgolen]

Is there any reason not to use underscore here? If it's because of performance, please add a code comment explaining that.

[luacmartins]

+1

[kidroca]

Why does the function has to be defined as mergeObject = function (target, source) instead of simply function mergeObject(target, source)?

[luacmartins]

We have to do that otherwise we would use it before it's defined, since we have the following circular dependency mergeObject -> fastMerge -> mergeObject

[tgolen]

+1

[kidroca]

when 2 functions are on the same level, they are registered at the same time, it's just that eslint would flag it as a code style issue, because our code style is to define stuff before it's used - impossible to address in case of a circular dependency, but we can just disable the warning

The actual problem is with variables - you can't use a variable before it is defined, but you can use a function before it's defined, because functions are always registered before any code runs

[luacmartins]

Thanks for clarifying @kidroca. In that case, I agree that we should declare it as function mergeObject() and disable the lint warning with a comment explaining why

[luacmartins]

+1

[mountiny]

Thanks for adding the comments, looks good to me

[luacmartins]

Left a few NAB comments

[tgolen]

Sorry to keep harping on the style, but we are sticklers for consistency. Please try to follow previous patterns and our style guides https://github.com/Expensify/Style-Guides/blob/main/javascript.md

[tgolen]

Suggested change

	/**
	* Is the object Mergeable
	*
	* @param {*} val
	* @returns {*|boolean}
	*/
	/**
	* @param {mixed} val
	* @returns {mixed}
	*/

Don't include a method description unless it's valuable (and what you had there just repeats the method name). For the return value, maybe we should cast it to always return a boolean?

[mountiny]

Thanks for addressing the style changes 👍

[tgolen]

Looks great! Thank you for the changes.