Hi,
I'm still not using modules. I left that for now until we complete the
first phase in our project, but will be using (hopefully) around February.
So right now we're only using minification, that seems not only to reduce
the size of the build, but release mode performs faster, and I think is
due, in part, to minify.
So, IMHO, as a user, I don't like A). Can't think of a solution, since is
not my zone of expertise, and sure you guys found a good solution after
all. Just want to say that as a user, is importante both things: have
modules (and hope we could link as well with routing like people do in
other current techs like React and Angular to get a powerful solution for
SPAs) and have minification, since IMO, the resultant js-release build has
many, many advantages, not only in performance and size but as well in
obfuscation, and for me is like our "binary output code".
Sorry to not be able to give any suggestion, but maybe as well an opinion
of use is as well valuable.
just my 2
El mar., 11 dic. 2018 a las 21:24, Alex Harui (<aha...@adobe.com.invalid>)
escribió:
> Thinking about it more, -js-dynamic-access probably won't help. We don't
> want to compile our SWCs with that option on and thus turn off minification
> of these field names always if we can help it.
>
> Even a directive per occurrence won't help either. Whether a field name
> is renamed is still dependent on what other code is in the compilation.
>
> The problem is better described as trying to find a way to control what
> field names get renamed in more than one compilation, given that there is
> pre-transpiled code that allows renaming. When building modules, we
> already require using Closure Compiler options that output the renaming
> maps of the main app so that UIBase is given the same short name in all
> minifications. But there is no way to dictate that for field names as far
> as I can tell.
>
> -Alex
>
> On 12/11/18, 11:32 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
> I vote for A.
>
> We can also do B which would require manually changing all access to
> brackets and quote all names in object literals.
>
> I might be nice to add some comment decorations to enable/disable
> -js-dynamic-access on a case-by-case basis, but I think it’s reasonable to
> have a global on/off requirement. I’m already doing this for a library I
> wrote which has a lot of dynamic data structures which does not survive
> minification and the results are fine.
>
> My $0.02,
> Harbs
>
> > On Dec 11, 2018, at 8:47 PM, Alex Harui <aha...@adobe.com.INVALID>
> wrote:
> >
> > IMO, some folks will want to rely on minification of object field
> names so save space. I think -js-dynamic-access blocks minification.
> >
> > So, to try to pose the problem another way, you can rely on
> minification object field names if you are building a single-js-file app,
> but as soon as you start using modules, things may break. So what should
> we tell folks?
> >
> > A) if you use modules you must turn off minification in objects with
> -js-dynamic-access
> > B) here are some ways to hack your code so you can still rely on
> minification
> > C) something else?
> >
> > We can manually rename fields in ROYALE_CLASS_INFO and other
> structures to make our code less readable in debug mode but save space in
> release mode, but that does not solve the general case problem. Folks may
> have other objects in their apps and modules that work until you add some
> code to one of the projects that changes which object fields get renamed.
> >
> > -Alex
> >
> > On 12/11/18, 9:31 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >
> > I’m not following why this is the same point.
> >
> > I’m using -js-dynamic-access-unknown-members=true to handle this
> kind of problem. It works flawlessly…
> >
> > I’d personally argue that true should be the default, but whether
> the default is true or not, we do have an option to deal with these kinds
> of data structures.
> >
> >> On Dec 11, 2018, at 6:39 PM, Alex Harui <aha...@adobe.com.INVALID>
> wrote:
> >>
> >> Yes, we can use our own short names in code we generate, but that's
> not really the point.
> >>
> >> The point is that any plain object field can be renamed based on
> other code in the compile. So if you just have:
> >>
> >> Var obj:Object = { harbs: 1};
> >> Public static function foo()
> >> {
> >> Trace(obj.harbs);
> >> }
> >>
> >> Use of foo() in one compile may result in harbs being renamed, and
> another wouldn't. And that poses a problem when data structures are shared
> between compiled outputs.
> >>
> >> This is a natural way to write AS, but the JS results when minified
> and shared between app and modules can fail. So what restrictions should
> we place if any on how folks use plain objects?
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 12/11/18, 7:36 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>
> >> I was about to make the same suggestion. We can use “I” for
> interfaces, “c” for class, “k” for kind, “n” for names. etc.
> >>
> >>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew <andrew.fr...@harman.com>
> wrote:
> >>>
> >>> Hi
> >>>
> >>> Not sure that I fully understand this but would a valid compromise
> be something where the field name isn't renamed at all automatically, but
> we just change it in the JS generation code to be "i" rather than
> "interfaces", and update the Language is/as functions to work with this
> property name? Not sure whether it would work and I don't know whether the
> Reflection stuff would then need to change too, but if this is all in the
> generated outputs and/or the framework's own code then it shouldn't be
> something that the end user would bother about..
> >>>
> >>> thanks
> >>>
> >>> Andrew
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Alex Harui [mailto:aha...@adobe.com.INVALID]
> >>> Sent: 11 December 2018 08:32
> >>> To: dev@royale.apache.org
> >>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
> >>>
> >>> I spent some time today trying to get Tour De Flex to run in
> production mode with the main app and modules being separately minified.
> >>>
> >>> I've fixed a few things here and there, but an interesting issue I
> ran into has to do with the plain object we use in ROYALE_CLASS_INFO (and
> will apply to other objects).
> >>>
> >>> The ROYALE_CLASS_INFO is generated on each class and has a "names"
> property and an optional "interfaces" property. An example is:
> >>>
> >>>
> org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO
> = { names: [{ name: 'PanelModel', qName:
> 'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }],
> interfaces: [org.apache.royale.core.IBead,
> org.apache.royale.core.IPanelModel] };
> >>>
> >>> Because the field names are not quoted, then in most output, the
> field name "interfaces" is renamed and all code referencing this field is
> renamed as well. This is good because it means that you don't have to
> download the word "interfaces" once per-class. Instead of 10 characters, it
> is usually one or two. 100 classes saves you about 900 bytes.
> >>>
> >>> However, it turns out that in Tour De Flex, the main app uses
> Reflection and Reflection uses a quoted 'interfaces' string and thus, the
> field name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most
> modules "interfaces" is renamed since no other code in the module has a
> quoted string for 'interfaces'. But that means that when a module loads,
> the Language.is/as won't work since classes in the main app are using
> "interfaces" but the classes in the module are using some short name.
> >>>
> >>> One solution is to always quote that field in the compiler output
> and Language is/as so it doesn't get renamed, but that means that field
> will never get renamed and you lose saving those bytes.
> >>>
> >>> Another is let folks figure out their own workarounds, by adding
> some code that will prevent the renaming in the modules.
> >>>
> >>> Other ideas are welcome. I'm done for tonight.
> >>>
> >>> Thoughts?
> >>> -Alex
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
