I have a Panel where items are List and two Toolbars are in dockedItems. One Toolbar is hidden by default other is visible. When I click one Toolbar it gets hidden and other visible ( using setVisible function ) The problem is that I can't see the active one until I resize a window. Maybe some one knows how could I repaint it or refresh? ( tried Ext.repaint(), didn't help )
Thanks
Try calling doComponentLayout() and doLayout() on the panel object.
Most likely you will want to use the doLayout() since doComponentLayout() will also try doing all of the child components and in some applications especially where there are a lot of components, weird things would happen with doComponentLayout() i.e. information going missing, bottom toolbars going to the top, extra whitespace around edges. This was experienced in Sencha Touch 1 hence i would definitely use the doLayout() on the component or you can add a listener to the toolbar and when show event is fired you can call doLayout on it and if that does not work call it on the parent of the toolbar and that should work.
Related
I've been using #headlessui/react for a project and it's helped me be very productive! But I've found an issue where one component interferes with another. I think I've found the general area of the issue and can provide a reproduction but I want to know:
Why specifically is this happening?
What solutions might fix this behavior either as a workaround or within the headlessui/react library itself?
The Issue
When using the Popover component within a Tab.Panel component, the Popover.Panel does not behave correctly. According to the docs:
When the panel is open, clicking anywhere outside of its contents, pressing the Escape key, or tabbing away from it will close the Popover.
However, when the Popover is within a Tab component (docs) the behavior is inconsistent. For me, in Chrome, clicks within the Popover.Panel close the panel unless the click is on a button and in Safari the panel closes in all cases. Focusing the button with the keyboard allows selection though.
Reproduction
I created a simplified version of the issue in codesandbox
I think this has something to do with the Tab component capturing the focus from the Popover.Panel which in turn closes the Popover.Panel.
I added this snippet from "Console logging the focused element as it changes" to the reproduction and the Tab.Panel seems to have the focus after clicking in Popover.Panel:
document.addEventListener(
"focusin",
function () {
console.log("focused: ", document.activeElement);
},
true
);
Can anyone provide an explanation of what is happening and suggestions for simple remedies?
I can now answer why specifically this is happening and also provide a possible solution.
I was able to simplify my case a bit. This will happen whenever Popover is inside a focusable element (which Tab.Panel is). I think it's here in the PopoverRoot that whenever the activeElement is outside of the group the panel is closed.
If the Popover is inside an element with tabindex="0" then that element will be the activeElement and the panel will be closed. I updated the codesandbox reproduction to demo this without using Tab and also propose a workaround but I'm not sure if it's an appropriate solution or not.
The workaround appears to be just adding tabIndex="0" to the Popover.Panel so that it is the activeElement. Is there a reason this shouldn't be done or could cause other unexpected behavior?
Let me start off by saying I understand you should never use refs.
With that said, I think in my scenario it is very valid. Specifically I am using a window.onscroll handler and cannot simply change props in the onscroll handler. Changing state or props in an onscroll handler rerenders child componentsfar too often, which causes way too much lag.
Hence since my scenario only requires setting the style of an element on scroll, (i.e. I make something sticky to the top of page when it is scrolled out of view), I get 0 lag by simply setting this.refs.myelement.style.position = 'fixed'
My problem is that I am currently doing:
this.refs.childelement.refs.childschildelement.refs.childschildschildselement.refs.style.position = 'fixed'
Basically I have my onscroll handler 3 parents abvoe on the actual element I want to style.
My page consists of a List component. This consists of ReadOnlyOrEditable components. Editable components are RichTextEditors which have a Toolbar Component. It is this Toolbar that I need to set the position to fixed when a window scroll event occurs.
Hence on a page I'll have some 10 ReadOnlyOrEditable components, of which maybe 5 are RichTextEditors, each having a Toolbar.
The toolbar has buttons like italics, bold, etc.
When the user scrolls down, we don't want the user to have to scroll back up if the toolbar goes out of view. I.e. so we want to set the position to be fixed if the toolbar goes out of view so that the user can hit italics / bold / etc. immediately.
So how do I make this nicer without having to pass refs from the top down? The way I currently have it is very ugly...
I prefer to keep the onscroll handler close to the location of the list because having window.onscroll handlers in each Toolbar component implies I am setting multiple window.scroll handlers which is unnecesary work on the browser.
Any suggestions is gladly welcome.
Like everything, I believe there are many ways to solve one problem and here's how I would tackle it.
I would abstract the responsibility of registering/unregistering to a node scroll events and firing custom events at predetermined positions to a "service".
The scrollable component or the app container (List component?) would be the glue between the scroll notification service and its children
The scrollable component would pass in a custom registration function to its children via props. This custom registration function would receive the node (Toolbar) to monitor for positions and a callback to set/unset position fixed
The children (RichTextEditor component) would call the function (e.g. onRegisterPinableToolbar 😁) on componentDidMount with the node from ReactDOM.findDOMNode and a callback that the child can use to modify it's node style.
Notes:
Of course you would also need to to cleanup on componentWillUnmount.
Don't know much about your application but I would try to create a HOC for the Editor, e.g. PinableToolbarRichTextEditor
By abstracting the register to scroll events to a service you can optimize using requestAnimationFrame, and provide fallbacks for older browsers.
The function passed to the children would look something like this (node:Node, setPinability:Function) => unregister:Function
I know the naming pinability is not the best 😶
Instead of trying to get a ref to a deeply nested component, pass down the 'fixed' state as a prop, and let the great-great-(great?)-grandchild check the property and set its own style.
I have two forms that have to use the same IDs, etc. however, one is specifically for mobile viewing and the other for everything else. I am using media queries and display: none to show/hide each, but of course they are both technically still coded ON the page, which means neither of them work. So instead I am trying to think of a way to totally remove the element based on screen size. It has to be actually removed and not simply hidden.
I'm stuck and I need to get the site migrated by tonight. Any suggestions would be most appreciated!!!
Use the jQuery solution here to add a 'resize' event listener to window:
jQuery on window resize
In your event handler check the screen size (Get the size of the screen, current web page and browser window)
Use jQuery remove() to remove the element http://api.jquery.com/remove/
then append() to add the new one: http://api.jquery.com/append/
(only remove and add elements when changing from one size range to the other, not on every window resize)
I am using a bootstrap popover on svg elements in D3. Multiple popovers can be open at any given time. What I would like to know is how to, on clicking on a popover at the back, to force it to move to the front i.e. being focused on?
Is there any way to increment the z-index of an individual popover to move it forward manually?
Thanks.
Edit:
I have managed to create a fiddle using the suggested answer. The problem arises that, with using the global variable, it increments the z-index correctly on the most forward popover, but after bringing one to the front I am not able to access the others i.e. to even click the ones behind...so the click handler is not even being called. I'm thinking there is some type of layering going on. For example: If you look at the children nodes and click on one (the link in the title of the popover), then click on another one to semi-overlap the first open one - click the one behind and it will move forward. Click the one that is now behind and nothing happens:
jsfiddle.net/Sim1/YME9j/9
Is there an alternative to incrementing the z-index to bring a popover forward without hampering interaction with those that are behind it?
You should be able to do this in a click handler:
element.on("click", function() {
d3.select(this).attr("z-index", d3.select(this).attr("z-index") + 1);
})
As #AmeliaBR pointed out, this won't really work if you have more than one popover though as the z-index is only incremented by one. In a case like this, you could have a global variable that keeps track of the maximum z-index and use that.
I'm using JQuery Mobile to create a tree by using nested collapsibles. As with any treeview, a parent may or may not have any children. In my current approach, collapsibles that have no children are still collapsible, alltough the collapsible part is empty as there are no children. This results in a very ugly UI. What I would like to have is a way of turning off the behaviour of expanding the collapsible, yet being able to turn it on on collapsibles that do have children.
I've already tried different solutions, like the one being discussed here. It uses a very simple piece of code to disable the collapsing effect:
$("#page").live('pageinit', function(event) {
$(".ui-collapsible[data-allow-collapse=false]").unbind("expand collapse");
});
But that solution has the opposite effect: he is looking for a non-collapsible section while I'm looking for a non-expandable section. Just editing the answerers jsFiddle page (which can be found here) to reverse the effect creates very strange effects.
I've updated that jsFiddle to show you what happens. You will notice that once you click on the last element in the collapsible-list (Section 4) it will automatically collapse all the above elements (except for the first element, as this one has the property data-allow-collapse set to false. This seems strange behaviour to me, as it collapses all elements while clicking on a different element.
Is there any way to fix that behaviour or should I take a completely different approach? All I basically want is a property like data-allow-to-expand, and if that is set to false nothing happens after clicking on that specific element. When set to true, it should expand as it would normally.