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. чт, 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 > > >
