unraid/webgui

Time to add SweetAlert2?

Opened this issue · 9 comments

gfjardim commented

Hi guys. The first generation of SweetAlert is unmaintained, and it's fork, called SweetAlert2 has loads of new goodies, like chaining modals, loads of input types, etc...

I think it's doable to add the fork without removing the original one, giving time to authors to migrate to the new version. What do you think?

Squidly271 commented

I did a feature request for the same thing 3 months ago http://lime-technology.com/forum/index.php?topic=53962.0

gfjardim commented

@Squidly271, never saw that. Let's see if LT agrees with it this time.

Squidly271 commented

And on a quick look at the API, I think it can outright replace the original as a drop in replacement. Testing of course would need to be done

gfjardim commented

Just add it as swal2 function. With time, each popup will get ported and then we can remove SweetAlert 1, imho.

bergware commented

I tested swal2 previously, but it breaks the function calling mechanism. Introducing swal2 would mean changing code in several places and possible impact on plugins.

gfjardim commented

@bergware, if we adopted the SweetAlert2 as swal2 function, I'm pretty sure it can ride along with SA1. This will give us time to migrate to the new widget. CSS won't be a problem, since all it's classes are prefixed "swal2".

gfjardim commented

@limetech, have you considered this?

eschultz commented

@gfjardim Sure, we'll consider adding SweetAlert2 in unRAID 6.4.

With some crafty swal1-to-swal2 adaption code behind the scenes it may be possible to translate (convert options, switch callback to Promises, etc.) and invoke swal2 for everything without needing to change any legacy swal calls in the webGui/plugins. It might be tough, but at least a developer can dream! 🤓

FYI, I was looking at this as a simple overview for the differences from swal1 to swal2: https://github.com/limonte/sweetalert2/wiki/Migration-from-SweetAlert-to-SweetAlert2

gfjardim commented

Eric, my suggestion is to introduce swal2 now (e.g. 6.3.2) alongside with swal1 code until 6.4. This way we can release updated code within this timeframe without any worries, and keep things as simple as possible. When 6.4 got released, we can deprecate swal1, and then remove it from OS and plugins.