I am implementing a recursive component that displays tabs and uses visibility to show only the active content. I choose this approach because the tab contents are expensive to generate and to layout from a DOM perspective.
based on this, i see that when i hide a tab, the nested child tabs are still visible.
I am thinking that the best way to handle this is by creating a set of css classes:
p-visible
p-visible-hidden
This way, I can recurse through the DOM elements when a tab is set to hidden and change any elements having a p-visible class to having the p-visible-hidden class instead. Similarly, when a tab is set to visible, i can switch all of the elements that have the p-visible-hidden class to p-visible.
So I'm wondering the best way to implement this in Angular2 - To me, the best way maybe to actually select the child DOM elements.
Thanks in advance for any help :)
test harness for component
tab layout component
I was able to solve the problem by creating an #Input boolean (called parentVisible) that indicates if the parent is visible or hidden. This property is cascaded down through the recursive hierarchy of components.
The parentVisible boolean is an additional filter on setting each child element's visibility (if parentVisible is false, the visibility is set to hidden, if parentVisible is true, then set the visiblity as before)
This strategy makes it possible to avoid direct DOM manipulation which is deemed good for unit testing and doing things in the Angular2 way :smile:
Related
I'm going to simplify my problem a bit, because I really want to avoid adding a lot of code, because this is a gigantic project we are working on if I started adding code snippets, there would be a lot of it.
My project has one feature, where you have a list of different div elements in the left column of the page, and they can be individually dragged to the right column, where you can make your own list out of these elements in the order you choose.
These div elements are all the same child component. My task is to add a dropdown to these div elements, but only to the ones that have been dragged to the right column (you can choose additional preferences, once it's in the right column). It shouldn't be there on the divs in the left column.
The only way to differentiate between them is by the class name. The ones on the left have a class="left" and the ones on the right get the class="right".
Now I'm wondering if there's a way where I can write some code to the effect: if the element has the class 'left', hide the dropdown, else show the dropdown?
Yes, this is definitely possible.
Create a Directive that has a #HostBinding() for a specific class and just add the directive to every component.
Inject ChildComponent into the constructor of that Directive. You can also inject ViewContainerRef and then call this.viewContainerRef["_data"].componentView.component This will give you reference to that child element that the directive is put on.
Once the #HostBinding('.left') event handler is triggered this will be the function that gets called when the class you're looking for is added. Here you can then access that ChildComponent and then presumably call a method on that child component to show/hide the mat-select
I haven't actually tested this but thats the approach I would take.
You might also achieve this thru your css. Something like
div[class*="left"] dropdown-element {
display: none;
~or~
visibility: hidden;
}
I am using a MDC Radio Element so I thought I would wrap it up in a nice little <mdc-radio name="the-name" value="the-value"></mdc-radio>.
Everything was going well, but then I realized when I use it multiple times w/ the same name attribute...
<mdc-radio name="the-name" value="the-value-1"></mdc-radio>
<mdc-radio name="the-name" value="the-value-2"></mdc-radio>
.. it does not toggle the other selected mdc-radio with the same name. I assume it is because the radios are in two separate shadow dom containers. Is this correct? is there a way around this behavior?
dang... that was a dumb question. I assumed using Shadow DOM was required for Custom Elements, but it isn't. Just appending the MDC Radio markup to this inside of the constructor for a HTMLElement did the trick
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.
In HTML we can create an element of type hidden, is it possible to create a similar element in flex-mobile ?
You can hide elements from displaying on screen by using the visible property and setting it to false
You can prevent elements from being included in the layout scheme of their container by using the includeInLayout property and setting it to false
You can also hide/show elements based on states.
Since you haven't provided any context for what you want to do, it is tough to direct you to a specific approach.
I want to create an MXML container component that has some of its own chrome -- a standard query display, et al -- and that supports the addition of child components to it. Something a lot like the existing mx:Panel class, which includes a title label, but acts like a plain mx:Box with regards to adding children.
What's the easiest way to do this?
Edit:
To be clear, I want to be able to extend the container using MXML, so the "Multiple visual children" problem is relevant.
Extend a container and add a title label. Probably the <mx:Canvas/> will work here. Make the title a public var and include a var for the styleName of the label.
Then override the addChild() method so that any child that is added is added instead to the that is your container.
Leave enough space for your title when you position your Box element (i.e., give its y property enough space. If there is no title you may want to reclaim that space.
That's the basics. Customize to your heart's content.
EDITED TO ADD: I do this creating an ActionScript class first, extending the container I am targeting, and I add the "furniture" — items the class will always use, like title in your case — by overriding createChildren and calling super.addChild(item) for those items. Calling addChild from then on, even in MXML markup, adds items to the inner container.
We do this with states.
We put the chrome for the base container in a state (in mx:AddChild elements) and then use the initialize event to switch to that state when the control is created. All the chrome is then added to the container.
That gets round the multiple sets of visual children problem.
The downsides to this approach are:
You don't see the chrome when editing descendents of the base.
You can't directly access the parent chrome controls from descendent components as they are not there at compile time (instead, you need to define properties, methods or events on the base that the descendents can access)
However, it works well for us.