-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add generic confirmation modal #389
Add generic confirmation modal #389
Conversation
…d-confirmation-boxes # Conflicts: # core/examples/luigi-sample-angular/e2e/support/commands.js # core/examples/luigi-sample-angular/e2e/tests/luigi-client-features.spec.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please check comments.
@@ -10,7 +10,9 @@ var _onContextUpdatedFns = {}; | |||
var _onInitFns = {}; | |||
var authData = {}; | |||
var pathExistsPromises = {}; | |||
|
|||
let promises = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a need to make it an object inside an object? Why not just confirmationModalPromise
object?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created it having in mind a future refactoring to include all promises in same object. Apart from this one, we have pathExists promise, and we will soon have generic alert promise. This solution scales better in my opinion
</p> | ||
<p class="fd-has-font-style-italic" data-cy="luigi-confirmation-modal-result" | ||
ngClass="{{(confirmationModalResult.currentKey === 'confirmed') ? 'fd-has-color-status-1' : 'fd-has-color-status-2'}}"> | ||
{{confirmationModalResult.info[confirmationModalResult.currentKey]}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't that be easier to just have Confirmation modal has been {{confirmationModalResult.currentKey}}
instead of creating this confirmationModalResult .info object?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I totally agree with you, this is overcomplicated. Thanks for pointing that out. Refactored
docs/luigi-client-api.md
Outdated
|
||
#### Parameters | ||
|
||
- `content` **[Object](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Object)** Text for different elements in confirmation modal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add what elements the user can define.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely, I have added them
core/src/ConfirmationModal.html
Outdated
@@ -21,15 +21,19 @@ <h1 class="fd-modal__title">{title}</h1> | |||
<script type="text/javascript"> | |||
export default { | |||
data() { | |||
//fallback data in case title or text props weren't provided | |||
// fallback data in case not provided |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we have a confirmation modal component. We are using it currently once in App.html, in this case, we are alway providing the data to the component. Whenever you provide the data, it will never use the fallback data, even if the data you provide is undefined. I also tried with single variables instead of an object. If you give variables as input when using the component, it will never take the default values.
Default values would be taken if we use somewhere else the component and we do not give the 'content' as input. We could make it more complicated to match what you (and mostly anyone) would expect. Let´s discuss the best solution offline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added mechanism to set default values if not provided. If values are provided, even with a falsy value like empty string or undefined, they will be taken
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just minor things
Co-Authored-By: jesusreal <[email protected]>
Co-Authored-By: jesusreal <[email protected]>
Co-Authored-By: jesusreal <[email protected]>
Co-Authored-By: jesusreal <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small fix
client/src/luigi-client.js
Outdated
* @param {string} content.body the content of the modal body | ||
* @param {string} content.buttonConfirm the label for the modal confirm button | ||
* @param {string} content.buttonDismiss the label for the modal dismiss button | ||
* @returns {promise} A promise which is resolved when accepting confirmation modal and rejected when dismissing it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @returns {promise} A promise which is resolved when accepting confirmation modal and rejected when dismissing it. | |
* @returns a {promise} which is resolved when accepting the confirmation modal and rejected when dismissing it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not correct regarding documentation. First comes the type of the returned value and the the additional info. I will just add the "the"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok :) I was just looking at the entire document, and under has Back
I've found:
Returns boolean indicating if there is a preserved view you can return to.
that's why I wanted to adjust the other part of the doc. Should we change this one as well, or is it a different case?
Also let's then write a promise
- lower case, to make it consistent :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The piece of documentation you mentioned is:
* @returns {boolean} indicating if there is a preserved view you can return to.
I will replace the line we are talking about with:
* @returns {promise} which is resolved when accepting the confirmation modal and rejected when dismissing it.
This makes it consistent imho. Is that ok for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Splitting uxManager and linkManager methods to different projects (probably) caused problems.
- open the app in
/overview
- go to
projects
using top nav - go to
pr1
using left nav - click
add backdrop
- nothing happens - click
confirmation modal
- modal is opened, but there is no message if it has been confirmed / rejected
Works properly if I open the app in /projects/pr1
.
Also, could we move this confirmation modal to the middle of the window?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
core/src/ConfirmationModal.html
Outdated
box-sizing: border-box; | ||
width: $width; | ||
max-width: 90vw; | ||
top: calc(#{$topNavHeight} + 1rem); | ||
left: calc(50% + #{$leftNavWidth}/ 2 - #{$width}/ 2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be removed as well if we want to have it in the middle of the screen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will fix the 1st one. For the 2nd one, I will clarify it with Franz
Description
Changes proposed in this pull request:
Related issue(s)