Read Aloud
Text Size
SharePoint • PnP • Practices and Patterns
As we promised, we are going to continue with our SharePoint series. In case you’ve just discovered our blog, we at Share IT are big fans of SharePoint. If you take a closer look at our content, you will see that we have already covered lots of SharePoint-related topics.
We wrote about the benefits that SharePoint brings to businesses across multiple industries, we compared the platform with similar tools, discussed specific features, and even created a beginner’s guide that can help newbies understand the basics of SharePoint.
The reason why we write so much about this specific product is simple: we believe that SharePoint is an extremely powerful and highly-customizable web-based collaborative software that has no true rival on the market.
As a software development company that usually creates software and apps for enterprise-level companies that are in need of better document organization and process optimization, our experience has shown that SharePoint is the perfect ally for this sort of work.
Of course, like any other pieces of software, Microsoft’s SharePoint has its good sides and bad sides. Yes, SharePoint is a highly-customizable piece of software, but it can be quite difficult to setup and maintain if you’re not sure what you’re doing. Things get messy really fast and the maintenance part can easily become a total nightmare.
Luckily, SharePoint pros stick together like white on rice, and even the most inexperienced developers can get their hands all the knowledge they need by accessing SharePoint PnP.
SharePoint PnP (Pattern & Practices) is best described as an initiative that includes samples and guidance on how to transform your full trust code solutions to the add-in model.
In layman’s terms, SharePoint PnP can be interpreted as a community open source project that is runned by SharePoint engineers who do their best to develop valuable SharePoint documentation, store samples and lines of code which their fellow SharePoint enthusiasts can use to build their own custom solutions.
Even though the PnP initiative is coordinated and owned by SharePoint engineering, the work itself happens with the community members. Without the community reaching out, this wouldn’t make any sense. Everything is open-source and available for use. In addition, SharePoint developers are encouraged to report issues regarding APIs, documentation, or anything else. With so many expert eyes, the chances of missing something are at minimum.
Under PnP, there is a:
The community of developers is typically very open to sharing lessons, tips, and tricks with the world. This type of knowledge transfer matters because it helps the industry move forward. When communication and collaboration is enabled, each individual professional gets the support they need.
Especially when it comes to complex projects, developers might invest a lot of time on building something from scratch. However, if the foundation of the project is not properly set, they might need to start all over again.
SharePoint PnP prevents this from happening. It’s like a live encyclopedia that is continuously updated with new findings and case scenarios, so you can always turn to it and consult with the expert contributors.
More importantly, SharePoint PnP functions like a well-managed knowledge base. Namely, the core team works closely with Microsoft and ensures none of the offered code improvements and solutions are flawed or insufficient. This is how each member can rest assured they are getting access to the refined, authentic, and practical SharePoint knowledge.
Plus, the community commits to providing a welcoming and useful environment for all and it functions under the Microsoft Open Source Code of Conduct.
Anyone who’s in development knows how the cookie crumbles: as you develop new projects, you will encounter situations you’ve already dealt with, and you’ll definitely find yourself facing completely new challenges. This is also true for SharePoint and Office 365,
The good news? You can save your time and energy by browsing through solutions in the git repositories. For example, if you want to introduce automatic deployment into stages of app development, there are ready-to-use solutions available thanks to the SharePoint PnP community. If you need to build custom solutions for your customer using SPFx, you can find helpful resources in a jiffy.
The SharePoint PnP team has also created a simplified javascript library called SharePoint PnP.js. This library is useful for both beginners and advanced developers and it requires a lot less coding compared to traditional JSOM and REST API. For instance, you can use it to create lists, accounts, libraries, etc.
By getting people to share their learnings and contribute to GitHub repositories, Microsoft has cleverly decreased support costs, and increased customer satisfaction and retention rates. Since people can frequently talk to each other and selflessly share their best work with one another, it's safe to assume that they will have a much better understanding of SharePoint than some other product that doesn’t have such a knowledge-sharing culture built around it.
All the bugs are fixed by people who don’t have the time or will to wait for someone else and come do the job for them. The content is also user-generated. Plus, Microsoft has multiple active places where they can closely follow customer feedback and learn from their actual customers how to make their product even better.
In addition to all this, when you have such an engaged community - it takes you a lot less money to market a new product because you already have your potential buyers grouped in a single place where they’re basically waiting to hear from you.
You can contribute to SharePoint PnP by creating new samples, fixing bugs in existing code, and updating documentation. If you want to fix bugs and create new samples, select a GitHub repository, look at the “issues” options, and try to tackle one that you think you can manage.
The typical way if tackling an issue in GitHub is to fork the repo, make your changes (in a preset environment), and then send it back via a pull request. Simple, right?
If you don’t know how to setup your environment, follow this instruction.
The document contribution works a bit differently. First, you need to visit docs.microsoft.com. In order to add or change documentation you need to alter the source code of a cmdlet. If you want to modify documentation or add an example of a cmdlet, navigate to the corresponding class where the cmdlet is being implemented and add the comments there. You can find a more detailed explanation here.
