5 Things SharePoint Client Side Developers Should Stop Doing Immediately (4/5)

Posted by: Mark Rackley on February 16, 2017

…in order to prepare for Modern sites, pages, and the SharePoint mobile application.

Welcome back! We made it through yesterday talking about why you shouldn’t modify SharePoint’s default forms by injecting script fairly unscathed. Good job everyone! :) Here we are at Day 4. Today we are going to talk about a subject near and dear to my heart, but also something which you should definitely approach with more caution if you want to have an eye towards the future.

If you plan on adopting modern sites, pages, and the SharePoint mobile application you should really show more restraint around…

Manipulating the DOM

If yesterday’s post stung, this post downright hurts. I’ve been using jQuery in SharePoint since 2009 to bend SharePoint to my will. Placing Web Parts in tabs, hiding navigation elements, light branding, and totally making SharePoint do what I want it to do… I was unstoppable. Some of my most popular posts dealt with doing just that:

The main problem with manipulating the page is that developers have gone crazy, hiding things like essential navigation elements and the Office 365 ribbon. These are critical elements that enable you do things like… edit a page… get to site settings… site contents… and get to other important Office 365 features. Yeah, your page may look like you want it to look, but you can’t actually DO anything. Going crazy on DOM manipulation has been frowned on since the dawn of Office 365 because we no longer have control over when new features are rolled out. Microsoft could (and have) rolled out changes in Office 365 that break your DOM manipulation.

This becomes even more critical if you want to take full advantage of new SharePoint mobile capabilities. If you aren’t careful you could completely destroy the mobile experience (and how many of you forget to test mobile when you make changes? Come on, be honest). Plus, at the rate of changes going on, just because something you wrote worked last week doesn’t mean it will work tomorrow. Microsoft is trying to do a better job of giving us rules and guidelines to follow when it comes to customizing our pages as well as giving us new tools to make these changes. Play by the rules and your life will be easier, and more supported.

Instead you should…

Yes, you can still inject script on new modern pages (we’ll discuss that tomorrow), but just because you can doesn’t mean you should. There’s really no workaround here. You need to avoid manipulating the DOM wherever possible if you plan to go to the new modern pages and sites.

Don’t get me wrong, I’m still going to try and reproduce my tabbed web part functionality for a modern page. However, you can’t assume just because it’s on the page you can do whatever you want to it. Be very careful with any changes you do decide to make and test to make sure you don’t break the mobile experience.

Bottom line, don’t rely on DOM manipulation to do your job.

We’re almost there! The end of our five-day journey! Thanks so much for sticking around this long. Join us tomorrow as we wrap up and talk about the 5th thing you should stop doing to prepare for the future of client side development in SharePoint.

 

Topics: SharePoint, Office 365, JavaScript

    Recent Posts

    Categories