You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If storing custom shape data as Geometry2d you will most likely need to render this out at some point. You can see a lot of this custom rendering happening internally already (examples below for brevity). I would suggest adding an abstract method to Geometry2d such as toSvg(shape: Geometry2d, props?: SVGProps<SVGSVGElement>): JSX.Element. By using props that would allow passing common attributes to customise such as color, stroke-width, etc.
External Usage
By exposing such a function as toSvg() to developers it will give them the option to define their geometry using the Geometry2d classes and easily render them. Of course, some developers may have much more custom use cases, but this provides a standard baseline for someone to start with.
I'm not exactly sure what the plans are for Geometry2d other than for basic debugging, indicators, and path collision checking, but adding this as a potential use case seems like a win to me.
Internal Cleanup
Some of this rendering functionality already exists in some of the internal Geo shapes. These are all using different approaches to create the path strings but are ultimately resulting in the same output. By centralising this in a single place it could help clean this up a bit (and also make it much easier to add additional shapes in the future, either internally or by 3rd-party devs).
There could be some difficulty for the drawn styles as some jitter is applied to those paths.
There are a few other places as well but I figure this gives enough examples
Implementation
There are a few different ways I could see implementing this (although if this is something that wants to be investigated I would love to hear feedback!):
Using a single <path d="complex path data here" /> and returning that from the function
Using any relevant SVG elements such as rect, ellipse, polyline, etc. Some of the more complex Geometry2d classes (such as Stadium2d) may need to fall back to a custom <path /> element. This would return the relevant path for each.
Barriers to implementation
Looking at Arc2d as an example, using an elliptical arc curve we would need attributes such as large-arc-flagsweep-flag which as indeed used in the constructor of Arc2d, but aren't saved internally. This might need to be saved to help with rendering the relevant SVG element.
Additional notes
I would be happy to help out with a PR if desired with the guidance of the team.
What's the feature?
If storing custom shape data as
Geometry2d
you will most likely need to render this out at some point. You can see a lot of this custom rendering happening internally already (examples below for brevity). I would suggest adding an abstract method toGeometry2d
such astoSvg(shape: Geometry2d, props?: SVGProps<SVGSVGElement>): JSX.Element
. By usingprops
that would allow passing common attributes to customise such ascolor
,stroke-width
, etc.External Usage
By exposing such a function as
toSvg()
to developers it will give them the option to define their geometry using theGeometry2d
classes and easily render them. Of course, some developers may have much more custom use cases, but this provides a standard baseline for someone to start with.I'm not exactly sure what the plans are for
Geometry2d
other than for basic debugging, indicators, and path collision checking, but adding this as a potential use case seems like a win to me.Internal Cleanup
Some of this rendering functionality already exists in some of the internal Geo shapes. These are all using different approaches to create the path strings but are ultimately resulting in the same output. By centralising this in a single place it could help clean this up a bit (and also make it much easier to add additional shapes in the future, either internally or by 3rd-party devs).
There could be some difficulty for the drawn styles as some jitter is applied to those paths.
tldraw/packages/tldraw/src/lib/shapes/geo/cloudOutline.ts
Line 265 in 40aeeba
tldraw/packages/tldraw/src/lib/shapes/geo/components/SolidStyleEllipse.tsx
Line 23 in 40aeeba
tldraw/packages/tldraw/src/lib/shapes/geo/components/SolidStyleOval.tsx
Line 60 in 40aeeba
tldraw/packages/tldraw/src/lib/shapes/geo/components/SolidStylePolygon.tsx
Line 22 in 40aeeba
tldraw/packages/tldraw/src/lib/shapes/geo/components/DashStyleCloud.tsx
Lines 63 to 64 in 40aeeba
tldraw/packages/tldraw/src/lib/shapes/geo/components/DashStyleEllipse.tsx
Line 46 in 40aeeba
tldraw/packages/tldraw/src/lib/shapes/geo/components/DashStylePolygon.tsx
Line 24 in 40aeeba
tldraw/packages/tldraw/src/lib/shapes/geo/cloudOutline.ts
Line 301 in 40aeeba
https://github.com/tldraw/tldraw/blob/main/packages/tldraw/src/lib/shapes/geo/components/DrawStylePolygon.tsx#L30
There are a few other places as well but I figure this gives enough examples
Implementation
There are a few different ways I could see implementing this (although if this is something that wants to be investigated I would love to hear feedback!):
<path d="complex path data here" />
and returning that from the functionrect
,ellipse
,polyline
, etc. Some of the more complexGeometry2d
classes (such asStadium2d
) may need to fall back to a custom<path />
element. This would return the relevant path for each.Barriers to implementation
Looking at
Arc2d
as an example, using an elliptical arc curve we would need attributes such aslarge-arc-flag
sweep-flag
which as indeed used in the constructor ofArc2d
, but aren't saved internally. This might need to be saved to help with rendering the relevant SVG element.Additional notes
I would be happy to help out with a PR if desired with the guidance of the team.
May impact/be impacted by #3020
Hope this makes sense and thank you all for an awesome project!
Contact Details
tldraw Discord: lorenzolewis
Code of Conduct
The text was updated successfully, but these errors were encountered: