test verifying altered order won't trigger config changes

[robertohuertasm]

Related to #1072.

If we introduce the proposed change then order alterations will trigger change detection. That's why intersectionWith was being used. I've added the test so we won't miss this next time.

[codecov]

Codecov Report

Merging #1075 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff           @@
##           master   #1075   +/-   ##
======================================
  Coverage     100%    100%           
======================================
  Files          48      48           
  Lines        2256    2264    +8     
  Branches      109     109           
======================================
+ Hits         2256    2264    +8

Impacted Files	Coverage Δ
test/init/applyCustomizationsManager.test.ts	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 32923dc...a121f29. Read the comment docs.

[JimiC]

I believe there is no need to stringify and parse here.

[robertohuertasm]

You're right. I just copied the line like a fool! 😂

[JimiC]

The function signature dictates oldConfig, newConfig, fn. You need to revert the order of the first two parameters.

[robertohuertasm]

done

[JimiC]

Why do I have the feeling that

 userConfig.associations.files = [
          { icon: "js", extensions: ["myExt1", "myExt2.custom.js"], format: "svg" },
          { icon: "js2", extensions: ["myExt1", "myExt2.custom.js"], format: "svg" },
        ];
        const initConfig = { ...userConfig, associations: { ...userConfig.associations } };
        initConfig.associations.files = [...userConfig.associations.files];
        userConfig.associations.files.reverse();

can be written as

userConfig.associations.files = [
          { icon: "js", extensions: ["myExt1", "myExt2.custom.js"], format: "svg" },
          { icon: "js2", extensions: ["myExt1", "myExt2.custom.js"], format: "svg" },
        ];
        const newConfig = { ...userConfig };
        newConfig.associations.files.reverse();

or will it reverse also the userConfig.associations.files?

[robertohuertasm]

Yes, it will keep the same references so you cannot do that.

[JimiC]

So { ...userConfig } is a ref copy instead of cloning.

[robertohuertasm]

You're right.

[JimiC]

I just remembered why I did stringify and parse. It's the vanilla js for cloning.

[robertohuertasm]

I also use this for cloning huge objects.

[JimiC]

So the test can be written as

        userConfig.associations.files = [
          { icon: "js", extensions: ["myExt1", "myExt2.custom.js"], format: "svg" },
          { icon: "js2", extensions: ["myExt1", "myExt2.custom.js"], format: "svg" },
        ];
        const initConfig = JSON.parse(JSON.stringify(userConfig));
        userConfig.associations.files.reverse();
        manageApplyCustomizations(initConfig, userConfig, spy);

to keep uniformity with the others.

[robertohuertasm]

I've already added it...

To be honest, I favor the new syntax over the JSON.parse trick. I only clone like this when I really need to clone the whole object which in this case... could make sense 😉 but I stick to the new ways when only having to modify a single property.

I leave it up to you if you want to include the change in #1074.

[JimiC]

The thing is that with stringify-parse you achieve the same result with fewer code lines which fall into my coding guidelines (we have already discussed this in another case). I think I'm gonna make the change.