A presentation at Microsoft Build in in Seattle, WA, USA by Anastasiya Flynn
1,000 Employees 50+ Countries 1,400 Partners 18,000+ Developers (C#, .NET, Windows) We offer a web-based CMS platform. Our ‘thing’ is personalization.
Personalization
Localization - Change social buttons based on user’s country
A/B Testing - Switch between 2 CTA styles to test which one drives more click-through
Personalization - Show personalized notification based on user’s cart content
Bottom line: page composition is not known at development-time
Bottom line: page composition is not known at development-time
Client implementation vs Platform
Faster performance - Faster, more efficient DOM reloading that makes sites/apps feel more responsive; DOM updates only when needed Easier maintenance - Well-defined patterns for setting up project, components, testing, etc Component re-use - Component-based design: Representing site content through self-contained components is the norm Robust data management - Application state is managed within the framework’s data models instead of scattered throughout the DOM Ecosystem - Big community of JS devs, huge ecosystem of tools and open-source libraries
Developers control component layout
React vs Angular vs Vue
What if we could totally disconnect front-end development from .NET and Windows dependencies?
Manifest data – locally defined static files (yaml or json) created by front-end devs are used to generate a “data manifest”. Define component schemas and content for later export to DB.
Local development – Use webpack-dev-server and create-react-app’s proxy feature to spin up a mock layout service.
Develop on a Mac without a VM
Support multiple frameworks
Developer experience improvements
Solution complexity grows
“Being able to clone a repo, run npm install, and run a watch/browser syncing task and get right to work… That’s my jam! THAT feels like a modern, well done FED workflow”
Front-end devs love automation 🤖
JSS CLI (command-line interface) delivers a modern developer experience Before CLI, we deployed individual scripts to /bin Used for:
Create a new JSS app is seconds with 3 commands
@AnastasiyaFlynn
https://github.com/yargs/yargs/blob/master/docs/advanced.md#providing-a-command-module
JSS has sample starter kits for each front-end framework
Each starter is based on popular starters
Starters serve as live documentation on patterns and best practices Supporting the starters – need to stay up to date with the various libraries Starters used for e2e testing
Cypress – testing library for anything that runs in the browser
Smokey (the e2e testing bear) Custom PowerShell scripts that we created in response to having to do a lot of manual testing.
Allows front-end devs to work more independently @AnastasiyaFlynn
We started with a small number of packages A lot of manual maintenance As solution grew, we made the decision to move to a monorepo
Monorepo benefits
Monorepo cons
Lerna – a tool for managing JS projects with multiple packages https://github.com/lerna/lerna
Manage your project using one of two modes: Fixed or Independent.
lerna publish
Iterative process during Tech Preview Initiated by community feedback Wanted TS users to have an easy time consuming our libraries.
Benefits
https://community.algolia.com/docsearch/
In building our JS layer, we wanted to make sure we are building something that JS devs will actually want to use.
Intuitive to use
Empowering
Supports independent workflow
Repository https://github.com/Sitecore/jss Free developer trial https://www.sitecore.com/trial Docs https://jss.sitecore.com/docs
For years, we have been a Microsoft-first company. Our web experience platform runs on Windows, our developers are .NET developers, and our customers implement custom web experiences using MVC.
With the rise in popularity and capabilities of front-end JavaScript frameworks, we saw an opportunity to give our customers more implementation and UX options. But we faced a challenge -we needed to build a JavaScript API for front-end developers who are unfamiliar with our system and ideologies. We wanted to enable them to harness all the features of our platform without being opinionated about framework specifics or forcing them to change how they code.
In this session, I will share the journey of building our JavaScript SDK. Session takeaways:
The following resources were mentioned during the presentation or are useful additional information.
Official Sitecore JavaScript Services (JSS) documentation and Quick Start guide.
Official repository
Sample app that implements Sitecore JavaScript Services.
Free developer trial with guided learning resources.
Node.js proxy for headless CMS architecture.
Used to build CLI
Basis for the JSS React starter.
A tool for managing JavaScript projects with multiple packages.
Free search provider for your documentation.
Here’s what was said about this presentation on social media.
for free. You
can too.