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

Reply via email to