I started on this. I was doing two things:
1. I added a visible check to only trigger layout if visible is true. There are
very few places this is needed. It’s not a lot of extra code.
2. I started adding “show” event listeners. During the process I noticed there
is already a “LayoutOnShow”
I’m looking at the Express components for the first time, and I have some
observations/questions.
1. Container adds a ScrollingViewport bead. I was kind of expecting the bead to
be added via CSS so it could be overridden in an app. What is an express app
client supposed to do if they don’t
I’m getting close to the release of my app and I’m starting to think about some
things related.
I would like to have the option for minified code to have package, class and
members renamed at compile time. I have two reasons for this:
1. Obfuscation. As it stands, it’s pretty easy to take
It might be more interesting and fruitful to investigate removing @export
annotations. How could we determine which variables are being accessed
via foo[someProperty] and only keep @export on those properties?
You might be able to use a text replacement tool to remove @export and
mess around
I’m fuzzy on all the reasons for using @import so much.
We’ve had discussions on the topic, but hey were spread out.
The reasons that stick in my mind was for bracketed access (needed for
binding?) and reflection. Another reason I think that was mentioned was for
modules (which we don't’ yet
The problem with even the simple check for visible is that it will run for
every container, but you might have dozens of containers that are never
ever made invisible.
A brute force alternative is different set of layouts that check for
visible.
A fancier alternative would be a bead that wraps a
>The bead is probably more PAYG, but it’s also more “pay” when you do go.
>Changing bead >notifications would probably make it cheaper though.
That’s a major point in my opinion. If we knew the cost of dispatching a
notification was next to nothing we would be able to provide lots of hooks,
