I am trying to use multiple toggles in my add-in but having trouble identifying which one was toggled.
I am able to get the id of the toggle in most cases, but if a user clicks on the smaller knob within the toggle, I am unable to get the toggle's id.
From the example above, if I click on the toggle thumb, where the red arrow points, I get the following output as the target.id
I have no way to identify which toggle this came from and do not believe I can set the id of the toggle thumb.
When the user clicks anywhere in the green sections, I get the following log where I can grab the ID and do conditional logic.
Before reporting this as a bug on github, I wanted to make sure I wasn't doing something wrong. I came across this which was similar but not what I am looking for: https://github.com/OfficeDev/office-ui-fabric-react/issues/6753
This code pen will show the issue:
https://codepen.io/rocketlobster5/pen/eYOvGjz
I don't think it should considered as a bug, to get the element that the event listener is attached to currentTarget property should be used instead of target.
The following example demonstrates how to retrieve id of toggle element:
private handleChange(ev: React.MouseEvent<HTMLElement>, checked: boolean) {
console.log(ev.currentTarget["id"]);
}
Modified codepen
Related
I am trying to automate an attendance form hosted by Google Forms, but the inputs aren't HTML <input> or <select> elements, so I am not sure how to change them other than manipulating the mouse and keyboard (an approach I used with Selenium).
Based off a fast peak; you could
let Form = document.querySelector('.freebirdFormviewerViewItemList');
let itemContainer = Form.querySelectorAll('.freebirdFormviewerViewNumberedItemContainer');
itemContainer.forEach((element)=>{
// Your code here, you should in theory be doing deeper loops depending on how advanced you want this.
});
Inside the loop we'd need to just find all the active inputs we want with a
itemContainer.forEach((element)=>{
if(element.querySelector('.exportOuterCircle')) {
console.log('we found ourselves a radio button but just one, we could go deeper with querySelector (and help of loops/etc)')
}
});
This is a bit of a large-task but not so bad, just make sure the freebirdFormviewerViewNumberedItemContainer class is correct every-form to or y ou find the pattern per-page that selects the questions for a fast loop through.
On loop, you're to query select one or more(if so apply another loop) to find the options you want. In this demo above radio button search, if the pages stay static you should with my example be able to grab/see a console pop-up no errors;
For setting these values, it's as easy in some cases setAttribute/value/ and other modifiers once selection is made. So you know click already and so the radio buttons be a good example. Any issues try navigating your elements in developer menu and sort if selections are going down correctly.
https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector
I'm using the compound model and the cytoscape-compound-drag-and-drop extension to let the user manually reorganize the layout by grouping some nodes together and moving whole groups easily.
Now I want a button to toggle the display of these groups "boxes", but keep displaying all non-parent nodes.
I first tried hide() on parent nodes, but it also hides the children, so I switched to dynamically applying a class which specifies display:hidden.
It seemed to do the trick, but still the hidden box can be clicked and cytoscape default "visual feedback" for click applies, showing off the area where the hidden box still lies.
I tried plenty of things that didn't work:
- disable events from my hidden style class: tried events:no. Should I report this as a bug ?
- .ungrabify().unselectify().panify().lock()
- on click: destroy the event object
- set e.target._private.active = false
I tried a nasty hack: setting e.target._private.position = {}
The event is still fired, but destroying the position sucessfully prevents the "visual feedback" from happenning, my box effectively stays "hidden".
But still the event occurs on the wrong target: the box, not on the empty space of the cytoscape container. I can keep hacking and leave with it, but isn't there a simpler solution to ?
Is it possible to simply and truly pass through hidden parent nodes events ?
You haven't used events properly.
cy.$('node').forEach(node => {
node.events = 'no'; // will not work
});
The following does work, and you can also restore events whenever you want.
cy.$('node').forEach(node => {
node.style('events', 'no');
});
I am trying to test the states of slide-toggles within my app using Cypress.
These time out and fails the test:
cy.get('label.mat-slide-toggle-label').eq(2).should('be.checked')
or
cy.get('div.mat-slide-toggle-bar').eq(2).should('be.checked')
Where as these pass
cy.get('label.mat-slide-toggle-label').eq(2).should('not.checked')
or
cy.get('div.mat-slide-toggle-bar').eq(2).should('not.checked')
The only difference is that the state of the toggle has changed.
Can someone help explain why the "not.checked" tests pass, but the others don't?
The documentation states:
The <mat-slide-toggle> uses an internal <input type="checkbox">
to provide an accessible experience. This internal checkbox
receives focus and is automatically labelled by the text content of
the <mat-slide-toggle> element.
When Angular Material adds the switch, it adds a whole little hierarchy of elements under the outer <mat-slide-toggle> element; divs with classes like mat-slide-toggle-label, mat-slide-toggle-bar, etc. But it also adds a real (but hidden) <input> element.
The 'checked' test only applies to input elements (this is probably why your should('not.be.checked') tests are working--because non-input elements can never be checked. So, to use Cypress's should('be.checked') test, you need to tell Cypress to get a reference to the actual <input> contained within the <mat-slide-toggle>, and not one of the other mat-xxx elements.
Example:
cy.get('mat-slide-toggle#whateverId input').should('be.checked');
// get reference to the single <input> inside the <mat-slide-toggle>
or:
cy.get('mat-slide-toggle#whateverId .mat-slide-toggle-input').should('be.checked');
// get reference to the element with class "mat-slide-toggle-input" inside the <mat-slide-toggle> (which is the <input> itself)
I was going to invite you to use the GUI snapshots panel to better understand what could be wrong, and maybe increase the timeout(s).
But in fact, I'm tempted to conclude that neither <label> nor <div> can be checked. <input type="checkbox"> can.
Is there another property you can assert on your label ?
I have managed to find a element for each toggle that allows me to check the state (checked or not checked).
input#mat-slide-toggle-29-input.mat-slide-toggle-input.cdk-visually-hidden
All I need to do is change the number to related to the toggle under test. I can check that the toggle is checked, press the master switch and then check that it is unchecked. I will also created a test where I test each toggle individually to ensure that the toggle works in a ground and singularly.
I'm not sure whether I'm using the right terminology here - but here is an example:
https://gist.run/?id=57ed46429e4583eb4c3fb11814451a55
This is how it looks like in Chromium:
Basically, the entries on top (red outline) are a visualization of an array as the "first-level" data display; here one can toggle each element's selection, and make a multi-element selection (red background). The array that is the source of the "first-level" display is mydata in first-level-items.js.
Those items that are selected in "first-level", are then shown again in "second-level" (green outline); here the same information of name and value is displayed, although a bit differently. Here also one can toggle an elements selection - but only one "second-level" element can be selected. The array that is the source of the "second-level" display is myseldata in second-level-items.js.
The intent here, is that once a "second-level" selection has been made, a slider appears, to change the .value property of the particular object which is the selected array element.
My original question (which is why I started this post/example at all), was:
How do I ensure that whenever the slider is changed, the value is updated in both second-level and first-level display?
... however, for reasons beyond me, this in fact does work somewhat in this gist.run example (but it still doesn't work in my actual project, which forced me to come up with the example to begin with). Also it only works somewhat, in the sense that when loading the example page at first, after making first and second level selections, and then changing the slider, the .value will be updated in both first- and second-level display. But as soon as I try deselecting on second level - or changing the selection on second level - then updating stops. So, I guess this question still stands...
After a second-level selection has been made, deselecting on second level (by clicking to toggle) does NOT remove the slider; how can I have it behave like that?
The update happens only on the slider's onChange - basically, while you drag and slide, this component emits onSlide, but it will generate onChange only at the end when the mouse is released (that is, when the sliding has stopped). How can I update both first- and second- level display while the slider is sliding?
And finally - is this how this kind of a problem is best addressed in Aurelia? That is - I currently have one array in first-level-items.js; first-level-items.js then has a singleton reference to second-level-items.js, so it can call a method within it, to change a filtered copy of the array on the second level, which then serves as a source both for second-level display and the slider... Is there a better way to organise this?
Boy, this was a pain, but here's what I think is the solution:
https://gist.run/?id=c09fea3b82a9ebc41e0a4c90e8665b04
Here are some notes:
Apparently, there is something wrong applying if.bind or show.bind on the input element of the slider - instead, the input element should be put in an enclosing div, and the div should have if/show.bind applied
Furthermore, if.bind should not be used, as it re-instantiates the slider element - use show.bind so we can get a reference to the slider widget at start already, even if it is hidden
Seemingly, using TaskQueue in attached() is the only way to get a reference to the slider at start
Once we have a reference to the widget, re-apply it on each second level element, whenever they change
Do not set this.myselChanging to null to specify no target of the slider (simply count on hiding the slider appropriately)
For a continuous change (onSlide), simply use this.myselChanging.value = e.value; in the handler - both first-level and second-level values will be changed
Beyond this, it seems arrays are copied by reference, so the multi-level update happens without further intervention...
Though, would still love to know what is the proper way to do this...
I have a single page app using Backbone, and whenever I over over something and then click the "back" button, the popover forever stays.
I want to destroy all instances of popover when a new instance is loaded.
Finding the popovers that are created through the data API is not difficult and has been covered in other answers like those of David Mulder and Amir Popovich. You just do:
$("[data-toggle='popover']").popover('hide');
Or you can use destroy if you need to or prefer to.
The challenge is to handle those popovers that are created dynamically.
Marking the Elements with Popovers
I would implement something like this. I'd override the default popover method and I'd try to perform this override as early as possible so that everything that needs a popover uses my override. What it does is just mark elements that use a popover with a class. Bootstrap does not mark them itself:
// Override popover so as to mark everything that uses a popover.
var old_popover = $.fn.popover;
function my_popover() {
this.addClass('marked-as-having-a-popover');
return old_popover.apply(this, arguments);
}
$.fn.popover = my_popover;
Then to clear everything before the unloading, I'd put in the code that detects the unloading the following:
$(".marked-as-having-a-popover").popover('hide');
Or it could use destroy rather than hide if testing shows that it works better for your use-case.
Now, the method above will work if the override happens early enough and you do not have a page where multiple jQueries are loaded. (Yep, this is possible.) I use something similar to deal with tooltips in one of my applications so I know the principle is sound. It so happens that in my app, all tooltips are created by my code so there is no risk of missing something.
Finding All Elements with Popovers, Even Unmarked
If you are in a situation where a popover can be created without being marked (I call this an "escapee"), then you need to query the whole DOM and find which elements have popovers. There is no shortcut here. You cannot rely on attributes like data-content because popovers can be created wholly dynamically (i.e. without any of the data- attributes). Also, all kinds of elements can get popovers, so you cannot reliably assume that only button elements will have a popover. The only surefire way to find everything that needs handling is to look at each element in the DOM and check whether it has a popover:
// Obviously this is quite expensive but in a situation where there *can* be escapees
// then you have to check all elements to see if they have a popover.
$("*").each(function () {
// Bootstrap sets a data field with key `bs.popover` on elements that have a popover.
// Note that there is no corresponding **HTML attribute** on the elements so we cannot
// perform a search by attribute.
var popover = $.data(this, "bs.popover");
if (popover)
$(this).popover('hide');
});
Again, destroy could be used rather than hide.
Proof of Concept
Here is a fiddle that illustrates the entire thing:
"Add a Dynamic Popover" simulates code that would add a popover when the override is in effect.
"Add an Escapee" simulates code that would add a popover and somehow manage to use the original Bootstrap code.
"Clear Marked" clears only the marked popovers.
"Clear All" clears every single popover marked or not.
try with this:
$('YOUR_ELEMENT_SELECTOR').popover('dispose');
reference url: https://getbootstrap.com/docs/4.1/components/popovers/
Its very simple, just you have to call one function popover() with argument "destroy" to destroy the popover. It will destroy all popovers which is created by $("[data-toggle=popover]").popover();
you can check documentation for more options and arguments of popover().
I suggest you to destroy popovers with having specific class name instead of using following code.
$("[data-toggle='popover']").popover('destroy');
The above code will destroy all popovers in the page. So instead of this, use class selector.
$(".YourClassName").popover('destroy');
If you have problems and need to remove all for sure:
$('.popover').remove();
will help (Popover automatic add this class, even for dynamicly created objects). It destroys all the popover DOM-Object incl. callbacks, etc.
But thats the rough way. Typically I displose all by popover class (clean way) and to be sure I do a hard clean up after. Works for me fine!
$('.popover').popover('dispose');
$('.popover').remove();
If you like to remove all execpt one, use a filter() with :not-Selector
$('.popover').filter(':not(#yourID)').popover('dispose');
$('.popover').filter(':not(#yourID)').remove();
popover adds also a id with a random number
#popoverxxxxx where xxxxx is a five digit number.
this helps sometimes to compare popovers. Of cause this could also be used to identify the popovers.
Something generic like this (assuming you're using data-bindings) should do the trick:
$('[data-toggle="popover"]').popover('hide')
or the more extreme call
$('[data-toggle="popover"]').popover('destroy')
though I doubt that would make sense often. Still to address the specific bug you're encountering you should create a minimal test case so that that bug itself can be addressed.
Oh and if you specifically want to check for open popovers you can use .data("bs.popover").$tip.parent().length (which is a bit of an hack), for example:
$('[data-toggle="popover"]:eq(0)').data("bs.popover").$tip.parent().length == 1
You can hide all popovers by using this:
$("[data-toggle='popover']").popover('hide');
You can destroy all popovers by using this:
$("[data-toggle='popover']").popover('destroy');
The difference between hide and destory is that when you hide a popover you do not need to reactive it, but when you destroy it you do.
Check out my JSFIDDLE and then:
Click on all popovers and then click hide. After clicking hide you can click on the popovers again.
Click on all popovers and then click destroy. After clicking destroy try clicking on the popovers again and see that nothing will happen since they are destroyed. In order to make them functional again, you will need to click on reactive and then try.
Popovers must be initialized manually, so you know exactly what you have to destroy because you did initialize it.
You should just call the destroy function with the same selector.
Or maybe I am missing something ?