Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Introduce custom modal confirmation dialogs #9859
Stop using native confirm dialogs and create a custom one. @cjcenizal is planning on further improving the UI of the dialog but here it is for now:
You can test it out in timelion by trying to delete a saved sheet. All usages of safeConfirm will now use this custom modal dialog.
Joe and I talked about the most recent changes to the PR and we came to a couple conclusions:
- Logic is best extracted out of an Angular service into a vanilla JS service when the resulting JS service has no Angular dependencies. This makes the service more reusable, testable, and easier to migrate into a non-Angular codebase.
- Extracting logic into a vanilla JS service creates indirection and adds complexity, which is only a good tradeoff if the above criteria can be met.
- The file
modal_dialogue.jsis more of a "teleport" for adding and removing an element to the body, and its knowledge of scope dilutes this single responsibility.
So, I think we should revert to the most recent commit, but preserve the changes made in response to my comments, as well as preserve the single point of entry in
Let's Zoom about this some more to make sure this makes sense. We had a long discussion and I may not be completely representing it here.
Joe's working on a POC to explore some other ideas he had as we were talking, partially inspired by the Modal demo I showed you (http://smaato.github.io/ui-framework/#/modal).
Are the new rules/suggestions using this
Also @cjcenizal you had said in that email
I don't think we've hit a) yet with this new pattern. I like it a lot, but after thinking about that email, I'm not sure I should be adopting it at this point. I guess I don't see the difference between me introducing this new pattern/style and what @weltenwort was trying to do. Both are attempts at creating new patterns in the code base but it looks like @weltenwort was held to the consistency/team adoption standard, while this pattern is being allowed to slip by. Perhaps this is my fault since I am the first person to introduce it to the existing code base, I'm just having second thoughts after that email and wondering if adopting the
I merged @w33ble's PR and made a few small adjustments like moving safe_confirm into the modals folder.
I have a question though - why the change to pass onConfirm and onCancel instead of returning a promise? Also making them default to noop feels a bit weird to me. If the default is to do nothing, there really shouldn't be two buttons. I could see making one optional, but not both. But then if you make one optional, which one?
referenced this pull request
Jan 16, 2017
This is all still very much in flux, it's just a pattern we've been happy with elsewhere. I still would have liked to break out the vanilla code, even just to make testing easier, but I see CJ's point in that the code is useless without Angular. But mocking the Angular stuff isn't that hard either, so I'm a little torn. What do you think?
I agree with what @Bargs has said. I didn't know of anyone else proposing other patterns at the moment though, and still need to dive in to what @weltenwort has been doing. Planning to sync with him this week. Like I said, the management team has been pretty happy with these patterns, but we do need to get larger buy-in from the team, and I think it's important to get feedback from more than just the three of us; that's a big part of why I brought this up with you originally. We're still very much open to other ideas.
If you decide not to follow our patterns here, it's really up to you. This is your PR after all.
I though it best to let the click handlers decide what to do when the user clicks the button. This way, the modal is only concerned with executing some handler and closing itself. We may not always want to deal with a promise, and it has the added bonus of one less dependency within
If you disagree, feel free to change it up.
Overall, this looks great!
One UX detail - it would be great if safeConfirm/confirmModal would focus the Okay/Confirm button by default, so users could just hit enter and confirm the dialog. This is how the vanilla