Does jQuery work differently in Flare 2017 R2

[rogersm]

Hi all,

I had a small jquery script in the previous release of Flare but I have just noticed that it is not working anymore. Does anyone have any idea if you need to do something different when referencing jquery in Flare 2017 r2? The script is included in a master page and is as follows:

Code: Select all

 
<script>
 <script>
$(document).ready(function() {
       $('a:contains("Home")').remove();
});
</script>

[NorthEast]

It hasn't really changed - maybe you don't have a link that contains "Home" ?

[rogersm]

It looks like jQuery does work in that this script will remove Home links, but previously this script was able to remove a Home link that displayed in one of the menus in the top navigation area.

[KayJay]

This has indeed changed in 2017r2 - I have some small scripts that manipulate the output of a menu proxy using $(document).ready() like you and find that jquery scripts are executing before the new MadCap JS that dynamically generates parts of the page.

In this new release the menu proxies (and perhaps your home button) are no longer static elements in the page, rather they are generated by MadCap's JS and inserted on the fly. I'm not sure in which order they execute, but it's after document.ready(), so any old scripts now execute before the elements they should work upon exist.

For instance, instead of a full list with li's and links, in the source of my page my TOC now looks like:

Code: Select all

<ul class="nocontent menu mc-component" data-mc-linked-toc="Data/Tocs/ByModule__Reporting.js" data-mc-side-menu="True" data-mc-max-depth="2" data-mc-include-icon="False" data-mc-include-indicator="False" data-mc-include-children="True" data-mc-include-siblings="True" data-mc-include-parent="False" data-mc-toc="True">
</ul>

so my code changing the list items has no effect because when it is executed they do not yet exist.

I would suggest you use CSS to hide your element as that will apply to any dynamically-generated elements when they are created.

If anyone else knows how I can delay my jquery script to work after Flare's new javascript runs that would be great...

[NorthEast]

It looks like jQuery does work in that this script will remove Home links, but previously this script was able to remove a Home link that displayed in one of the menus in the top navigation area.

From 2017r2, all the menus and navigation (top nav menu, menu proxy, bookmarks) are generated at run time. In previous versions they were added to the topic at build time (i.e. they're actually in the output HTML topic file), but from 2017r2 they're added at run time by MadCap's scripts.

Your script isn't working because it's being run too early - at the time it's being run, MadCap's scripts haven't yet generated and added those menu links to the page, so there is no "Home" link (yet).

To get your script working, it would have to be delayed to start after MadCap's scripts have finished. However, I don't know of any way to detect when MadCap's scripts have finished.

[NorthEast]

If anyone else knows how I can delay my jquery script to work after Flare's new javascript runs that would be great...

Posted my reply before seeing your post.

I had a look at this for my own menu customisation. I got as far as looking at MutationObserver to detect changes, which looks very promising and could detect changes in parts of the DOM. My JS knowledge wasn't good enough to do the job properly though, so in the end I just avoided using scripts altogether and went for a pure CSS solution.

[KayJay]

Sadly I'm also coming to the conclusion that I will have to use a CSS-based solution.

For anyone else like me using JS to target Menu Proxies, it can sometimes be cumbersome to construct the right CSS selector if you are trying to target something really custom or arbitrary in a long list (this is why I was using JS, for changing elements based on e.g. their title etc).

One workaround I'm now using is to add some TocEntry styles on a new Skin in the Skin Editor. When these styles are added on the TOC item (Properties > General > Style Class) they are passed into the HTML output as classes, which you can then use to style this individual element, instead of relying on selectors like :nth-child(k) which are brittle when you change your TOC down the line.

Of course, it would be great if menu proxies passed even more information into the HTML (like conditions, so you could dynamically show-hide links like inline conditions). I've made a feature request, but this will do for now.

[NorthEast]

Of course, it would be great if menu proxies passed even more information into the HTML (like conditions, so you could dynamically show-hide links like inline conditions). I've made a feature request, but this will do for now.

For one of my projects, we have 2 versions of the application, and can dynamically show/hide content for each version. It's triggered by the the application including a certain parameter in the URL, and when we detect this we use a script to add a particular class to the html tag. That means we can set up the CSS to show/hide content for each version of the app. For menus, we actually include 2 menu proxies in the page, and the CSS will hide the one we don't want to display. Like yourself, I'd prefer things like conditions to be included with the items in the menu proxy, but this is the best we can do for now.

[Psider]

I had an issue where I needed to hide content after scripts in another tool (coughrhcough) finished running. What I came up with isn't ideal, but generally works.
Disclaimer: I have no idea what I'm doing and just cribbed from various websites, so feel free to tell me this is a terrible idea and why.

What I think this does is check if the page has finished loading and if not waits 700 milliseconds then tries again. This seems to be long enough for the other scripts to finish, although the content to hide does appear briefly before my script runs, but it doesn't seem to be long enough to annoy my users at this stage (and in my case I don't expect users to access this particular function too often as it's tied to one specific link).

var interval = setInterval(function() {
if(document.readyState === 'complete') {
clearInterval(interval);
ProcessTopic();
}
}, 700);

[rogersm]

Thanks very much all, looks like CSS is the easiest option to work around this.

[chrisj]

It looks like jQuery does work in that this script will remove Home links, but previously this script was able to remove a Home link that displayed in one of the menus in the top navigation area.

From 2017r2, all the menus and navigation (top nav menu, menu proxy, bookmarks) are generated at run time. In previous versions they were added to the topic at build time (i.e. they're actually in the output HTML topic file), but from 2017r2 they're added at run time by MadCap's scripts.

Your script isn't working because it's being run too early - at the time it's being run, MadCap's scripts haven't yet generated and added those menu links to the page, so there is no "Home" link (yet).

To get your script working, it would have to be delayed to start after MadCap's scripts have finished. However, I don't know of any way to detect when MadCap's scripts have finished.

I've had success with

Code: Select all

$(window).bind("load", function () { ...... });

[NorthEast]

In Flare 2017r3 there's a solution to the problem of detecting when the menu proxy is ready (is populated with menu items).
See: viewtopic.php?f=9&t=21607&p=129366#p129366