Hi, IMO, new "standardized" browser features will eventually show up in js.swc because they'll show up in the Google Closure's externs. We can put those in the js.swc's missing.js in the interim.
AIUI, 3rd-parties add other things to the prototypes that are not standardized. If those are not called "polyfills", fine. I would recommend those things not be added to missing.js, but as a separate typedefs SWC. Either way, both scenarios should be presented to the app developer the same way for PAYG reasons. We should focus on PAYG and composition instead of inheritance and not lose sight of our desire to deal with other runtimes/platforms someday. So, instead of adding an "animate" API to UIBase or IUIBase, we should have an Animate bead. The Animate bead's JS code can call element.animate if we've added it to missing.js, but I'd like us to find some other pattern for non-standardized APIs otherwise missing.js will eventually hold every 3rd-party prototype hack ever invented. I'd suggest that, like HTMLElementWrapper/element/positioner, maybe we should create an HTMLElementAnimateWrapper. Or something like that. My 2 cents, -Alex On 5/5/19, 6:53 AM, "Carlos Rovira" <[email protected]> wrote: Hi, I agree in most of the points explained here, but want to expose a point that maybe will change this particular case. A Polyfill for me is a JS implementation of an API that will be part of all browsers natively, and use to be already implemented by 1 or 2 browsers, but not for all the most important ones. So to be able to use actually people use a JS implementation until all browsers implement it. So the bead approach is ok to me when we implement things to be supported cross targets, and we can create a bead for animation and in JS do strand["animate"], but still would want JS (through Royale) could make a dot access and not that kind of bracket access that seems to me not what people should end to do. In this case we are talking to a new Element API, so I was figuring is this could be added vía prototype something like: Element.prototype.animate I see lots of this in typedefs and we should not forget that animate method is coming vía Web Animations API, so I think is something sooner or later we'll be on the HTML apis So for me there's two separate things, one make a bead implementation to ensure cross target consistency in APIs, and other, in this case centered on HTML target, how to deal with a new API that will be part of all browsers to support it sooner vía pollyfill. (Notice that we still need to add @keyframe to CSS parsing in Royale that is still unsupported, and this is the way to do the same as animate vía CSS) thoughts? El dom., 5 may. 2019 a las 14:02, Yishay Weiss (<[email protected]>) escribió: > > >if you can get yourself away from trying to access features on concrete > instances > (…) > > >var animateBead:IAnimateBead = > indicator_content.getBeadByType(IAnimateBead); > >animateBead.animate(); > > Is this PAYG? getBeadByType iterates through an array. > Also, animateBead may turn out to be null which adds a level of > uncertainty as to whether or not this will run. > > -- Carlos Rovira https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce6ca6613bd5a4315d99108d6d16104ac%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636926611965222777&sdata=n7yCDIWT3QYtHMTHNNDoy%2FZYau5D6w3gGWJwQMAejhg%3D&reserved=0
