royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabe Harbs <harbs.li...@gmail.com>
Subject Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)
Date Tue, 06 Feb 2018 08:51:19 GMT
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 <aharui@adobe.com.INVALID> 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" <harbs.lists@gmail.com> 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 <aharui@adobe.com.INVALID>
>>> 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" <harbs.lists@gmail.com> 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 <harbs.lists@gmail.com>
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 <aharui@adobe.com.INVALID>
>>>>>> 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" <harbs.lists@gmail.com> 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 <aharui@adobe.com.INVALID>
>>>>>>>> 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" <harbs.lists@gmail.com>
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 <aharui@adobe.com.INVALID>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com>
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
>>>>>>>>>>>> <aharui@adobe.com.INVALID>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com>
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
>>>>>>>>>>>>>> <aharui@adobe.com.INVALID>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Mime
View raw message