fix(Canvas): invalidate _objectsToRender on stack change

[ShaMan123]

Motivation

@jiayihu found a bug

Description

We forgot to invalidate _objectsToRender on stack change

Changes

the fix itself and a test

Gist

In Action

[ShaMan123]

done

[github-actions]

Build Stats

file / KB (diff)	bundled	minified
fabric	912.673 (+0.104)	305.394 (+0.083)

[github-actions]

Coverage after merging fix-stack-invalidation into master will be

82.92%

Coverage Report

File	Stmts	Branches	Funcs	Lines	Uncovered Lines
index.node.ts	7.69%	100%	0%	14.29%	17, 20, 23, 35, 38, 41
src
ClassRegistry.ts	100%	100%	100%	100%
Collection.ts	94.71%	94.64%	86.67%	97.09%	101, 104, 207–208, 233–234
CommonMethods.ts	96.55%	87.50%	100%	100%	9
Intersection.ts	100%	100%	100%	100%
Observable.ts	87.76%	85.29%	87.50%	89.58%	134–135, 160–161, 32–33, 41, 50, 78, 89
Point.ts	100%	100%	100%	100%
Shadow.ts	98.36%	95.65%	100%	100%	178
cache.ts	97.06%	90%	100%	100%	57
config.ts	75%	66.67%	66.67%	82.76%	130, 138, 138, 138, 138, 138–140, 151–153
constants.ts	100%	100%	100%	100%
src/Pattern
Pattern.ts	92.31%	91.89%	90%	93.55%	119, 130, 139, 32, 95
src/brushes
BaseBrush.ts	100%	100%	100%	100%
CircleBrush.ts	0%	0%	0%	0%	108, 108, 108, 110, 112, 114–116, 118–121, 128–129, 13, 136, 138, 23–24, 32–36, 40–44, 51–54, 62–66, 68, 76, 76, 76, 76, 76–77, 79, 79, 79–82, 84, 92–93, 95, 97–99
PatternBrush.ts	97.06%	87.50%	100%	100%	21
PencilBrush.ts	91.06%	82.35%	100%	93.81%	122–123, 152, 152–154, 176, 176, 276, 280, 285–286, 68–69, 84–85
SprayBrush.ts	0%	0%	0%	0%	107, 107, 107, 107, 107–108, 110–111, 118–119, 121, 123–127, 136, 140–141, 141, 149, 149, 149–152, 154–157, 161–162, 164, 166–169, 17, 172, 179, 18, 180, 182, 184–185, 187, 194–195, 197–198, 20, 201, 201, 208, 208, 21, 212, 22, 22, 22–24, 28, 32, 39, 46, 53, 60, 67, 84–86, 94–96, 98–99
src/canvas
Canvas.ts	78.99%	77.35%	83.05%	79.61%	1000, 1003–1004, 1004, 1004, 1006, 1014, 1014, 1014–1016, 1016, 1016, 1023–1024, 1032–1033, 1033, 1033–1034, 1040, 1042, 1073–1075, 1078–1079, 1083–1084, 1197–1199, 1202–1203, 1276, 1395, 1517, 157, 182, 292–293, 296–300, 305, 328–329, 334–339, 359, 359, 359–360, 360, 360–361, 369, 37, 374–375, 375, 375–376, 378, 387, 393–394, 394, 394, 41, 437, 445, 449, 449, 449–450, 452, 535–536, 536, 536–537, 543, 543, 543–545, 565, 567, 567, 567–568, 568, 568, 571, 571, 571–572, 575, 584–585, 587–588, 590, 590–591, 593–594, 606–607, 607, 607–608, 610–615, 621, 628, 665, 665, 665, 667, 669–674, 680, 686, 686, 686–687, 689, 692, 697, 710, 738, 738, 796–797, 797, 797–798, 800, 803–804, 804, 804–805, 807–808, 811, 811–813, 816–817, 887, 899, 906, 906, 906, 927, 959, 980–981, 997–998, 998, 998–999
CanvasOptions.ts	100%	100%	100%	100%
SelectableCanvas.ts	94.41%	92.21%	94.23%	96.15%	1080, 1082, 1084–1085, 301, 471–472, 474–475, 475, 475, 524–525, 586–587, 640–642, 674, 679–680, 707–708, 880, 880–881, 884, 904, 904, 953, 961
StaticCanvas.ts	96.78%	93.09%	100%	98.53%	1031, 1041, 1093–1094, 1097, 1132–1133, 1209, 1218, 1218, 1222, 1222, 1269–1270, 187–188, 204, 571, 583–584, 914–915, 915, 915–916
StaticCanvasOptions.ts	100%	100%	100%	100%
TextEditingManager.ts	84.31%	71.43%	91.67%	88%	17–18, 18, 18–19, 19, 19
src/canvas/DOMManagers
CanvasDOMManager.ts	95.52%	70%	100%	100%	21–22, 29
StaticCanvasDOMManager.ts	97.50%	88.89%	100%	100%	33
util.ts	86.67%	80.56%	83.33%	93.94%	14, 26, 63–64, 67, 67, 74, 93–94
src/color
Color.ts	94.96%	91.67%	96.30%	96.05%	233, 258–259, 267–268, 48
color_map.ts	100%	100%	100%	100%
constants.ts	100%	100%	100%	100%
util.ts	85.71%	76.92%	100%	89.74%	55–56, 56, 58, 58, 58–59, 61–62, 89
src/controls
Control.ts	94.44%	93.10%	91.67%	96.77%	183, 249, 353
changeWidth.ts	100%	100%	100%	100%
commonControls.ts	100%	100%	100%	100%
controlRendering.ts	81.63%	78%	100%	84.78%	106, 111, 121, 121, 45, 50, 61, 61, 65–72, 81–82
drag.ts	100%	100%	100%	100%
fireEvent.ts	88.89%	75%	100%	100%	13
polyControl.ts	6.06%	0%	0%	11.43%	103, 117, 117, 117, 117, 117, 119–122, 122, 125, 132, 17, 25–29, 29, 29, 29, 29, 29, 29, 29, 50–56, 56, 56, 56, 56, 58, 63–64, 66, 76, 82–84, 84, 86, 89–90, 90, 90, 90, 90, 92, 97
rotate.ts	19.57%	12.50%	50%	21.43%	41, 45, 51, 51, 51–52, 55–57, 59, 59, 59, 59, 59–61, 61, 61–63, 65, 65, 65–67, 67, 67–68, 73, 73, 73–74, 76, 78, 80–81
scale.ts	93.57%	92.94%	100%	93.67%	129–130, 132–134, 148–149, 181–183, 42
scaleSkew.ts	78.79%	64.29%	100%	85.71%	27, 29, 29, 29, 31, 33, 35
skew.ts	91.03%	79.31%	100%	97.67%	131–132, 163–164, 171, 177, 179
util.ts	100%	100%	100%	100%
wrapWithFireEvent.ts	100%	100%	100%	100%
wrapWithFixedAnchor.ts	100%	100%	100%	100%
src/e

[jiayihu]

IMO this is a bad design and caching should never be implicit, rather left opt-in for the developer or even as override if needed. As a developer, I would need to dig into the source code to find out why my objects are not correctly rendered even after maybe spending hours investigating that the _objects array has been correctly modified.

[ShaMan123]

I am not sure I agree.
This is a pure bug.
As long as caching works it is great, once it doesn't it is awful to debug. You said that.
Your experience was that exactly.

[ShaMan123]

But maybe we could add a flag to renderAll

[asturur]

We set _objectsToRender as undefined most of the time when we need to invalidate,
but when the canvas start we assign it an empty array

  /**
   * hold the list of objects to render
   * @type FabricObject[]
   * @private
   */
  _objectsToRender?: FabricObject[] = [];

Why?

[ShaMan123]

Nice catch

[asturur]

Can we set it as declare there and avoid the empty array? the first render with or without objects will be created.

[ShaMan123]

Sounds the right way to it.
Also adding an assertion to the test I have added

[asturur]

IMO this is a bad design and caching should never be implicit, rather left opt-in for the developer or even as override if needed. As a developer, I would need to dig into the source code to find out why my objects are not correctly rendered even after maybe spending hours investigating that the _objects array has been correctly modified.

Regarding this i don't have an opinion about this being bad or not bad.
The change of caching the result of that calculation was added here:
#7726
as part of 'neutral group changes'
It hasn't given much thought, but as with each caching it brings complexity and possible bugs.

Regarding a developer digging hours and not understanding why what, that is the exact issue that i mention and why i m not releasing 6.0 without a full set of docs and explanations.
The code auto documenting itself is not true and people should have document available to understand how a framework works under the hood.

[ShaMan123]

I didn't add declare because there is no need for it since it is undefined by default

[ShaMan123]

applied review comments

[ShaMan123]

I think it is ok to cache this but I don't mind
We said we want less work to happen during rendering - this is part of it

[asturur]

I didn't add declare because there is no need for it since it is undefined by default

is the way it gets assigned that is unfriendly with setOptions, we can add declare another time.