We can "leave it as it was" by making SIMPLE_OPTIMIZATIONS the default. The difference between Flex and Royale is that Royale currently crunches your code through the Google Closure Compiler with ADVANCED_OPTIMIZATIONS and that messes up how you use plain objects.
IMO, there is enough to gain from using ValueObjects (code hinting, type-checking, etc) that we should promote use of them and make it really easy to use them, like creating typedefs via some utility. IOW, if it only took 5 minutes to generate ValueObjects for your JSON responses, would you just use them because it saved you time making mistakes using plain object? But if enough folks want to use plain objects in production (this is not an issue for the bin/js-debug version) I have no objection to making it work, I'm just wondering if we should just use SIMPLE_OPTIMIZATIONS since that is easy, or take the time to add another compiler option and fork the output code generators to generate different code (and write tests for all of that). Would ADVANCED_OPTIMIZATIONS plus this new option be worth it over SIMPLE_OPTIMIZATIONS? If we change our default to SIMPLE_OPTIMIZATIONS our HelloWorld will be fatter, but I don't know by how much. But that is a consideration if folks are going to care about download size. Thoughts? -Alex On 2/8/18, 1:55 PM, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> wrote: >but why to complicate this so much? I think we always had in Flex/Flash >the >opportunity to make this without any additional config. >Why not left it as it always was? > >thanks > >2018-02-08 19:48 GMT+01:00 Alex Harui <[email protected]>: > >> I'm not disagreeing. I think the question is whether we need yet another >> compiler option to generate bracket notation for objects or just ask >>folks >> to use SIMPLE_OPTIMIZATIONS. And whether we switch to >> SIMPLE_OPTIMIZATIONS by default. I can think of lots of other things to >> work on besides this new option if we have rough equivalents. >> >> -Alex >> >> On 2/8/18, 10:36 AM, "[email protected] on behalf of Carlos >>Rovira" >> <[email protected] on behalf of [email protected]> wrote: >> >> >Although I'm pro typed, I agree with Josh that we should not enforce >> >that. >> >That's one of the great points in Flash/Flex. >> >For make things quick, I use simple objects with bracket notation, when >> >the >> >application is more relevant I go the right typed path. >> >It's up to the developer decide when they want one or another. >> > >> > >> > >> >2018-02-08 18:50 GMT+01:00 Josh Tynjala <[email protected]>: >> > >> >> Nothing frustrated me more about Royale/FlexJS than the fact that I >> >> couldn't use untyped objects without bracket notation. It's a very >>bad >> >>user >> >> experience when trying to consume JSON, or even when choosing to >>create >> >>my >> >> own object literals. While it's a good best practice to create value >> >> objects, that shouldn't be forced on everyone. I frequently use >>untyped >> >> objects when prototyping because it's more convenient. They're also >> >>useful >> >> in example code to reduce boilerplate that isn't particularly >>relevant >> >>to >> >> the concept/feature that you're trying to demonstrate. And, of >>course, >> >> there's the already mentioned JSON. >> >> >> >> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS >>the >> >> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly >> >> larger file size is an acceptable trade off, if it reduces the >> >>frustration >> >> of this situation. Especially for new users who will absolutely think >> >>its a >> >> serious bug in the Royale compiler. However, as Harbs notes here, if >>the >> >> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be >> >>retained. >> >> The compiler could generate code differently when something resolves >>as >> >>the >> >> Object type. The emitter could translate dot notation normally most >>of >> >>the >> >> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it >> >> detects Object, switch to bracket notation instead. I believe it >>would >> >>also >> >> need to add quotes around properties defined in object literals. >> >> >> >> Ideally, the following code should work properly out of the box: >> >> >> >> var obj:Object = {one: 1, "two": 2}; >> >> obj.three = 3; >> >> obj["four"] = 4; >> >> var one:Number = obj["one"]; >> >> var two:Number = obj.two; >> >> var three:Number = obj["three"]; >> >> var four:Number = obj.four; >> >> >> >> The compiler would probably emit something like this to make it work >> >>with >> >> the Closure compiler's ADVANCED_OPTIMIZATIONS: >> >> >> >> var obj:Object = {"one": 1, "two": 2}; >> >> obj["three"] = 3; >> >> obj["four"] = 4; >> >> var one:Number = obj["one"]; >> >> var two:Number = obj["two"]; >> >> var three:Number = obj["three"]; >> >> var four:Number = obj["four"]; >> >> >> >> Again, that's only for when something is typed as Object. If >>something >> >> actually has a class, let Closure compiler go nuts and rename >> >>everything it >> >> wants. >> >> >> >> - Josh >> >> >> >> On 2018/02/06 08:51:19, Gabe Harbs <[email protected]> wrote: >> >> > 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? >> >> > >>>>>>>>>>>>> >> >> > >>>>>>>>>>>> >> >> > >>>>>>>>>>> >> >> > >>>>>>>>>> >> >> > >>>>>>>>> >> >> > >>>>>>>> >> >> > >>>>>>> >> >> > >>>>>> >> >> > >>>>> >> >> > >>>> >> >> > >>> >> >> > >> >> >> > > >> >> > >> >> > >> >> >> > >> > >> > >> >-- >> >Carlos Rovira >> >https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2 >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7C16f65e18ee564aa421b308d5 >> >6f22fef3%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0% >> 7C636537118603984962&s >> >data=bFel9Zwl4bBQWQNBB0UqK5j36pUSXjph1yeExZQOwjw%3D&reserved=0 >> >> > > >-- >Carlos Rovira >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2fde110ce8564489482608d5 >6f3ebb3a%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537237863888227&s >data=NzRRhywOm8%2FOHplSf0Q3f6dHLc480KaWNxYLScrFpRQ%3D&reserved=0
