Related:
On this page:
http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/RoyaleDocs_Staging/lastSuccessfulBuild/artifact/_site/create-an-application/application-tutorial/data.html
<http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/RoyaleDocs_Staging/lastSuccessfulBuild/artifact/_site/create-an-application/application-tutorial/data.html>
Shouldn’t the following code have trouble with minification?
{
repos = configurator.json.repos;
projectName = configurator.json.projectName;
}
What’s preventing json.repos and json.projectName from being renamed?
> 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?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
