Skip to main content

Digital Transformation

Best Practices with JQuery and Sharepoint

I heard Eric Harlan and Mark Rackley talk about best practices with JQuery and Sharepoint

JQuery Overview

What

  • It’s that client side middle tier thing
  • It’s a Javascript utility library
  • available at JQuery.com
  • Lots of third parties libraries are available to enhance your sites

Why

  • Using it will improve your user experience
  • You don’t have to deploy assemblies
  • Windows 8 will have a lot of this type of thing built into it.

What Skills you need

  • Javascript
  • CSS
  • XML
  • CAML, CAML, CAML (did they emphasize it enough?)  CAML is the query language for SharePoint.  It’s how you query data from SharePoint lists.
  • A development background

Why SharePoint and JQuery is Awesome

It’s all about that visual wow factor.  You can get past that, “But it looks like SharePoint”  Take a long list view and put it into JQuery with pagination, etc and you are the hero.  It’s also about new controls you get with JQuery that you couldn’t do before.

  • Mark and Eric make the case that it eases development.  You can cut the time down to deploy something.  Their case is three weeks to two days.
  • JQuery allows you to do rapid prototyping.  Changing a font color is easy.  (Interesting example in this brand is king, long live CSS as the master page world)

Why JQuery and SharePoint is Evil

Because it’s fairly easy to get JQuery up and running.  Copy/Paste can cause a problem.  If you don’t understand what it’s doing in the Client Object Model and the Document Object Model then it will do things on your site that were completely unexpected.

Many blogs will note workarounds they employed on their sites.

Why it’s not working: Debugging “sucks”

  • You need to develop small blocks of functionality
  • Test it by putting in some alerts  and console.log
  • Set breakpoints and monitor the DOM via Firebug and some IE development tools

Performance……..or lack thereof.  It happens all the time.  (Note, I totally agree with this.  We had to include an extra library for >500 rows of query results because it didn’t work).  You should look at the tradeoffs. More time may give you more functionality.

Consistency……….”But it works fine on my computer. So test on many browsers.  Take into account client resources

Harm the Farm: You need to code wisely and negatively test.  Don’t be the cause of a DoS attack that’s really JQuery asking for a resource over and over and over again.  So code wisely. Do negative testing. Monitor Server Resources.

They also did a demo where JQuery did an endless loop to pull data from a list. It’s a poor decision but also an easy mistake.  They spiked their server resources within a couple seconds and had to shut down the call before it brought it down.

Best Practices

Deployment Best Practices

They are only as good as the context it’s being referenced.  In other words, take into account your world before applying it.

  1. Script your deployment options.  Folder in SPD. Use the file system.  Make external references.  The JQuery library is on the Microsoft Ajax Content Delivery Network. You may even choose to publish to and from the document library. (pros and cons to this approach)
  2. Reference options when referencing the script.
    1. ScriptLink will make sure it’s loaded at the top of the page and only loaded once. You need Visual Studio or SPD
    2. Content Editor Web Part (CEWP).  Drop it on the page and it’s there.  Easy but dangerous
    3. Custom Actions. Great for global deployments of JQuery.  Loads it on every page. It also works in Sandbox installations.
  3. Deployment Maintenance Dont’s
    1. Don’t add scripts directly to your Master Page. That’s way too much effort because the pages are hard to maintain.
    2. Don’t add scripts directly to the CEWP.  Use a content link instead. That will allow for reuse. If you or someone deletes the CEWP you won’t lose code in the web part
  4. Security.  Any scripts run with the same privileges of the current user.  In other words, you can’t get in trouble.

Development Best Practices

    1. Don’t abuse the DOM.  There are better options to load the DOM without hitting it 1,000 times.
    2. User other performance boosters.
      1. Try other libraries.  Try some custom code
      2. Avoid String conversion
      3. Minify your files
      4. Use CAML to reduce number of returns rows
      5. Only update your JQuery library AFTER RIGOROUS REGRESSION TESTING
    3. CRUD operations can come with some fun
      1. SP Services wraps SharePoint’s web services for execution
    4. The Bing SDK is pretty easy to use.  You can add it to your page with a script,  put it into a content editor web part and connect it from the address parameters in a list.

So What’s the Deal?

JQuery is now another tool in your tool kit. You don’t have to use it. Use it where it makes sense and where it helps you get your job done.

  • Don’t abuse it, you will pay for it later
  • It will add to page bloat so take that into account
  • It can slow your performance

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Michael Porter

Mike Porter leads the Strategic Advisors team for Perficient. He has more than 21 years of experience helping organizations with technology and digital transformation, specifically around solving business problems related to CRM and data.

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram