Example plunker:
http://plnkr.co/edit/YLLslImGOpS8u6zx
In the plunker, I display the height and width of a div from the parent component using ViewChild.
I pass the div from the parent component to the child component as an Input HTMLElement, and in the child component, I again read the currentValue of this input. If you open the browser console, I logged the SimpleChanges object. If you look at the currentValue.offsetHeight, the height is the expected value (i.e. the value matches what the parent component is displaying)
However, the child component is displaying a different value from the expected.
Whats even stranger is if you edit the child component template to something like:
<div>
<p>Child: {{ display }}</p>
</div>
Simply adding some additional content in the div, the child component now displays the expected value (i.e. the value matches what the parent component is displaying, and it matches the value in SimpleChanges)
To put it simply, why does this difference occur?
In my code-base, I'm experiencing an issue using offsetHeight where the value within SimpleChanges is accurate, but the value I try to store on an instance variable and use within the component is inaccurate. This plunker probably does not emulate exactly the issue I face in my code-base but maybe understanding the cause/effects of what I described above might help me figure out the problem I face in my code-base.
Thanks!
Related
In the Angular 11 project I need to change ng-circle-progress library CircleProgressComponent element size dynamically.
I have found out, that size of the element can be changed by putting width/height CSS properties on the child DOM element - svg. Problem is that svg doesn't have any id or class values, so even if I could somehow query the element, this would be not that easy and flexible as it should be.
Would be extremely nice to have a parameter in the CircleProgressComponent, that listens to outer variable changes and re-renders the element with a new size.
I had never used this library, so I've read their doc and thier demo page.
If I understand, they have the parameter that you want called radius
<circle-progress
[percent]="85"
[radius]="200" // the size you want
[outerStrokeWidth]="16"
[innerStrokeWidth]="8"
[outerStrokeColor]="'#78C000'"
[innerStrokeColor]="'#C7E596'"
[animation]="true"
[animationDuration]="300"
></circle-progress>
I am trying to create a profile menu for my polymer website, something on the lines of github.com
If you notice,there is a triangular tip at the top of the menu.I am trying to create a similar triangle at the top of paper-listbox.
The problem I am facing is that the triangle seems to hide as soon as it gets out of the boundaries of paper-listbox.
I have create a jsbin to demonstrate my problem: http://jsbin.com/samaloqowu/1/edit?html,console,output
If you change the top property of the triangle (say -16px), it hides when it gets out of the listbox region. Please help me solve this CSS issue.
Short answer : No you can't.
Explanation : Because the dropdown content get encapsulated in a slotted element that gets styled inside the shadowRoot of the custom element you try to modify the behavior. And the paper-menu-button doesn't actually gives you a way to directly customize the slotted.
But there is a trick ! You can access the slotted through classic javascript. Just alter your connectedCallback function and add this line :
...
connectedCallback() {
super.connectedCallback();
this.$.profileMenu.$.dropdown.querySelector('.dropdown-content').style.overflow = 'visible';
...
}
...
This should do the trick, I agree this looks totally awful and trying to force and change the initial behavior of an element is not really recommended but well it seems to work, just make some tests when the element gets in a new context to see if anything breaks.
UPDATE (22/09/2017) :
Thinking of that again, I think this is a terrible idea to change this overflow to visible, I guess the polymer team has set the overflow to auto because if the list get long and you force the height of the element, the list will flow and be visible which is not really a dropdown anymore, but more like a full list display and that will mess with the general design purpose of your app. IMO when you start trying to mess with the inner properties of a custom element it means this element doesn't quench your requirement, and that it's time to make your own, especially when you try to modify the design of a custom element that has a design already implemented.
I have a search suggestion component that is displayed under a TextField. whenever text is entered into the TextField the search suggestion component displays a list of possible matches based on the current entered text... I have more content under the TextField that gets pushed to the bottom whenever the Search suggestion gets populated with results. Is there any way to overlay the search suggestions over the content underneath it instead of pushing the content down? in HTML/css I would apply the position absolute and z-index css properties to the search suggestion component but this doesn't seem to be the case in Nativescript. I see that Nativescript does support the z-index css property but just applying that doesn't seem to do anything. It doesn't look like Nativescript supports the position property... Any idea how I can make this work/what i'm missing?
You have a couple quick options. One is to use a grid as mentioned in the comments. Set the views on the same row/col. This is the same as stacking views on the z axis. Or an absolute layout and use the same positioning of the views within that layout.
Alright, i'm creating a Sketchup model but i'm confused. The parent component is not taking it's children properties correctly. Is this normal?
Never mind. I fixed it! In case other people stumble on this problem: In every child component add the attribute you want to let the parent to Sum up.. (in my case i forgot to add the attribute "LenZ" to a component at the bottom of the list). If you do not add them the parent will not sum them.
I am a little confused about the setActualSize method. It appears from what I've read, that if it is not called on a component by its parent, the component will not be rendered.
So it appears that setActualSize is a critical method that is directly bound to rendering the UIComponent. It also appears that the width and height properties of UIComponent override the functionality of the width and height properties of flash.display.DisplayObject, in that they are not directly bound to the rendering of the object but are virtual values that are mainly used by the getExplicitOrMeasured when the parent of the component calls the component's setActualSize method.
So the question are:
1) Why isn't the default behavior of every component to just call setActualSize(getExplicitOrMeasuredWidth(),getExplicitOrMeasuredHeight()) on itself?
2) I guess this question stems from the above question and the behavior as I understand it as described above: does setActualSize change the visibility of the component?
It appears that that the behavior is that a component is not rendered until setActualSize is called, but if it contains display object children itself (expected behavior as it can calculate measure on itself) and is added to the display list, the only reason why flash isn't rendering it, is because its not visible.
The answers to your questions are in the way the Flex component life cycle works, consider these two phases:
measurement:
The Flex framework will call the measure() method of your component. You can override this method to set a default and/or minimum size for your component.
Flex components first measure themselves to provide a default and/or minimum size suggestion to the layout/container classes. Flex does this from a bottom up approach, so that the lowest level objects are measured first. Thus when each parent object measures itself, the preferred sizes of it's child objects has been established.
rendering:
Later Flex calls the updateDisplayList() method of your component. You can override this to size/position your component's child objects. This is where setActualSize() is intended to be used: the parent calls setActualSize() on it's child objects, not on itself.
Note the method signature of updateDisplayList():
protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
Measurement was done from the bottom up. However, rendering is done from the top down. So at render time, updateDisplayList(unscaledWidth, unscaledHeight) gets executed on your component. Flex is telling your component the space it has been allotted to render itself, and your component must size/position it's child objects accordingly and/or do programtic drawing.
The sizes passed in to updateDisplayList() are based on various factors:
how/if you override the measure() method (measure is not called when
your component has a fixed width/height)
the types of sizing
parameters (fixed, percent, constraint) and layouts that you use
An old but good resource on this topic
setActualSize() is one of the crutial and most interesting methods in Flex layout process:
1) Notice that setActualSize() is an entry point for parent's layout to set the component size, and it has to be called by parent (container) almost exclusively!
This is because only the parent knows the amount of space available for each child (this method is being called after all children are measured and the container knows it's own given size).
(note: the example of not calling it by layout posted below)
This method exists because if parent would set 'width' and 'height' on children directly, they would immediately turn into fixed size children, and they won't be measured anymore.
Using this method, only the rendering size is being changed - not the (explicit) width and height but _width and _height - meaning if for some reason the container resizes again, the children will be resized by given rules (percentage of the parent, expanding to child component's children size etc.)
2) Yes, because if this method isn't called at all, the component has a (rendering) size of (0, 0), so this is the reason of it's invisibility (not setting 'visible' to false)! ^_^
Note that THERE HAS TO BE A LAYOUT (even a non attractive one) to trigger this method call. By 'non attractive' I consider the layout that isn't supposed to do anything smart, like CHANGE THE WIDTH AND HEIGHT of children at all (like absolute layout)!
Now, look at the PopUpManagerImpl's class addPopUp() method: there is an interesting case of calling setActualSize():
IUIComponent(window).setActualSize(
IUIComponent(window).getExplicitOrMeasuredWidth(),
IUIComponent(window).getExplicitOrMeasuredHeight());
Explanation: PopUpManager does stuff that layout should normally do, because it WANTS TO KNOW THE POPUP DIMENSIONS IMMEDIATELY, so it could center the popup on stage. It has no time to wait for the layout pass!
If you comment those 3 lines in the framework code, you'll see that popup is being centered with it's top left corner - just like it's size is (0, 0). Anyway, it is rendered with proper width and height because at rendering time the dimensions are known.
Hope this makes things a bit clearer...
Cheers! ^_^
Danko Kozar