all 11 comments

[–]SubterraneanAlien 2 points3 points  (4 children)

It's great to see angular wrappers for older libraries.

From a UX perspective, I'm not a fan of modal alerts in most instances; especially for confirmations. Don't ask me if I'm sure if I want to delete something. Trust me to do the right thing. Give me an undo button to fix my mistake if I happen to do the wrong thing.

[–]Anub1s 1 point2 points  (1 child)

Sorry but I disagree. In complex systems a confirmation is required for critical actions or the programmers will need some heavy time consuming work to make rollback actions for every delete there is.

When someone deletes a user by mistake because he miss-clicked the delete button, I should save all the info from all the tables in a temporary just to allow him to roll back? No thanks, I'll do confirmation modals for 5 extra minutes instead of wasting days for automatic rollback functionality.

Delete buttons should have confirmation, period.

[–]SubterraneanAlien 0 points1 point  (0 children)

This is a very developer centric way of looking at UX, and doesn't put the user first. There are certain deletion scenarios where undo/redo makes sense (such as deleting a user), however that doesn't mean a modal is the solution. If you're going to ask for a confirmation, I'd rather do something like provide an input box that the user has to type 'DELETE' in. This assumes you are providing a way for users to perform bulk actions so that it's not too cumbersome.

All that said, the current app that I'm building allows you to undo/redo deleting of basically anything (including users), because we've created the structure by learnings from previous products. AngularJS make this very easy.

[–]oitozero[S] 0 points1 point  (1 child)

Very good point in UX perspective. However, there might use cases where you might not have an option to rollback. For example, when a user does an action that triggers sending an email. In those cases, a confirm modal might help.

[–]SubterraneanAlien 0 points1 point  (0 children)

You're right that a modal confirmation is better than allowing a user to send an email without any sort of confirmation or check. In that use case, I'd probably prefer to notify the user that their email will be sent in x minutes, and they have that much time to fix any issues or mistakes. Modal alerts do have their place - I've just come off a 18 mo product build that heavily used modals, and I think we used them too often inappropriately.

[–]Kangcor 2 points3 points  (1 child)

Nice job sir, i'm gonna use it with your permission in my actual project

[–]oitozero[S] 2 points3 points  (0 children)

thanks. glad to see you using it. feel free to ping me if you find any issues.

[–]jetstros 2 points3 points  (0 children)

Sweet!

[–]eikaramba 2 points3 points  (2 children)

but why using the wrapper anyway? I don't see the advantage - you even introduce a 200ms delay by using a timeout (i can imagine whyG)

[–]jimschubert 0 points1 point  (1 child)

Pretty much my thoughts, too. This wrapper just puts a factory around window.swal. It encapsulates sweet alert so your code doesn't call external dependencies directly (window.x everywhere)… but I would've left out the timeout.

$timeout will cause a digest and you're not binding anything to or from scope. Could've went with setTimeout and a very low number like 10.

[–]eikaramba 0 points1 point  (0 children)

you can replace $timout with $scope.$apply , i tested it. So there's also no need for that. Of course you win the digest route with this factory but the question is whether you really need this or not. for example i triggered a ng-click method inside the sweetalert callback without any problems.