In some edge cases, like when splitting a path on or very close to its
start or end point, `Path.split()` will return an array in which one of
the elements is not a Path object, but rather an empty array.
That is rather combersome to check for, so this changes that behaviour
and will return null for such cases.
I've also updated the documentation to clarify this behaviour.
Fixes#6816
This also fixes a bug when a path was being split on its end point.
We're using chai-string as it provides the `equalIgnoreSpaces`
assertion which we use in our SVG tests.
However, that package does not seem to be maintained, and lists chai v4
as its peer dependency. We've moved on to chai v5 and this is causes
issues in one of our github workflows as dependencies cannot be
resolved.
So, I've extracted the assertion we need, and dropped the dependency.
The discussion in #5976 is whether `Path.join()` should use a line
segment to close any gaps in the path caused by move operations, or by
differences in the end and start points of paths being joined.
The answer is yes, that is the intended behaviour, but people who read
_join_ might expect differently.
So I have made a few changes to clarify this:
- The new `Path.combine()` method combines multiple path instances into
a single instance without making any changes to the drawing operations
- Since `Path.combine()` is variadic, I have also updated `Path.join()`
to be variadic too, since that is more consistent.
- The old way of calling `Path.join(path, bool)` is deprecated and will
log a warning. Calling `Path.join()` this way will be removed in v4.
- Related to this change is how `Path.length()` should behave when there
are gaps in the path. Currently, it skips those. So I've added a
parameter that when set to `true` will include them.
- Added documentation for `Path.combine()`
- Updated documentation for `Path.join()`
- Updated documentation for `Path.length()`
Note that the tests for Lumina are failing, but that's not related to
the chai upgrade, rather it seems these tests fail because of issues in
the design that we'll tackle later (it's a brand new design yet to be
released).
The data returned by `Pattern.getRenderProps()` was not serializable as
we were returning `this` all over the place, thereby including marcors,
log methods, cyclic object references, and so on.
This commit changes that by implementing a `.asRenderProp()` method on
all of the various objects (stack, part, path, point, snippet,
attributes, svg) and only including data that can be serialized.
In addition, we no longer include the logs in the renderProps because
they are not related to rendering the pattern.
Instead, the new method `Pattern.getLogs()` gives you the logs.