This document provides an overview of lessons learned from building products on SharePoint Modern. It discusses SharePoint Framework architecture, localization strategies, versioning approaches, challenges of supporting older browsers and environments, and the importance of testing. Key recommendations include using semantic versioning, sharing common code via libraries, automating releases through CI/CD, and testing across different environments.

1. Things I've learned while
building a product on
SharePoint Modern
Elio Struyf- @eliostruyf
Solu?ons architect @ Valo Intranet

2. Kiitos, thank you our dear sponsors…

10. Architecture overview
JavaScript, HTML, CSS
à SharePoint Framework
Web Parts Extensions
Client-Side SoluCon Driven
Key vault
Functions
All back-end logic lives here

12. Channels to follow
• hIps://www.microsoM.com/en-us/microsoM-365/roadmap
• hIps://developer.microsoM.com/en-us/office/blogs
• PnP Community Calls: hIp://aka.ms/sppnp
• hIps://techcommunity.microsoM.com/t5/SharePoint/ct-p/SharePoint
• hIps://azure.microsoM.com/en-in/updates/

13. Let us talk about building
things

14. SPFx runs in the context of
the user

16. Azure Functions tips
❗ Don’t forget to secure them with Azure AD
❗ You’ll be using app-only permissions
• Check the SharePoint permissions on both ends
❗ Try to create a messaging system
• Users will not wait > 10 seconds
• Queues great for this in combinaCon with Queue Triggered funcCon
• Create a HTTP Message Broker à creates the queue message

17. Naviga?on

19. Checks that we have in place
✓ Check page URL
✓ Check list ID + item ID
✓ Check the HubSite ID
✓ Check the current UI language
✓ Check if you are creaCng a new page
Depending on the change:
- ApplicaCon customizer reloads
- Page refreshes
- Component updates
- AborCng calls
hIps://elst.es/building-product-1
hIps://elst.es/building-product-2
hIps://elst.es/building-product-3

21. SPFx localiza?on story
• Each web part / extension has its own localizaCon file
• /src/webparts/<your-webpart>/loc/<locale>.js
• Developers must maintain these files
• “Easy” for 1-3 languages à updates need to happen in each file
• Harder when you need to support +20 languages
• It is JS, things can go wrong!

22. SPFx localiza?on solu?ons
• Create the localizaCon files as TS files à Catch issues during build
• One global localizaCon file
✅ Easy to maintain
✅ Sharing localizaCon keys is easier
❗ Developer must sCll maintain it
• Use an extension - h"ps://elst.es/vscode-localiza3on
✅ AutomaCcally add entries in all locale files
✅ Generate a CSV file that can be owned by someone else
• Create your own system

23. How we do localization
CI CD
Global localization
project provided as
a library component
Excel file is maintained by
our localizaCon master
Retrieves XLSX +
Export new keys +
Generates locale files

28. Mul?ple projects
✅ Faster build Cmes
✅ Easier to debug
✅ Lower impact when you need to do a hokix
❗ Watch out for code duplicaCon
❗ LocalizaCon
❗ Packaging and installaCons
❗ Project management -> Check out monorepo (Lerna)

29. Think about sharing common
logic

30. Sharing common logic
• SPFx library component
✅ OpCon for sharing code between projects
❗ Only one library component version can be used
• Private npm dependencies (Azure ArCfacts)
✅ Each project can use its own version
✅ Not SPFx specific
✅ Will work for classic and on-prem projects
❗ Could lead to larger bundles (talking about KBs)

31. 1.0.0.0

32. 1.2.3.4

33. 1.5.2.1

34. SP doesn’t care

35. Solu?on versioning
• Update version in package-solu,on.json
• The version only applies to the feature framework and SharePoint
feature defini,ons
• Code and assets will be updated as soon a new version is uploaded

36. My preferred versioning approach
• Use seman,c versioning to align with your dependency versions
• Keep control over your version by manually updaCng them
• If you want to automate, update the label (you can use the build nr)
• Update version in package.json (caching in Azure DevOps – future)
• Sync your version numbers (hIps://elst.es/spfx-versioning)

37. Challenges

38. The one that doesn’t want to die

39. Suppor?ng IE11
❗ Speed is the biggest issue
❗ Slow due to all the polyfills required (ex.: fetch)
❗ SPFx memory leaks (1,5GB aMer two minutes)
❗ Styling

40. Suppor?ng classic
❗ Not everything is supported
• Dynamic data
• No applicaCon customizers
❗ Speed

41. Suppor?ng on-premises

42. Are you alone?

43. Are you the only third-party on the tenant?
✅ If you don’t do DOM manipulaCons, you should be OK
❗ Watch out with AadHIpClient
• Shares permission scopes
• You are not in control
✅ Use isolated web parts (>=1.8.0 SPFx)
✅ Use your own Azure AD App if you want to be in control
• Use the AadTokenProvider

45. It’s not always your fault

46. Tes?ng is THE most
important thing

48. hIps://elst.es/puppeteer-devops

49. Automate as much as you can

50. Automate your releases
CI CD

51. The full story
• We push everything immediately to our shared-DEV environment
• We do nightly provisioning
• Flush the whole environment
• Reinstall all components
• Azure AD Apps
• Azure FuncCons
• SharePoint sites
• Deploy SPPKGs
# PnP PowerShell

53. Things to consider
❗ Flat site structure are great, but …
• Lots of cross-site collecCon calls à calls cannot be batched
• Have a good caching story
❗ Watch your bundle sizes
• Don’t be blinded by it
• Have a good CDN or use the Office 365 CDN (client-side asset packaging)
• Browser will cache files à biggest impact on cold load
❗ Test on different environments

54. Ques?ons?

55. Office Servers & Services MVP
Azure / Office 365 / SharePoint
@eliostruyf
www.eliostruyf.com
elio@valointranet.com
Elio Struyf
Solutions Architect at Valo Intranet