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


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

Reply via email to