Skip to main content
Nintex Community Menu Bar

Would be super-helpful!

Yup.  I can see that. 


I know you probably hate this question…

any idea when Planned might become Implemented?


Looks like Matt beat me to the punch on this one - Conditional Rendering of menu items would eliminate a lot of custom code that we currently have written to manage our menu system.  

Please please please 🙂  and thank you!


Yeah, this is a no-brainer. Working on it!


Awesome news, thanks Ben!


Yup. As Ben says, “no-brainer”.


Working on it to be part of a patch?


Bugs are first priority, then it’s on to these things!


This looks implemented but I see empty spaces where those items “would be”.  I have different rep types and render a group of Nav Items for 1 and a different one for the other. The nav bar breaks up or has empty spaces when logged in as someone with sections not meeting render criteria.


Acknowledged?



That shows all of the blank spaces and a Nav item going to another row when there’s plenty of room to slide into the first row.


Joe, I just submitted this to our dev team. So, yes, Acknowledged. Thanks for the bug report!


Hello, Would there be any ETA for this bug to be fixed?

I’m wondering , as right now it’s affecting us as well, and would like not to have to create a Different navigation menu for each role…

Thx


Sorry this is still outstanding.  The conditional rendering works,  but there is evidence of the hidden piece remaining behind that looks weird… 


Hey Rob … did this bug fix get a guernsey for Rockaway?


This reply was created from a merged topic originally titled unrendered nav component items cause wrapping/css problems. I thought I saw another thread about this a while ago, but I couldn’t find it again. Sorry if this is a repeat.

This seems like a pretty simple fix, guys. Right?


Matt,

Thanks for pointing this out. Our devs are aware of this and we’ll let you know when this is fixed in a future release.

Thanks!
Amy


Hey friends, since Skuid is taking it’s time to get a fix out for the conditional rendering bug, you can use this inline script:


(function(skuid){ var $ = skuid&#46;$;<br /> $(document&#46;body)&#46;one('pageload',function(){ $('#<b>MyNavComponentId</b>')&#46;children(':empty')&#46;remove(); }); })(skuid); 


 Just be sure to change MyNavComponentId to the unique id of your nav component. Alternatively, you could use something like


&nbsp;$('&#46;sk-navigation')&#46;children(':empty')&#46;remove(); 

to handle all navigation components instead of a specific one.


Thanks Matt! I just wrote something for this yesterday, although mine was much less efficient. I used an $.each loop and ‘this.getAttribute(“data-rendered”) == “false”’.


Matt/Craig - In general, removing DOM elements that Skuid adds could lead to undesired behavior in some situations. In this case, you should be OK since it’s a DOM element inside of the component itself. With that said, rather than use Javascript for this, you should be able to accomplish the workaround with pure CSS. Try one of the following: 1) To hide all empty DIVs with any navigation component .sk-navigation div:empty { display:none; } 2) To hide all empty DIVs within a specific navigation component (Specify a unique Id on your Nav component - in this case its called myNav) #myNav div:empty { display: none; }


Thanks for the information Barry. My JS snippet actually added a CSS class that has display:none in it. A much less eloquent solution than yours - but it did the job 🙂


Thanks for sharing this workaround Matt! 

Karen


This issue has been incorporated into Rockaway Iteration 13 and is now available from the Skuid Releases page at http://www.skuid.com/skuidreleases. As a reminder, Salesforce does not allow reverting back to prior versions of managed packages. Skuid always recommends installing new versions in a non-business critical sandbox environment to test all mission critical functionality before installing into a production environment.

Thank you for your patience while we worked to implement this. 

Mark