2022-06-28 17:25:22 -05:00
|
|
|
import { useEffect, useRef} from 'react'
|
2022-06-28 13:41:27 -05:00
|
|
|
import Svg from '../../draft/svg'
|
|
|
|
|
import Defs from '../../draft/defs'
|
|
|
|
|
import Part from './part'
|
2022-02-25 08:30:03 +01:00
|
|
|
|
2022-02-20 18:46:21 +01:00
|
|
|
const Draft = props => {
|
2022-06-28 02:02:51 -05:00
|
|
|
if (!props.gistReady) {return null}
|
2022-03-13 14:37:17 +01:00
|
|
|
const { patternProps, gist, updateGist ,app, bgProps={} } = props
|
2022-03-06 18:54:30 +01:00
|
|
|
const { layout=false } = gist
|
|
|
|
|
|
2022-06-28 15:16:29 -05:00
|
|
|
const svgRef = useRef(null);
|
|
|
|
|
|
2022-03-06 18:54:30 +01:00
|
|
|
useEffect(() => {
|
|
|
|
|
if (!layout) {
|
|
|
|
|
// On the initial draft, core does the layout, so we set the layout to the auto-layout
|
|
|
|
|
// After this, core won't handle layout anymore. It's up to the user from this point onwards
|
|
|
|
|
updateGist(['layout'], {
|
|
|
|
|
...patternProps.autoLayout,
|
|
|
|
|
width: patternProps.width,
|
|
|
|
|
height: patternProps.height
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}, [layout])
|
|
|
|
|
|
|
|
|
|
if (!patternProps || !layout) return null
|
2022-02-20 18:46:21 +01:00
|
|
|
|
feat(lab): First stab at custom layout
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.
2022-03-12 18:53:47 +01:00
|
|
|
// Helper method to update part layout and re-calculate width * height
|
|
|
|
|
const updateLayout = (name, config) => {
|
|
|
|
|
// Start creating new layout
|
2022-06-28 13:41:27 -05:00
|
|
|
const newLayout = {...layout}
|
feat(lab): First stab at custom layout
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.
2022-03-12 18:53:47 +01:00
|
|
|
newLayout.parts[name] = config
|
2022-06-28 15:16:29 -05:00
|
|
|
|
feat(lab): First stab at custom layout
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.
2022-03-12 18:53:47 +01:00
|
|
|
// Pattern topLeft and bottomRight
|
2022-06-28 15:16:29 -05:00
|
|
|
let topLeft = {x: 0, y: 0}
|
|
|
|
|
let bottomRight = {x: 0, y: 0}
|
feat(lab): First stab at custom layout
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.
2022-03-12 18:53:47 +01:00
|
|
|
for (const [pname, part] of Object.entries(patternProps.parts)) {
|
2022-06-28 15:16:29 -05:00
|
|
|
let partLayout = newLayout.parts[pname];
|
feat(lab): First stab at custom layout
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.
2022-03-12 18:53:47 +01:00
|
|
|
// Pages part does not have its topLeft and bottomRight set by core since it's added post-draft
|
2022-06-28 15:16:29 -05:00
|
|
|
if (partLayout.tl) {
|
|
|
|
|
// set the pattern extremes
|
|
|
|
|
topLeft.x = Math.min(topLeft.x, partLayout.tl.x)
|
|
|
|
|
topLeft.y = Math.min(topLeft.y, partLayout.tl.y)
|
|
|
|
|
bottomRight.x = Math.max(bottomRight.x, partLayout.br.x)
|
|
|
|
|
bottomRight.y = Math.max(bottomRight.y, partLayout.br.y);
|
feat(lab): First stab at custom layout
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.
2022-03-12 18:53:47 +01:00
|
|
|
}
|
|
|
|
|
}
|
2022-06-28 15:16:29 -05:00
|
|
|
|
feat(lab): First stab at custom layout
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.
2022-03-12 18:53:47 +01:00
|
|
|
newLayout.width = bottomRight.x - topLeft.x
|
|
|
|
|
newLayout.height = bottomRight.y - topLeft.y
|
2022-06-28 15:16:29 -05:00
|
|
|
newLayout.bottomRight = bottomRight
|
|
|
|
|
newLayout.topLeft = topLeft
|
feat(lab): First stab at custom layout
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.
2022-03-12 18:53:47 +01:00
|
|
|
updateGist(['layout'], newLayout)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2022-03-06 18:54:30 +01:00
|
|
|
// We need to make sure the `pages` part is at the bottom of the pile
|
|
|
|
|
// so we can drag-drop all parts on top of it.
|
|
|
|
|
// Bottom in SVG means we need to draw it first
|
|
|
|
|
const partList = Object.keys(patternProps.parts)
|
2022-02-25 08:30:03 +01:00
|
|
|
|
2022-02-20 18:46:21 +01:00
|
|
|
return (
|
2022-03-06 18:54:30 +01:00
|
|
|
<div className="my-8 w-11/12 m-auto border-2 border-dotted border-base-content shadow">
|
2022-06-29 13:36:41 +02:00
|
|
|
<Svg {...patternProps}
|
|
|
|
|
embed={gist.embed}
|
|
|
|
|
ref={svgRef}
|
|
|
|
|
viewBox={layout.topLeft ? `${layout.topLeft.x} ${layout.topLeft.y} ${layout.width} ${layout.height}` : false}
|
|
|
|
|
style={{maxHeight: '100vh'}}
|
|
|
|
|
>
|
2022-02-20 18:46:21 +01:00
|
|
|
<Defs {...patternProps} />
|
|
|
|
|
<style>{`:root { --pattern-scale: ${gist.scale || 1}}`}</style>
|
|
|
|
|
<g>
|
|
|
|
|
<rect x="0" y="0" width={patternProps.width} height={patternProps.height} {...bgProps} />
|
2022-03-06 18:54:30 +01:00
|
|
|
{[
|
|
|
|
|
partList.filter(name => name === 'pages'),
|
|
|
|
|
partList.filter(name => name !== 'pages'),
|
|
|
|
|
].map(list => list.map(name => (
|
|
|
|
|
<Part {...{
|
|
|
|
|
key:name,
|
2022-07-11 21:00:08 -05:00
|
|
|
partName: name,
|
2022-03-06 18:54:30 +01:00
|
|
|
part: patternProps.parts[name],
|
|
|
|
|
layout,
|
|
|
|
|
app,
|
|
|
|
|
gist,
|
feat(lab): First stab at custom layout
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.
2022-03-12 18:53:47 +01:00
|
|
|
updateLayout,
|
2022-03-06 18:54:30 +01:00
|
|
|
}}/>
|
|
|
|
|
)))}
|
2022-02-20 18:46:21 +01:00
|
|
|
</g>
|
|
|
|
|
</Svg>
|
|
|
|
|
</div>
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
export default Draft
|
|
|
|
|
|