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