Awesome discovery!
So, I think there are benefits to having MXML result in a data structure
because it allows run-time manipulation which should turn out to be useful
in testing as well, but if you are welcome to change the data structure for
the JS side if it will result in faster startup.
While you're on the subject, there is a related problem I wondered about a
while ago. In the example, the data results are a JSON object and AS code
simply did:
value = somejsonobject.somesubobject.somefield.
This broke when minified because the JSON object's fields don't get renamed.
I just changed the example code to
value = somejsonobject["somesubobject"]["somefield"]
but that isn't my favorite thing to require of our developers/customers.
So I guess both problems involve scanning all of the code and determining
what strings need to be saved and which ones don't? Because if you try to
allow renaming of API names you have to know if:
1) folks are ever using ["apiname"] syntax to access it
2) if extern'd JS code is going to access it via "apiname".
But since we're starting from AS, seems like we might be able to know that?
Anyway, if you want to take this on, you are more than welcome.
-Alex
On 5/5/13 12:34 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
> Alex, all,
>
> In 'goog', adding @expose in the JSDoc prevents a property or method
> from being renamed in order to keep it available for calls from 'the
> outside'.
>
> In FlexJS, the MXMLData solution has (target) property names as strings.
>
> The Closure Compiler won't touch strings and it will not rename
> @expose members. A small test shows that this adds up to an 'unneeded'
> file size in the release version of the example of 6 kb. This is 6 kB
> of 26 kB (not counting the 'goog.events' contribution), a whopping
> 25%. This is not a one time hit like you get when adding another
> library functionality, this looks to be 25% of every application you
> create, however big. So, a 200 kB app is "wasting" 50 kB by not
> allowing members to be renamed.
>
> My points is (if there is any) that if we're looking to keep the
> delivery size of the compiled JS down, we might not find much benefit
> in keeping out minor, one time additions, but we might want to look at
> optimising the use of the toolchain.
>
> EdB
>
> PS. The 'small' test I did was not functional and immediate efforts to
> make it so showed some non-trivial hurdles; this is not an 'easy-fix'.
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
