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 > > > > > > > > > > > > > > >
