Quite sure. In my angular app I was using an older version of the closure compiler to minify the js files. I was using the default options which clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals didn’t get renamed.
I think most modern app frameworks use other tools such as Babel for magnification, but I believe that handles object literals correctly too. We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing object literals. I’m proposing a compiler *option* to allow to continue using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which should not be renamed. Harbs > On Feb 6, 2018, at 9:38 AM, Alex Harui <[email protected]> wrote: > > Are you sure Angular and React minify your code instead of running it > against their minified framework? > > -Alex > > On 2/5/18, 11:22 PM, "Gabe Harbs" <[email protected]> wrote: > >>> Maybe I'm missing something. I don't think Royale has any extra >>> problems >>> with JSON objects than other JS Frameworks have. If you want to minify, >>> you have to use brackets and strings. >> >> It does. >> >> I’ve written angular apps and I’ve never had to worry about using bracket >> notation for minifying simple js objects. I’m pretty sure the same is for >> React, etc. >> >>> On Feb 5, 2018, at 11:34 PM, Alex Harui <[email protected]> >>> wrote: >>> >>> Maybe I'm missing something. I don't think Royale has any extra >>> problems >>> with JSON objects than other JS Frameworks have. If you want to minify, >>> you have to use brackets and strings. If you don't want to minify, then >>> you don't need to worry about that. Am I wrong about that? >>> >>> >>> JSON has something like a "reviver". Has anyone played with that to see >>> if it can be used to convert straight to VO's? >>> >>> Thanks, >>> -Alex >>> >>> On 2/5/18, 1:08 PM, "Gabe Harbs" <[email protected]> wrote: >>> >>>> An additional point: >>>> >>>> How do you propose handling json that’s multiple levels deep? Walk the >>>> json and construct VOs on each level? That seems to me just as bad as >>>> the >>>> problem. Imagine you just want foo.baz.thingy.uid? You’d need to >>>> create a >>>> VO of foo, baz and thingy or be forced to use >>>> foo[“baz”][“thingy”][“uid”]. Of course the average user is not going to >>>> remember to do that until their release build doesn’t work… >>>> >>>> Creating VOs means you can’t simply use JSON.parse(). You’d need your >>>> own >>>> parser for each type of json you’re consuming. OK. Maybe not full >>>> parsing, but the constructors for these VOs will get pretty messy — >>>> especially if the structure is a bit fluid. >>>> >>>> Harbs >>>> >>>> >>>>> On Feb 5, 2018, at 10:36 PM, Gabe Harbs <[email protected]> wrote: >>>>> >>>>> In theory, everything you say is true. It might even be good practice. >>>>> >>>>> I’m telling you that this was a pain point when migrating my app. >>>>> Simply declaring types as VOs didn't solve the problem for me. The way >>>>> I’ve found that’s needed to solve the problem was passing the object >>>>> literal into a VO constructor and declaring the variables using >>>>> bracketed access. I was likely going about it wrong, but it was easier >>>>> to just go with the bracketed literals. >>>>> >>>>> Again: Suggesting using VOs (if we can figure out easy instructions to >>>>> do so) is probably a good idea and better recommended practice, but >>>>> people live on the edge using other JS frameworks, and I’d rather not >>>>> make it harder than it needs to be if they do want to use untyped >>>>> object >>>>> literals. >>>>> >>>>> Harbs >>>>> >>>>>> On Feb 5, 2018, at 8:01 PM, Alex Harui <[email protected]> >>>>>> wrote: >>>>>> >>>>>> It was great to skip type-checking in Flash at times, but the runtime >>>>>> was >>>>>> also strongly typed. Also, JS was not a practical language for >>>>>> Flash. >>>>>> It >>>>>> is more risky to do skip type-checking in Royale for JS. These new >>>>>> cars >>>>>> with lane warnings are a rough analogy. They only let you be less >>>>>> attentive on nice new painted highways. Flash's runtime wouldn't let >>>>>> you >>>>>> make type mismatches so it effectively had lane lines. JS is a road >>>>>> without lane lines. A ValueObject keeps your eyes on the road. An >>>>>> ounce >>>>>> of prevention is better than a pound of cure. >>>>>> >>>>>> IMO, you might be better off writing a bead that you can pass a JSON >>>>>> object and it will generate the AS class for you to copy from the >>>>>> clipboard and paste into a file. Then you could guess at the types. >>>>>> That >>>>>> wouldn't require compiler changes and would encourage early >>>>>> prevention. >>>>>> >>>>>> Just an idea, >>>>>> -Alex >>>>>> >>>>>> On 2/5/18, 9:39 AM, "Gabe Harbs" <[email protected]> wrote: >>>>>> >>>>>>> Yeah. That’s what you’ve argued in the past, and in a pure world >>>>>>> you’d be >>>>>>> right. >>>>>>> >>>>>>> However, I’d prefer the option to be practical when dealing with >>>>>>> more >>>>>>> data types. Being forced to fiddle with properly typed objects >>>>>>> *always* >>>>>>> is too confining IMO. What I personally ended up doing when dealing >>>>>>> with >>>>>>> APIs and the like was the make sure to quote everything in my app >>>>>>> rather >>>>>>> than declare VOs even though finding all the instances were a pain. >>>>>>> >>>>>>> I think it’s pretty common for folks to use untyped objects >>>>>>> *especially* >>>>>>> when dealing with APIs in classic Flex apps. It seem overly >>>>>>> draconian >>>>>>> to >>>>>>> make that a requirement for Royale. >>>>>>> >>>>>>> Part of the attraction of ActionScript has been that it’s >>>>>>> *optionally* >>>>>>> typed. Minification in JS makes the optional typing pretty weak. >>>>>>> >>>>>>>> If you don't care about SWF support, you can quickly make >>>>>>>> ValueObjects >>>>>>>> just for the compiler. >>>>>>> >>>>>>> Quickly? I’m not sure how. >>>>>>> >>>>>>> My $0.02. >>>>>>> Harbs >>>>>>> >>>>>>>> On Feb 5, 2018, at 7:28 PM, Alex Harui <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> IMO, your proposal sort of defeats the purpose of ActionScript and >>>>>>>> Royale, >>>>>>>> which is to provide a type system at compile time. Not only should >>>>>>>> you >>>>>>>> want to address your JSON fields, but you should want to have them >>>>>>>> type-checked, and that you spelled the field name correctly. >>>>>>>> Otherwise, >>>>>>>> the compiler is going to also allow you to mistype: >>>>>>>> >>>>>>>> var name = myProps["nme"]; >>>>>>>> >>>>>>>> >>>>>>>> And there will be no errors. And similarly: >>>>>>>> >>>>>>>> var myObj:Object = { >>>>>>>> nme: "foo", >>>>>>>> age : 30.1415 >>>>>>>> } >>>>>>>> >>>>>>>> Will be allowed when it probably shouldn't. And also, you could >>>>>>>> then >>>>>>>> use >>>>>>>> myObj when you intended to use myOtherObj and nobody will know >>>>>>>> until >>>>>>>> you >>>>>>>> try to debug in JS. >>>>>>>> >>>>>>>> >>>>>>>> If you don't care about SWF support, you can quickly make >>>>>>>> ValueObjects >>>>>>>> just for the compiler. In ASDoc, the ValueObject is never >>>>>>>> instantiated. >>>>>>>> It is just like a typedef for the compiler. >>>>>>>> >>>>>>>> HTH, >>>>>>>> -Alex >>>>>>>> >>>>>>>> On 2/5/18, 8:43 AM, "Gabe Harbs" <[email protected]> wrote: >>>>>>>> >>>>>>>>>> JSON Objects are not destroyed. >>>>>>>>> >>>>>>>>> Yeah. I know, but untyped js literals are pretty much useless in >>>>>>>>> minified >>>>>>>>> Royale apps. >>>>>>>>> >>>>>>>>>> Propose a way to determine that a data structure >>>>>>>>>> is external and what the compiler should generate and implement >>>>>>>>>> it. >>>>>>>>>> IMO, >>>>>>>>>> the answer is to create ValueObjects. That is essentially >>>>>>>>>> typedefs >>>>>>>>>> and >>>>>>>>>> AFAIK, there is no way to automate typedef generation. >>>>>>>>> >>>>>>>>> I already made a suggestion once: >>>>>>>>> >>>>>>>>> For untyped Objects, the compiler could convert dot notation to >>>>>>>>> bracket >>>>>>>>> notation. >>>>>>>>> >>>>>>>>> The other half of that would be to convert all object literals to >>>>>>>>> “quoted” literals automatically. >>>>>>>>> >>>>>>>>> So if I have a function: >>>>>>>>> >>>>>>>>> function parseMyJson(json:String):Object{ >>>>>>>>> return JSON.parse(json); >>>>>>>>> } >>>>>>>>> >>>>>>>>> var myProps:Object = parseMyJson(json); >>>>>>>>> >>>>>>>>> var name:string = myProps.name; >>>>>>>>> >>>>>>>>> Would become: >>>>>>>>> >>>>>>>>> function parseMyJson(json){ >>>>>>>>> return JSON.parse(json); >>>>>>>>> } >>>>>>>>> >>>>>>>>> var myProps = parseMyJson(json); >>>>>>>>> >>>>>>>>> var name = myProps["name"]; >>>>>>>>> >>>>>>>>> And this: >>>>>>>>> var myObj:Object = { >>>>>>>>> name: "foo", >>>>>>>>> age : 30 >>>>>>>>> } >>>>>>>>> >>>>>>>>> Would become: >>>>>>>>> var myObj = { >>>>>>>>> "name": "foo", >>>>>>>>> "age" : 30 >>>>>>>>> } >>>>>>>>> >>>>>>>>> These two features would have solved almost all minification >>>>>>>>> issues >>>>>>>>> I’ve >>>>>>>>> run into. >>>>>>>>> >>>>>>>>> I’d love to work on this myself, but I’m still not up to making >>>>>>>>> any >>>>>>>>> major >>>>>>>>> changes to the compiler… :-( >>>>>>>>> >>>>>>>>>> On Feb 5, 2018, at 6:13 PM, Alex Harui <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> I’ll try to work on this. It’s pretty slow loading the debug >>>>>>>>>>> build. >>>>>>>>>>> >>>>>>>>>>> I still maintain there should be a compiler setting or language >>>>>>>>>>> feature >>>>>>>>>>> to prevent objects produced from JSON being destroyed on >>>>>>>>>>> minification. >>>>>>>>>> >>>>>>>>>> JSON Objects are not destroyed. The code referencing their >>>>>>>>>> fields >>>>>>>>>> by >>>>>>>>>> name >>>>>>>>>> has those names changed. Propose a way to determine that a data >>>>>>>>>> structure >>>>>>>>>> is external and what the compiler should generate and implement >>>>>>>>>> it. >>>>>>>>>> IMO, >>>>>>>>>> the answer is to create ValueObjects. That is essentially >>>>>>>>>> typedefs >>>>>>>>>> and >>>>>>>>>> AFAIK, there is no way to automate typedef generation. >>>>>>>>>> >>>>>>>>>> Also, you can turn off minification for the app as a whole. >>>>>>>>>> >>>>>>>>>> Other ideas welcome, >>>>>>>>>> -Alex >>>>>>>>>> >>>>>>>>>>> This remains a pain point for developing apps and having to >>>>>>>>>>> create >>>>>>>>>>> VOs >>>>>>>>>>> for every API is a drag. >>>>>>>>>>> >>>>>>>>>>>> On Feb 5, 2018, at 10:21 AM, Alex Harui >>>>>>>>>>>> <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Typo. I meant js-reease. >>>>>>>>>>>> >>>>>>>>>>>> Yeah, at some later point in time someone should build Value >>>>>>>>>>>> Objects >>>>>>>>>>>> for >>>>>>>>>>>> the JSON and get js-release working. Maybe after this release. >>>>>>>>>>>> I'm >>>>>>>>>>>> just >>>>>>>>>>>> trying to make the ASDoc useful. >>>>>>>>>>>> >>>>>>>>>>>> I'm going to add Events to the class detail page and anchor >>>>>>>>>>>> links >>>>>>>>>>>> from >>>>>>>>>>>> the >>>>>>>>>>>> lists to the details and maybe a simple search-for-class >>>>>>>>>>>> feature, >>>>>>>>>>>> then I >>>>>>>>>>>> think it will be time for a release. >>>>>>>>>>>> >>>>>>>>>>>> -Alex >>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 4, 2018, at 8:08 AM, Alex Harui >>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Why is bin-release not working? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you mean SWF support? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
