I just compiled with the new option and it appears to work. Yay. On the other
hand, only functions and variables are being minified. getters and setters
(which is a very large percentage of the signature of my code) is not.
It looks like that adds the @exports for non-mxml files as well. Can we output
the @exports for only MXML declared variables?
If a comment with @export is added in AS code, will that be passed through to
the JS output?
If yes, I think @exporting ids declared in MXML should be the only case we
need. I can probably handle any specific cases where that might break output
code by manually inserting @export statements.
> On Aug 9, 2017, at 10:20 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> Hmm. I thought GCC didn't rename those. Anyway, I added back the
> @export. See if that works for you and then see if you think there is
> enough obfuscation.
>
> Thanks,
> -Alex
>
> On 8/9/17, 12:45 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> The problem is as follows:
>>
>> Taking textInput as an example, the MXML gets compiled into the following:
>> textInput: {
>> /** @this {com.printui.view.components.PaletteSlider} */
>> get: function() {
>> return this.textInput_;
>> },
>> /** @this {com.printui.view.components.PaletteSlider} */
>> set: function(value) {
>> if (value != this.textInput_) {
>> this.textInput_ = value;
>>
>> this.dispatchEvent(org.apache.flex.events.ValueChangeEvent.createUpdateEve
>> nt(this, 'textInput', null, value));
>> }
>> }
>> },
>>
>> which gets minified to this:
>>
>> yw:{get:r('Nja'),set:function(a){a!=this.Nja&&(this.Nja=a,this.dispatchEve
>> nt(yR(this,iI,null,a)))}}
>>
>> goog has no way of knowing that the original textInput property name is
>> used anywhere so all references to textInput are changed to yw.
>>
>> I think the solution to this is to add @export tags to the
>> Object.defineProperty specification for any property that’s declared or
>> used in the MXML.
>>
>> If localId is used, there might be another option which would be to
>> rename the id to some value that’s one or two characters long. I’m pretty
>> sure that goog will not rename really short property names like that. (We
>> can’t do that for id because it might be used by CSS.)
>>
>> Harbs
>>
>>> On Aug 9, 2017, at 10:25 AM, Harbs <harbs.li...@gmail.com> wrote:
>>>
>>> Here’s a problem I ran into:
>>>
>>> I have a component which has the following:
>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.ap
>>> ache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7Cfa7b
>>> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaamWRAc
>>> t5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.a
>>> pache.org%2FcN1T&data=02%7C01%7C%7C5b5c51c82fc94c95d9d408d4defa99bb%7Cfa7
>>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636378615292281524&sdata=FPaamWRA
>>> ct5HAYakAZnFzT8biHOT%2F%2F0%2BCFlY32%2BvZtg%3D&reserved=0>
>>>
>>> In the script block I have references to disableBead, textInput, etc.
>>>
>>> The instance correctly has properties of disableBead, textInput, etc.,
>>> but every reference to these properties is renamed.
>>>
>>> textInput.addEventListener
>>> becomes:
>>> this.yw.addEventListener
>>>
>>> disableBead.disabled
>>> becomes
>>> this.Jm.disabled
>>>
>>> etc.
>>>
>>> this.yw and this.Jm are both undefined
>>>
>>>> On Aug 9, 2017, at 9:10 AM, Harbs <harbs.li...@gmail.com
>>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>
>>>> I’ll give it a go and see.
>>>>
>>>>> On Aug 9, 2017, at 8:31 AM, Alex Harui <aha...@adobe.com.INVALID
>>>>> <mailto:aha...@adobe.com.INVALID>> wrote:
>>>>>
>>>>> I don't think getters and setters get renamed because they are keys
>>>>> in the
>>>>> Object.defineProperties data structure. I'm wondering if that will be
>>>>> enough obfuscation for you or not.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 8/8/17, 10:22 PM, "Harbs" <harbs.li...@gmail.com
>>>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>>
>>>>>> I have a custom component “A” which implements a DisabledBead in
>>>>>> ActionScript. It has a getter called “enabled”.
>>>>>>
>>>>>> I have another MXML file “B” which uses the component and specifies
>>>>>> enabled=“false”.
>>>>>>
>>>>>> I’m assuming the “enabled” property in “A” will be renamed without an
>>>>>> @export.
>>>>>>
>>>>>> The mxml in “B” will still be using a string for the property name
>>>>>> which
>>>>>> will be “enabled” that will be undefined.
>>>>>>
>>>>>>> On Aug 9, 2017, at 7:55 AM, Alex Harui <aha...@adobe.com.INVALID
>>>>>>> <mailto:aha...@adobe.com.INVALID>> wrote:
>>>>>>>
>>>>>>> I just tried DataBindingExample. MyInitialView is essentially a
>>>>>>> custom
>>>>>>> component. What are you thinking won't work?
>>>>>>>
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 8/8/17, 2:30 PM, "Harbs" <harbs.li...@gmail.com
>>>>>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>>>>
>>>>>>>> Did you try MXML with custom components? I’m not sure I understand
>>>>>>>> how
>>>>>>>> that would work.
>>>>>>>>
>>>>>>>>> On Aug 9, 2017, at 12:01 AM, Alex Harui <aha...@adobe.com.INVALID
>>>>>>>>> <mailto:aha...@adobe.com.INVALID>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Some things I found were that MXML isn't a problem because the id
>>>>>>>>> maps
>>>>>>>>> to
>>>>>>>>> a getter/setter which maps to Object.DefineProperty which takes an
>>>>>>>>> object
>>>>>>>>> structure where the ids are keys so they don't get renamed.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
