This will allow us to break up the styles, so that one can have for example
button.60
checkbox.60
and finally widgets.60:
import { Button } from "button.60";
import { CheckBox } from "checkbox.60";
export { Button, CheckBox };
and then the users have to only import "widgets.60";
In commit 46ca98b159 the binding fixup was moved
to be applied later, but at that point the bindings have been
moved and aren't there (on the element) anymore, so they'd
never get fixed. This patch moves the fixup back up again.
This is the counter part of the export statement and right now it's
implemented as a dumb recursive file loader. This can be extended in
thefuture to support cycles between files (but not types), if
theresolution of types is done lazily.
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.
Don't concatenate paths as strings with directory separators, use the
variant to create from an iterator. This could also be cannonicalized,
but it's not necessary AFAICS.
Work around a problem with specifying multiple properties in property animations.
While trying to find what the problem is
and how to fix it, this patch avoids the
test failure in the CI.
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
