Another case which seems to need exports is any property used in MXML.
It seems like the low hanging fruit would be to allow some kind of markup to
specify classes which don’t need exports.
Rewriting constants to literals is another one which should be pretty easy to
solve.
> On Aug 7, 2017, a
Dynamic access (aka square bracket access) is used in data binding, but
people use it for other things as well. The really hard case involves
"string math" where you access something like foo[someValue + "label"].
It is hard to know that "enUSLabel" and "frFRLabel" should not be renamed.
And yes,
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 re
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 with
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,
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 minif
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 want
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” bead
