Did you know that several parts of the tools you’re using on the Salesforce Platform are open source? That you can create a LWR Community using Lightning Base Components and Lightning Design System and host it wherever you want? That you can benefit from new features being part of LWC but not yet available on the Platform like Light-DOM or dynamic components creation? And that some of your existing components can be reused quite easily?
If not, come and see how powerful Lightning Web Components Open Source are!
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Build your apps everywhere with Lightning Web Components Open Source, Fabien Taillon
1. Build your apps everywhere with Lightning
Web Components Open Source
by Fabien Taillon
2. #CD22
Fabien Taillon
- 7x Salesforce MVP
- CTO at Texeï
- Paris Developer Group leader
- French Touch Dreamin team
- Serial speaker
- Not so serial blogger
@FabienTaillon
https://texei.com/blog
3. #CD22
● What’s Open Sourced at Salesforce
● What’s available as a public package
● What can be done
● Let’s build something with Lightning Web Runtime
● Demo
● Differences between OSS & Platform
Agenda
4. #CD22
A whole site dedicated to OSS (open source software):
https://opensource.salesforce.com
Some OSS Projects:
● Lightning Web Components
● Salesforce Extensions for VS Code
● Salesforce Lightning Design System
● oclif
● TransmogrifAI (automated machine learning)
● …
Not something new, Aura was already open source.
What’s Open Sourced at Salesforce
5. #CD22
Some other projects are not open sourced, but available as packages
(npm) for us to use:
● Lightning Web Runtime
● Lightning Base Components
● …
What’s available as a public package
6. #CD22
Benefit from all publicly available resources to build your own application
locally, hosted wherever you want:
● Lightning Web Runtime
● Lightning Web Components
● Salesforce Lightning Design System
● Lightning Base Components
What can be done
7. #CD22
Benefit from all publicly available resources to build your own application
locally, hosted wherever you want:
● Lightning Web Runtime
● Lightning Web Components
● Salesforce Lightning Design System
● Lightning Base Components
● Custom @wire api
What can be done
8. #CD22
Benefit from all publicly available resources to build your own application
locally, hosted wherever you want:
● Lightning Web Runtime
● Lightning Web Components
● Salesforce Lightning Design System
● Lightning Base Components
● Custom @wire api
● Use Lightning Navigation Service
What can be done
9. #CD22
Benefit from all publicly available resources to build your own application
locally, hosted wherever you want:
● Lightning Web Runtime
● Lightning Web Components
● Salesforce Lightning Design System
● Lightning Base Components
● Custom @wire api
● Use Lightning Navigation Service
● Use OSS first/only features (Light DOM, dynamic component creation)
What can be done
10. #CD22
Benefit from all publicly available resources to build your own application
locally, hosted wherever you want:
● Lightning Web Runtime
● Lightning Web Components
● Salesforce Lightning Design System
● Lightning Base Components
● Custom @wire api
● Use Lightning Navigation Service
● Use OSS first/only features (Light DOM, dynamic component creation)
● Any tool of your choice (Rollup, webpack, TypeScript…)
What can be done
11. #CD22
● LWR is a runtime built with performance in mind
● Loads modules/services, like routing
● Used by the latest Experience Cloud templates
● Configurable via lwr.config.json
Easy to start with: npm init lwr
https://developer.salesforce.com/docs/platform/lwr/overview
Let’s build something with Lightning Web Runtime
19. #CD22
Basically just an ES6 module
with a few functions:
● constructor
● connect
● disconnect
● Update
https://lwc.dev/guide/wire_adapter
Custom @wire
21. #CD22
● Custom images/assets vs static resources (different import)
○ OSS: just add files to src/assets folder
○ Platform: import myResource from '@salesforce/resourceUrl/resourceReference';
● Custom @wire → not allowed on Platform, replaced by Apex Class
○ OSS: import { getUser } from 'c/usersWireApi';
○ Platform: import getUser from '@salesforce/apex/Namespace.UsersWireApi.getUser';
Differences between OSS & Platform
22. #CD22
● Navigation page names
○ OSS: whatever name you would like (eg. “namedPage”)
○ Platform: page names expected by Salesforce (ex: comm__namedPage)
● Metadata file (myComponent.js-meta.xml)
○ OSS: No need, but won’t complain if the file is there
○ Platform: expected by Salesforce,
Differences between OSS & Platform
23. #CD22
● Presentational components
● No Salesforce only import
● Navigation is OK
● Was designed to work everywhere from the start
○ Use Salesforce expected page names
● Won’t fit for all components
Components suited to use everywhere