2022-10-28 15:03:04 -05:00
import { useRef } from 'react'
2023-01-29 18:57:24 +01:00
import { Stack } from './stack.mjs'
2023-05-11 19:14:48 +02:00
import { SvgWrapper } from '../../pattern/svg.mjs'
import { PartInner } from '../../pattern/part.mjs'
2023-02-27 17:47:34 -06:00
import get from 'lodash.get'
2022-02-25 08:30:03 +01:00
2023-01-29 18:57:24 +01:00
export const Draft = ( props ) => {
2022-10-28 15:03:04 -05:00
const {
patternProps ,
gist ,
updateGist ,
app ,
bgProps = { } ,
fitLayoutPart = false ,
layoutType = 'printingLayout' ,
2023-03-09 08:52:28 -06:00
layoutSetType = 'forPrinting' ,
2022-10-28 15:03:04 -05:00
} = props
2022-08-14 16:50:16 -05:00
2022-10-28 15:03:04 -05:00
const svgRef = useRef ( null )
2022-08-21 10:26:35 +01:00
if ( ! patternProps ) return null
2022-08-14 16:50:16 -05:00
// keep a fresh copy of the layout because we might manipulate it without saving to the gist
2023-02-27 17:47:34 -06:00
const layoutPath = [ 'layouts' ] . concat ( layoutType )
let layout = get ( patternProps . settings [ 0 ] , layoutPath ) || {
2022-10-28 15:03:04 -05:00
... patternProps . autoLayout ,
width : patternProps . width ,
height : patternProps . height ,
}
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
2022-10-28 15:03:04 -05:00
const updateLayout = ( name , config , history = true ) => {
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
// Start creating new layout
2022-10-28 15:03:04 -05:00
const newLayout = { ... layout }
newLayout . stacks [ 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-10-28 15:03:04 -05:00
let topLeft = { x : 0 , y : 0 }
let bottomRight = { x : 0 , y : 0 }
2022-11-14 17:19:01 -06:00
for ( const pname in patternProps . stacks ) {
2022-08-09 16:16:06 -05:00
if ( pname == props . layoutPart && ! fitLayoutPart ) continue
2022-10-28 15:03:04 -05:00
let partLayout = newLayout . stacks [ pname ]
2022-08-09 16:16:06 -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
// Pages part does not have its topLeft and bottomRight set by core since it's added post-draft
2022-07-14 07:08:41 -05:00
if ( partLayout ? . tl ) {
2022-06-28 15:16:29 -05:00
// 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 )
2022-10-28 15:03:04 -05:00
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
2022-08-09 16:16:06 -05:00
if ( history ) {
2023-02-27 17:47:34 -06:00
updateGist ( layoutPath , newLayout , history )
2022-08-09 16:16:06 -05:00
} else {
2022-08-14 16:50:16 -05:00
// we don't put it in the gist if it shouldn't contribute to history because we need some of the data calculated here for rendering purposes on the initial layout, but we don't want to actually save a layout until the user manipulates it. This is what allows the layout to respond appropriately to settings changes. Once the user has starting playing with the layout, all bets are off
2022-08-09 16:16:06 -05:00
layout = newLayout
}
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-10-28 15:03:04 -05:00
const viewBox = layout . topLeft
? ` ${ layout . topLeft . x } ${ layout . topLeft . y } ${ layout . width } ${ layout . height } `
: false
2022-12-12 10:14:28 -06: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
2022-11-14 14:02:11 -06:00
const stacks = [
< PartInner
2022-12-13 11:55:50 -06:00
{ ... {
part : patternProps . parts [ 0 ] [ props . layoutPart ] ,
partName : props . layoutPart ,
gist ,
skipGrid : true ,
} }
2022-11-14 14:02:11 -06:00
key = { props . layoutPart }
/ > ,
]
2022-12-12 10:14:28 -06:00
// then make a stack component for each remaining stack
2022-10-28 15:03:04 -05:00
for ( var stackName in patternProps . stacks ) {
2022-11-14 14:02:11 -06:00
if ( stackName === props . layoutPart ) {
continue
}
2022-10-28 15:03:04 -05:00
let stack = patternProps . stacks [ stackName ]
const stackPart = (
< Stack
{ ... {
key : stackName ,
stackName ,
stack ,
layout ,
app ,
gist ,
updateLayout ,
isLayoutPart : stackName === props . layoutPart ,
2023-03-09 08:52:28 -06:00
layoutSetType : layoutSetType ,
2022-10-28 15:03:04 -05:00
} }
/ >
)
2022-11-14 14:02:11 -06:00
stacks . push ( stackPart )
2022-10-28 15:03:04 -05:00
}
2022-02-25 08:30:03 +01:00
2022-02-20 18:46:21 +01:00
return (
2022-10-28 15:03:04 -05:00
< SvgWrapper { ... { patternProps , gist , viewBox } } ref = { svgRef } >
< rect x = "0" y = "0" width = { layout . width } height = { layout . height } { ... bgProps } / >
{ stacks }
< / S v g W r a p p e r >
2022-02-20 18:46:21 +01:00
)
}
