Please see this commit in my branch https://github.com/andruhon/wicket/commit/f507ae60f183882336b6ca145ab945a6ba9bc94a
пт, 3 мая 2019 г. в 16:46, Andrew Kondratev <[email protected]>: > Hi Everyone! > > Today I tried to quickly migrate a wicket-ajax-jquery into a bunch of TS > files and made it build into something similar to what was originally > there. Just made it compile and checked that Wicket.Class.create() works > with this example: > > ``` > Wicket.SomethingElse = Wicket.Class.create(); > Wicket.SomethingElse.prototype = { > initialize: function() { > this.message = "HiThere!"; > }, > hi: function() { > console.log(this.message); > } > }; > var something = new Wicket.SomethingElse(); > something.hi(); > ``` > > The implementation is still missing some bits and pieces and for sure not > optimal, just a proof of concept. Just wanted all you to have a look and > think if it worth further time investment. > > чт, 2 мая 2019 г. в 20:58, Andrew Kondratev <[email protected]>: > >> Right, I'll try to toss these objects into separate TS files WITHOUT >> changing anything in implementation to finish with with full compatibility >> with all existing code and tests and will see how it looks like. If result >> will look good we can discuss how the TS transpilation can be properly >> squeezed into the wicket build. >> >> P.S. I don't think that transpilation of this amount of code will take >> longer than 1 or 2 seconds. >> >> чт, 2 мая 2019 г. в 20:51, Martin Terra <[email protected] >> >: >> >>> to 2. toukok. 2019 klo 11.42 Martin Grigorov ([email protected]) >>> kirjoitti: >>> >>> > On Thu, May 2, 2019 at 11:17 AM Andrew Kondratev <[email protected] >>> > >>> > wrote: >>> > >>> > > The idea for using TypeScript came into my mind when I was >>> implementing >>> > > custom AjaxBehaviour, because I had a few issues with it: >>> > > 1. The 3000 lines file is not quite a readable thing. >>> > > 2. There's not a lot of intelli sense help when someone trying to >>> > implement >>> > > something. Say it's hard to remember what's the object passed to >>> > > Wicket.Ajax.post, and what's dh in this object, is dh an object or a >>> > > function or array of functions, what is ep and so on... >>> > > >>> > > Potentially second can be improved without changing the code itself, >>> by >>> > > implementing d.ts definitions for the file. The first problem can >>> also be >>> > > fixed by placing objects such as Wicket.Log, Wicket.Channel, >>> Wicket.Ajax >>> > > and so on into separate files and then concatenate them somehow into >>> > single >>> > > file. >>> > > >>> > >>> > I start to like the idea! >>> > Let's see what others think. >>> > To convince us more you can create a branch and setup the TS build in >>> > wicket-core >>> > >>> > >>> +1 >>> >>> > >>> > > >>> > > чт, 2 мая 2019 г. в 18:17, Martin Grigorov <[email protected]>: >>> > > >>> > > > Hi, >>> > > > >>> > > > >>> > > > On Thu, May 2, 2019 at 7:02 AM Andrew Kondratev < >>> [email protected]> >>> > > > wrote: >>> > > > >>> > > > > Hi Colleagues! >>> > > > > >>> > > > > Are there any plans about refactoring / modernisation of wicket's >>> > > > front-end >>> > > > > code? >>> > > > > >>> > > > >>> > > > None that I am aware of. >>> > > > >>> > > > >>> > > > > >>> > > > > What comes to my mind: >>> > > > > >>> > > > > - Start using TypeScript for a new code, so we can have type >>> > safety >>> > > on >>> > > > > the front end side as well. TypeScript is also released under >>> > apache >>> > > > > license, so I think there should be no licensing issue with >>> this. >>> > > > > Potentially, as a crazy idea Kotlin could also work, but I >>> think >>> > > > > TypeScript >>> > > > > suits better and requires less effort and learning; >>> > > > > >>> > > > >>> > > > I do not see big profit in using TypeScript for Wicket Ajax. >>> > > > Generally I prefer TypeScript over JavaScript, but only for bigger >>> code >>> > > > bases with more often development. >>> > > > wicket-ajax-jquery.js is quite stable in the last several years >>> (since >>> > > > 6.0.0). It is more stable for two main reasons: >>> > > > - we migrated the old vanilla JS code to jQuery based one. Note: >>> the >>> > > > vanilla JS version was fragile due to the browser >>> incompatibilities. >>> > > > - we added a *lot* of JS tests ! >>> > > > >>> > > > IMO using TypeScript won't add much value. It will only make the >>> build >>> > > > process more complex and a bit slower. >>> > > > >>> > > > >>> > > > > - Potentially get rid of jQuery, it's not that useful in 2019 >>> > > (wicket >>> > > > > has recently dropped legacy IE support); >>> > > > > >>> > > > >>> > > > This has been suggested by someone else several months ago. But >>> AFAIK >>> > > > nothing has been done so far. >>> > > > The good thing is that one can replace wicket-ajax-jquery.js with >>> > > > wicket-ajax-xyz.js in his/her application by using >>> > > > >>> application.getJavaScriptLibrarySettings().setWicketAjaxReference(...). >>> > > > So both implementations could be supported by Wicket for some time >>> > with a >>> > > > deprecation cycle for the jQuery based one. >>> > > > These are the requirements I have: >>> > > > - same Wicket.xyz APIs are supported, because this is what the Java >>> > code >>> > > > uses >>> > > > - the test suite still passes >>> > > > >>> > > > >>> > > > > - Potentially introduce some modern lightweight front-end >>> > framework >>> > > > such >>> > > > > as ReactJS; >>> > > > > >>> > > > >>> > > > What benefits would that bring ? >>> > > > I do not want to use ReactJS just because it is the latest fashion >>> in >>> > JS >>> > > > world. >>> > > > >>> > > > >>> > > > > >>> > > > > Sorry if it was already discussed, I searched on >>> > > issues.apache.org/jira >>> > > > > and >>> > > > > didn't find anything relevant. Just wanted to discuss if >>> something >>> > like >>> > > > > this is possible for distant future release. Potentially I can >>> > devote a >>> > > > few >>> > > > > hours a week to this. >>> > > > > >>> > > > >>> > > > Thanks for the suggestions! >>> > > > >>> > > > >>> > > > > >>> > > > > Have a nice day, >>> > > > > Andrew >>> > > > > >>> > > > >>> > > >>> > >>> >>
