Note that there's no impact on tests, as we don't have tests for SVG support.
There is a potential minor problem with this approach - it may be acceptable, but seems a bit wrong, we're now treating all SVG properties as string types, which isn't quite right.
For example, the width and height properties might be computed as a number, which means this test will fail - which effectively means that all numeric SVG properties initialized with numbers will be converted to strings and updated with every call to patch, because the type has "changed", even if the value has not; since the comparison is !==.
Applies this change from Hyperapp.
Closes #80
Note that there's no impact on tests, as we don't have tests for SVG support.
There is a potential minor problem with this approach - it may be acceptable, but seems a bit wrong, we're now treating all SVG properties as
string
types, which isn't quite right.For example, the
width
andheight
properties might be computed as anumber
, which means this test will fail - which effectively means that all numeric SVG properties initialized with numbers will be converted to strings and updated with every call topatch
, because the type has "changed", even if the value has not; since the comparison is!==
.If you're okay with that, this PR is probably ok.