FWIW, source externs might have bugs. I only tried it in one simple test case. But it should be possible to make it work and we want it to work. It would be like writing header files for 'C' programs.
Both #2 and #3 are valid ways of integrating external JS in Royale. #2 is better for non-UI libraries. #3 is better for UI libraries, but may be required for a non-UI library that doesn't have a procedural API surface or you want to create a more strongly-typed API surface. In theory, tooling to automatically generate typedefs should be possible. It, like many other things, is mostly a matter of time. Josh, would you consider donating dts2as to Royale? Is there enough stuff in there that could be re-used? The basic idea is that you need a description of the types (usually as comments) associated with an API declaration. Just look at Google's externs for an example. The complicating factor is that there is no single standard of describing the types or declaring the API. Some folks wrap their declarations in an object to create a namespace. Others use Google's format. Others use Typescript. Royale has (via Google Closure Compiler) access to Rhino, a JavaScript parser, so we can parse non-externs JavaScript if we need to and walk all of the nodes and generate externs if we want to. It would be interesting to see if the DTS files could be better converted by writing a conversion app in TypeScript itself. I don't have time to work on this, I'm just throwing ideas out there in case someone is interested. HTH, -Alex On 5/2/19, 9:02 AM, "Carlos Rovira" <[email protected]> wrote: Hi Josh, I think this piece of knowledge you just exposed here is key for the success of Royale. I'll try to use this in TDJ to experiment with it and will use in the blog example I plan to do. thanks! El jue., 2 may. 2019 a las 16:36, Josh Tynjala (<[email protected]>) escribió: > > Users can't do this, they required that Royale framework devs add > typedefs to the typedefs repo and wait to next SDK release. What does not > seems very useful. > > Users can create their own typedefs from scratch. > > I just created a quick example for hljs, that exposes the highlightBlock() > function: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdIq0&data=02%7C01%7Caharui%40adobe.com%7C41fd5b44a618421a24fd08d6cf1791a0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924097469557412&sdata=9qQSyt7WG7tqOdT6i2C3Dngc5IU3e1yGO5j7XLhhEWQ%3D&reserved=0 > > Basically, the class needs an asdoc comment with the @externs tag (this is > something that comes from Google Closure compiler, which we use to create > release builds) and the compiler should handle the rest. > > As I understand it, you don't even need to create a SWC library for custom > typedefs. Recently, Alex mentioned that the mxmlc compiler is smart enough > to handle a source file as long as it has the @externs tag. > > - Josh > > On 2019/05/02 09:34:37, Carlos Rovira <[email protected]> wrote: > > Hi, > > > > to sumarize (let me know if I'm wrong), the current ways to integrate an > > existing library are 3: > > > > 1.- access vía brackets notation: This is the most easy and direct, an > > example is TourDeJewel in class utils.HighlightCode > > > > var hljs:Object = window["hljs"]; > > hljs["highlightBlock"](block); > > > > but this one is not what we really want since we are going with Roayle > and > > AS3 to get type checking and strong typing. So this, although useful is > not > > what we really want to use in out Apps, but since we want to maintain the > > dynamic aspect of the language it could be very useful sometimes > > > > 2.- using typedefs > > > > This will be the next step to use a real type and dot notation, but seems > > not easy or direct. > > Users can't do this, they required that Royale framework devs add > typedefs > > to the typedefs repo and wait to next SDK release. What does not seems > very > > useful. > > > > In the other hand we'll need to know how to extend current typedefs since > > don't know if we have docs about this. Until now I added to "missing.js" > > file fo now, but this doesn't seems a valid path since it lacks > > organization, separation, and a way for all people contributing to know > wha > > we have, what can be added and where, if not we'll find in time lots of > > code very difficult to maintain. > > > > Yishay and Josh talked about to use TypeScript, but seems that is already > > explored by Josh but not a valid path since will be very difficult to > > maintain. > > > > 3.- wrapping libraries > > > > This is how we did with MDL. This will be recommended when we want to > > integrate existing libraries with Royale to make it work with our APIs > in a > > more seamless way. But the problems is that this is very laborious. Can > be > > useful for some concrete libraries and we should do when needed (the case > > is MDL). But the problem is that this not solve the problem of our users > > that need to integrate a existing library themselves in a quick way. > > > > Let me know if you know other way. > > > > For me method 1, is ok to do the work, but doesn't make us justice. > > method 2 should be the main one if there's a fast and easy way... I'm > > missing something here? Can users create typedefs themselves? > > method 3 can be useful for us or for users (doing their own libs, and > > eventually can share with us to add to official royale repo and sdk) > > but is something not fast at all and not as convenient and direct as > method > > 2, and will require maintenance as libs change. > > > > Could we agree that this is the currently available ways in Royale now to > > use external JS libs? > > > > thanks > > > > -- > > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C41fd5b44a618421a24fd08d6cf1791a0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924097469557412&sdata=dcdgme4YtQgOPVzHIq7YDDcuCSFxfyzpDxaQS2tE7g8%3D&reserved=0 > > > -- Carlos Rovira https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C41fd5b44a618421a24fd08d6cf1791a0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924097469557412&sdata=dcdgme4YtQgOPVzHIq7YDDcuCSFxfyzpDxaQS2tE7g8%3D&reserved=0
