What are the pros and cons of using JSLink to customize forms and fields in SharePoint?

Question

I've noticed a massive trend of users using JSLink for customization, while I've always found it to be a bit of a pain. What does the community think?

Answer 1

I use JSLink a lot, sometimes for CSR, and sometimes not, and so, from the perspective of JSLink is a mechanism to load scripts in different places, and is not directly correlated with CSR, here's my thoughts:

In the comments above @mannaggia says that for customizing forms they usually add a CEWP to the page and link in scripts from that. But why bother adding a CEWP, when you can just edit the form web part and pull in the scripts using JSLink? I've done plenty of form customization with the JSLink on my form web part set to something like

~token/path/to/jQuery.min.js|~token/path/to/MyCustomForm.js

where the "MyCustomForm.js" is doing all kinds of DOM manipulation, making REST calls to get data from other lists and render it on the form as well, you name it, but it's not doing any kind of CSR or linking in to the CSR framework.

Then on the other hand, I do use it for CSR as well, and in that sense it really handy that there is a JSLink property on fields themselves, so you can dial up your custom rendering for a particular field, and then make sure the script is linked to no matter where that field is used. You don't have to worry about "oh, what happens if a user adds a LVWP to this other site page, I'll have to make sure to add the CSR script there" because it'll be there already because it's attached directly to the field.

So I guess, Pros for me include:

• Being able to load any scripts I want to pages with LVWPs or form web parts without having to figure out how to add <scrip src="..."></script> tags in the HTML of the page somewhere.
• Ensuring that CSR scripts follow the things they are rendering around wherever they go. Or even any scripts I want loaded when, say, a certain field is present.

As far as Cons, I can't really think of any except that, as @DannyEngelman mentions, JSLink is disabled in the "Modern Experiences" in SPOnline/O365, which you might consider a problem if you've done a lot of CSR customization and you are in that environment.

In my particular case, however, I am on-prem, so JSLink is available to me.

Answer 2

Strictly speaking it is not JSLink.

You are programming CSR : Client Side Rendering and JSLink loads your CSR (JavaScript) files

It is only JavaScript your are programming with,
and you use the CSR Library/Syntax to talk to SharePoint

You don't need JSLink to load CSR files,
and JSLink can load any JS file (like jQuery), it doesn't have to be CSR code

CSR/JSlink was introduced in SharePoint 2013

So I guess it has been around for 5 years now (counting the early previews)

It never got popular with .Net heads because they (in general) dislike JavaScript.
Some MVP 'wizards' still refer to JavaScript as "rogue" scripting.

Then Microsoft created TypeScript.. which IS ECMAScript 6 (JavaScript) with some sugar on top.

And now SPFx "gurus" develop in TypeScript ... producing stupid JavaScript code patterns because they never learned JavaScript.
(learn the Array map and reduce methods if you are reading this!)

Important to know is that all that CSR stuff does not work in Microsofts "Modern Experiences"

They have disabled JSLink and UserCustomActions (in Modern Experiences) a year ago, and have yet to come up with an alternative. Latest information is that they are working on "Scenarios" and "CodeParts" to allow scripting and branding, but no-one has a clue what they mean by that.

In every presentation they repeat the words:

"We want to protect you from making [javascript] mistakes"

So I guess Microsoft still thinks JavaScript developers are morons...

---

Anyone interested in JavaScript and SharePoint must be aware of these tools:

• https://github.com/andrei-markeev/cisar

• https://github.com/tavikukko/Chrome-SP-Editor

Answer 3

Another plus for using JSLink on a view instead of using CEWPs - CEWPs on views will force the ribbon to be initially hidden, so you've got to click in the data of the list to show the ribbon. JSLink doesn't cause that.

For forms, I've used CEWPs for my scripts they're second nature to me. All my code is located in files I store in the SiteAssets library, whether I do CEWPs or CSR JSLink stuff, so editing it basically the same. CSR is more complex for me since I'm used to JQuery/SPServices type of edits - I can do those in my sleep.