The Rectangle element has properties for a border outline. If those are
used, then the generated code should use BorderRectangle. But if they are
not used, then we can fall back to just generating a Rectangle.
Instead of doing the SyntaxNodeWithSourceFile construction as late as
possible (in Document::from_node), we can do it as early as possible.
That'll reduce the chances of missing out the source file and prepares
for dependency loading just based on a SNWS :)
This also makes the source_file optional in the SNWS, but that's
consistent with what the diagnostics expect.
I tried passing this as a component of the file name (uri style with a query),
but nodejs wants only valid paths for
require() calls. So instead this uses simply an environment variable.
This allows specifying additional component locations. It works for
simple structs, but not yet for more complex types due to a bug yet to
be fixed :-)
Move run_passes into the library compilation function. That way the
FileDiagnostics are created by the parser, can be passed on to the library
compilation function and after that we don't need them anymore and can
replace them with future BuildDiagnostics for example.
Don't require the callers to hold on to the source code string until an
eventual diagnostics code path is hit. Instead it turns out it's
simpler to let the parser consume the source code as string, where
internally after tokenizing it can be moved into the diagnostics and
from there into the code map if needed.
There are a few places where we now clone the source code, but that's
only in cases where we also extract stuff separately (test code) or the
syntax updater.
For a .60 files the locally defined components are now stored in a separate
per-document TypeRegistry instance that falls back to the global registry
for lookups.
Always use a Pin<Rc> for the component. (This is required to support repeater
within repeater as well anyway)
Do not use the context within the binding. We can get along by simply capturing
a weak pointer to the component
When the path was constructed from events (SVG commands), then we don't really need to build an intermediate path,
neither for rendering nor for path layouting.
Use two arrays, one for events and one for coordinates. That simplifies
the code generator and the generated code, and it also provides for
a more compact memory representation.
Using the commands property we can just paste SVG paths. This makes it
much easier to write examples/demos. A good online path designer is
for example https://codepen.io/anthonydugois/pen/mewdyZ
They are represented as lyon-style path events. We can use this to
compile SVG paths ahead of time and use them
without including lyon's SVG path builder.
