ProductiveRage / Bridge.React

Bindings for Bridge.NET for React - write React applications in C#!
MIT License
74 stars 14 forks source link

Add Dom.Svg #32

Closed DanTup closed 7 years ago

DanTup commented 7 years ago

Seems like react supports Svgs:

https://jsfiddle.net/momunchu/mk0p05cp/

Currently there's no bindings for these, so we have to either use an external file (overkill for a 3-point polyline) or stick HTML in with DangerouslySetHtml.

Were these bindings scripted? If so, we can re-generate them? Or do they need to be hand-implemented?

ProductiveRage commented 7 years ago

There isn't a script to generate them. I originally did a one-off script, I think, to create the early versions of the bindings and then tweaked them. This was when there were fewer DOM factory method overloads. When more were added I think that I created another one-off script to migrate from the older overloads to the new.

Adding SVG factory methods should be fairly easy.. on the surface. The devil will be in the details - for example, what properties should an SvgAttributes class have? Should there be restrictions on what child components may be passed (I presume that it wouldn't make sense to be able to pass a Div element as an SVG child component but I guess that we need some way to provide shapes as child components*)?

* (My knowledge of the SVG facilities are quite limited so correct me if what I'm saying doesn't make sense)

ProductiveRage commented 7 years ago

While I'm not trying to say that this shouldn't be done, I think that there is a third option for a workaround; in the component that wants to draw some SVG content, you could use JavaScript to generate the SVG rather than using DangerouslySetHtml.

It would be better to come up with a good interface in Bridge.React but this might tide you over until that's done.

ProductiveRage commented 7 years ago

Have you come up with a workaround for this for now? I'm in half a mind to close the issue even though it hasn't been resolved in the ideal way (via bindings).. only because I'm not likely to do it in the near future!

DanTup commented 7 years ago

I think we're doing dangerouslySetHtml or setting the source on an img to be a data url. This isn't blocking, I thought it'd name sense to have for completeness but if you can't easily script it, it might not be worth the effort!

ProductiveRage commented 7 years ago

Let's bury for now, since I can't easily autogenerate it at the present! :) If it becomes important in the future then sure we can either try to work something out together or whoever needs it most can make a PR!