use a callback to toggle the collapse on small screens - plotly-dash

I saw a lot of this in many codes and I also even use this code by copying it from somewhere. But I don't understand what they do. Can anyone help me with the below code? Thanks
# we use a callback to toggle the collapse on small screens
#app.callback(
Output("navbar-collapse", "is_open"),
[Input("navbar-toggler", "n_clicks")],
[State("navbar-collapse", "is_open")],
)
def toggle_navbar_collapse(n, is_open):
if n:
return not is_open
return is_open
if __name__ == "__main__":
app.run_server(debug=False)

This callback is triggered by clicking on clickable element (mostly likely a button) with id navbar-toggler. This is an input argument meaning whenever the n_click changes for this element, the callback is triggered.
The state argument is the collapsible element's current collapsed state (either True or False).
The if condition checks whether the button has been clicked on yet, if not then it is most likely the initial loading of the app, and so just return the the current collapsible element's collapsed state as it is. If the n_clicks is greater than 0 (ie. the callback was triggered by the click), then return the negation of the current collapsible element's collapsed state (ie. if it is True change to False and vice versa). This way, when it is collapsed and you toggle the button, the collapsible element will re-open and vice versa.

Related

Focusing input box programatically from another component

I had a question where the (great) answer exemplified how to allow an input box to obtain focus (by requesting change detection to be run in case the component isn't visible at the moment of focus assignment).
Now, I'm faced with a similar problem. I'm setting the value in a field of the component that contains the input box from another component. It works as far I can see the input box being displayed and the read-only label getting hidden. However, the input box isn't focused on.
I'm suspecting that the reason for it is the same, or least similar. However, since I'm setting the value from outside of the component, I can't rely on accessing it as a view child anymore, as I did in the case of the click handler.
What would be an appropriate strategy to approach it?
The usual googling rendered no useful links. I'm not providing a sample because, frankly, I'm not sure how to illustrate the issue other than describe it in words.
onUpdate(config: DataRowConfig) {
const target = config.cellConfigs.find(a => a.justSubmitted);
const index = config.cellConfigs.findIndex(a => a.justSubmitted);
if (target.key === "Enter")
config.cellConfigs[(column + 1) % 5].editing = true;
}

How to make a custom web component focusable?

I'm writing a custom web component that is meant to be interactive. How can I tell the browser that this custom component should receive focus?
I wish that my custom element…
could be focused (by tab-navigation);
could receive keypresses when focused;
could be matched by :focus pseudo-selector.
I'm not using any external library, just plain HTML5 APIs.
Based on this demo that I found in this question, I have this answer:
Just add the tabindex attribute to the elements you want to be focusable.
// Add this to createdCallback function:
if (!this.hasAttribute('tabindex')) {
// Choose one of the following lines (but not both):
this.setAttribute('tabindex', 0);
this.tabIndex = 0;
}
// The browser automatically syncs tabindex attribute with .tabIndex property.
Clicking on the element will give it focus. Pressing tab will work. Using :focus in CSS will also work. keydown and keyup events work, although keypress doesn't (but it's deprecated anyway). Tested on Chrome 44 and Firefox 40.
Also note that this.tabIndex returns -1 even if the HTML attribute is missing, but this has a different behavior than setting tabindex="1":
<foo></foo>: No tabindex attribute, the element is not focusable.
<foo tabindex="-1"></foo>: The element is not reachable through tab-navigation, but it is still focusable by clicking.
References:
http://www.w3.org/TR/html5/editing.html#sequential-focus-navigation-and-the-tabindex-attribute
https://html.spec.whatwg.org/multipage/interaction.html#the-tabindex-attribute
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex
https://github.com/whatwg/html/issues/113
#Denilson, I would like to provide you with some more information.
As you said, this.tabIndex = 0 works when your webcomponent contains no focusable elements. If it does, it gets more complicated.
For example, if your component contains one or more inputs, then first the "whole" component gets focus, and only later, when tabbing, each inner inputs get focus, one by one. This is usually not what you want. Usually, when the component gets focus this should mean its first input gets focus immediately.
Also, there is a reverse tabbing problem. If your first input has focus and you press SHIFT-TAB, then the "whole" component gets focus, and you are forced to press SHIFT-TAB twice to move to the previous element.
I found this to solve all focus and tabbing problems:
// At first, the component may get focus and accept tabbing.
createdCallback = function () { this.tabIndex = 0; }
// When the component gets focus, pass focus to the first inner element.
// Then make tabindex -1 so that the component may still get focus, but does NOT accept tabbing.
focus = function (e) { firstFocusableInnerElement.focus(); this.tabIndex = -1; }
// When we completely left the component, then component may accept tabbing again.
blur = function (e) { this.tabIndex = 0; }
Note: As of now (Sep 2015) if an inner element gets focus, then the "whole" element is not matched by the :focus pseudo-selector (tested only in Chrome). If find this behavior to be just plain wrong. The focus event was fired, and the blur event was not. So the element should have focus, right? I hope they change this in the future.
Short answer: delegatesFocus is what you need here, not tabindex.
Details:
Assuming that you have interactive elements inside the shadow DOM, there is no satisfying way to make the component programmatically focusable with tabindex:
if you set it to 0 you add the host element to the tab sequence ("sequential keyboard navigation") and you have an extra tab stop
if you set it to -1 you remove not only the host element but any interactive element inside its shadow DOM from the tab sequence, so the whole thing becomes inaccessible for keyboard users
There's a web component API just for this: ShadowRoot.delegatesFocus, see here. Set this to true and you'll get:
calling .focus() on the host or clicking on any non focusable part of the component focuses the first focusable element in the shadow DOM
:focus styles are applied to the host in addition to the focused element within
tab sequence is unchanged (it should already work the way you want)
It's supported since shadow DOM v1.
One very pragmatic approach I use, if possible and suitable, is just to put a <button type='button'> around my custom element.
This maybe does not fit as solution for you, I mention it anyway for others stepping into this question / problem.
It handles all focus matters, including a focus rectangle an so on.
To tame a <button> is less work than it seems (think especially about the line-height the button changes)

stop css target being affected by backbutton

I use the target selector to put and remove a class that shows and hides the navigation menu. The problem is that when a user uses the backbutton on the browser the menu states get messed up.
This is my css code
<style>
#buttons-container a.close-menu-primary{display: none;}
#wrap:target #mainmenu{display: block;}
#wrap:target #buttons-container a.open-menu-primary{display: none;}
#wrap:target #buttons-container a.close-menu-primary{display: block;}
</style>
buttons-container is a div with two buttons, open-menu-primary & close-menu-primary, that toggle each other on and off and show or hide the mainmenu.
The problem occurs when someone uses the back button. In that case it only toggles the button states between open and close-menu-primary, which are a burger and a close image.
You can check the live version here if you make the browser small enough or use a mobile device, screen size has to be smaller than (min-width: 768px) and (min-height: 558px) website with toggle by target selector
Hope someone can clear this up if it is possible to use target this way or if there better ways to get this affect without scripting please.
Thanks in advance!
The question is... when user presses the back button, do you want to go back one state of menu visibility (ie. hide it or unhide it), or do you want to go back one page?
I check your linked page http://www.rieon.nl. I think this is the problem:
I presume you want the user to go back one page, not just to hide the menu. Then, you need to change this piece of code
jQuery( document ).ready(function( $ ) {
$("#buttons-container a").click(function(){
$("nav").toggleClass("main");
});
});
and add either return false or e.preventDefault():
jQuery( document ).ready(function( $ ) {
$("#buttons-container a").click(function(e){
$("nav").toggleClass("main");
e.preventDefault(); // use either one
return false; // of these lines
});
});
The problem is that by clicking on the link on navigation button, browser executes the javascript handler that shows the menu AND navigates to link's href address (which is #wrap) and that creates a new step in its history, so that when user hits back button, browser just goes back to previous state (which is usually the same page but without #wrap). By adding return false (that's jQuery speciality) or calling preventDefault() on event object (that's standard JS), you cancel the navigation and leave only your own handler to be executed.

Pop-up menu in Eclipse gets shrunk

I have a problem with the context menu in Eclipse Juno. I have a class extending the ContributionItem class. This creates menu items. Each menu item has an index. But I don't know, what value have the index to contain and how should it behave. I suppose, that it should insert items on the position. E.g. I have contribution URI:
popup:org.eclipse.jdt.ui.PackageExplorer?before=common.new.menu
Then is my fill(Menu menu, int index) method invoked with 0 as index, because common.new.menu is the first item. But always the New menu item (which is the firs one in the pop-up menu) disappears and when I'm right-clicking second time, the pop-up menu gets shrunk and contains separators and few items (including my items) only. I'm totally lost...
Note: When a resource has been clicked, the fill() method is always called twice.
Heureka! Googling for a long time have I found it. Somebody noted in one discusion, that there is also important to override the isDynamic() method defined in ContributionItem class. The default implementation always returns false. In Indigo it usually does not matter, but Juno is a bit stricter. In own contribution item is necessary to override the isDynamic() method to make it returning always true.

Flex 4 <s:Scroller> Recalculate Range?

I am building a Flex 4 application which uses a <s:Scroller> component to vertically scroll overflown content. Let me explain what happens before I ask my question:
The body of the page is loaded from a database
Once the information has loaded, the "body" of the application (in this case the list of items you see below) is constructed
Once the list is constructed, the entire encapsulating component is transitioned into view using TweenMax, like so:
myComponent.visible = true;
TweenMax.to(myComponent, 1, {
alpha : 1,
y -= 20 //Slides the component up 20px from its original location
});
Below is the result. Notice how the scrollbar is scrolled the whole way down, but you can see the tips of a few white letters that were cut off at the very bottom.
Using my custom menu, I can navigate away from the page, and come back to it, and Flex will correctly recalculate the range of the scroller so I can scroll down and see all of the desired content. This issue only happens if the initial URL that the user enters is a longer page like this one.
Any ideas on how I can force Flex to recalculate the range of the scroller?
Thank you for your time.
Ok, after many hours of researching, piecing together, and trial and error here is what I came up with.
What I was doing wrong:
When I first posted this question, the "component" that I had mentioned was already added as a child element of the <s:Scroller>, but collapsed and hidden away, like this:
<comp:MyComp alpha="0" height="0" visible="false"/>
When the data would be loaded and the component's visual appearance would be restored and transitioned into place, like this:
myComp.visible = true;
myComp.height = NaN;
myComp.invalidateSize();
myComp.height = myComp.measuredHeight;
TweenMax.to(myComp, 1, {
alpha : 1,
y -= 20 //Slides the component up 20px from its original location
});
This method of approach didn't force the <s:Scroller> to recalculate its proper size until later, sometimes not until myComp was transitioned away and another component was transitioned into place using the same method. Even then, the size of the scroller would fit the size of the previous component, not the one that is currently displaying.
Now, what I am doing correctly:
My research showed me that anytime the addElement() method is called, either directly within the <s:Scroller> itself or by any of its children, the scroller's measure() method is called, and properly re-sizes the scroller.
Instead of placing the components inside of the scroller and simply hiding them until I need them, I dynamically created them in ActionScript, set their properties, and added and removed them as needed using the addElement() and removeElement() methods respectively. Now, as old elements are transitioned away and new ones take their place, the scroller re-sizes itself correctly.
There was one final problem that I was faced with. If the very first page the user was viewing (i.e. there was no previous component that was transitioned away and destroyed) required a scroller, it wouldn't show up.
I corrected this final issue by adding an event listener that listened for when the new component had finished transitioning into place. Inside of the event handler, I explicitly set the height of the component using this code:
newComp.height = NaN;
newComp.invalidateSize();
newComp.height = newComp.measuredHeight;
Now that the component has an explicit height, the scroller now appears, even if it is the first page.
The scroller now works as expected in all cases, and does not cut off any content or disappear when it shouldn't.
I hope that it is helpful to someone.