JSLink distinguish between several Lists

Question

I'm rendering some lists via JS link and I want to use postRender to move some containers via jQuery. Everything works fine as long as I'm displaying just one list. If I add several list webparts with that JSLink file it screws up the DOM Ids.

Simplyfied it is something like this:

var myHash = Math.floor((1 + Math.random()) * 0x10000);

fieldJsLinkOverride.Templates.Body = function() {
    return '<div id="' + ctx.view + '-' + myHash + '">some content</div>';
}

fieldJsLinkOverride.Templates.OnPostRender = function() {
    $('#' ctx.view + '-' + myHash ).append('other stuff');
}

But I can't generate a unique hash because of course the variable is global and gets overwritten if a JSLink file is called multiple times.

Is there some kind of hash unique for every single list stored in the ctx object I can use?

Answer 1

try to bind your customization to the specific webparts. e.G. like this:

if( ctx.wpq === "WPQ5" ){
     // do custom stuff
}
else{
     // use standard stuff
}

Also the BaseViewID and ListTemplateType is important.

overrideCtx.BaseViewID = 99;

overrideCtx.ListTemplateType = 100;

More here and here.

Answer 2

As Patrick mentioned, specifying the BaseViewID and ListTemplateType in your override is important.

That works especially well when you are using different types of OOB SharePoint lists (i.e. a document library, a contacts list, and announcements list, etc.) on the same page, as they will already have different BaseViewID and ListTemplateType values.

Where it gets problematic is when you have more than one custom list on a page. Custom lists always seem to end up with BaseViewID: 1 and ListTemplateType: 100. (I have even played around with defining a custom list definition in CAML in VS, where supposedly one of the attributes you can set is the template ID, but that doesn't seem to get translated through to the LVWP on a page. See my other answer here.)

Doing conditional checks in the actual rendering code seems messy to me, so I have usually gone with the workaround Patrick also linked to, the one found here, in which basically you hijack the default SharePoint RenderListView method, and quickly switch out the BaseViewID values for the webparts on the page to match what you have set up in your rendering overrides, and then let SharePoint take over again.