This adds a React component to handle custom layouts.
This React component is a long way from perfect, but it's a start.
There are two reasons that (at least in my opinion) implementing this is non-trivial:
1) React re-render vs DOM updates
For performance reasons, we can't re-render with React when the user drags a
pattern part (or rotates it). It would kill performance.
So, we don't re-render with React upon dragging/rotating, but instead manipulate
the DOM directly.
So far so good, but of course we don't want a pattern that's only correctly laid
out in the DOM. We want to updat the pattern gist so that the new layout is stored.
For this, we re-render with React on the end of the drag (or rotate).
Handling this balance between DOM updates and React re-renders is a first contributing
factor to why this component is non-trivial
2) SVG vs DOM coordinates
When we drag or rotate with the mouse, all the events are giving us coordinates of
where the mouse is in the DOM.
The layout uses coordinates from the embedded SVG which are completely different.
So we need to make this translation and that adds complexity.
3) Part-level transforms
It's not just that the DOM coordinates and SVG coordinate system is different, each
part also has it's own transforms applied and because of this behaves as if they have
their own coordinate system.
In other words, a point (0,0) in the part is not the top-left corner of the page.
In the best-case scenario, it's the top-left corner of the part. But even this is
often not the case as parts will have transforms applied to them.
4) Flip along X or Y axis
Parts can be flipped along the X or Y axis to facilitate a custom layout.
This is handled in a transform, so the part's coordinate's don't actually change. They
are flipped late into the rendering process (by the browser displaying the SVG).
Handling this adds yet more mental overhead
5) Bounding box
While moving and rotating parts around is one thing. Recalculating the bounding box
(think auto-cropping the pattern) gets kinda complicated because of the reasons
outlined above.
We are currently handling a lot in the frontend code. It might be more elegant to move
some of this to core. For example, core expects the custom layout to set the widht and height
rather than figuring it out on its own as it does for auto-generated layouts.
Known issues
- Rotating gets a little weird sometimes as the part rotates around it's center in the
SVG coordinate system, but the mouse uses it's own coordinates as the center point that's
used to calculate the angle of the rotation
- Moving parts into the negative space (minus X or Y coordinated) does not extend the bounding box.
- Rotation gets weird when a part is mirrored
- The bounding box update when a part is rotated is not entirely accurate
I've sort of left it at this because I'm starting to wonder if we should perhaps re-think
how custom layouts are supported in the core. And I would like to discuss this with the core team.
