[MUSIC]
Speaker 1: Because future looking statements are inherently subject to risk
and uncertainty, are reminders that you should make any purchasing decisions or
investment decisions based on products that are currently commercially available.
Kevin Hill: Developers today are facing more and more demand to create consumer
grade experiences while maintaining enterprise scale, and
often with a more compressed time frame.
The Salesforce platform has been a great answer to enterprise development,
by providing a robust environment to develop with both clicks, and code.
However, when it comes to the ultimate customization with external apps,
like communities where the Salesforce data meets your customers.
Sometimes you need to customize that experience with every pixel.
For these use cases, developers need a set of flexible tools
that allows them to build with open frameworks that they can quickly learn.
Take their code and deploy everywhere, where their customers are and
all the while keeping their apps secure and robust.
This is where Lightning Web stack comes in.
Lightning Web stack provides the most important modules and
services to build a trusted web app that can run anywhere.
Let's take a look at what it takes to make that happen.
First, your code needs to be modular and open.
This is why we created LWC, a component framework based on open standards.
So any JavaScript developers can quickly build LWC components.
Of course, we have an exceptional design system that has been out there for
over three years as an open source project.
SLDS provides the patterns and
the blueprints that make it easy to design great applications.
The SLDS team just announced a new tool for sketch,
a sketch plugin to help you develop beautiful experiences even faster.
The second part of building great, trusted web apps is making it secure.
You can leverage even more lining services like
locker that is out of the box with LWC.
We're making it easier than ever to add security and
include enterprise grade protection for components running on consumer websites.
And finally,
making your code portable, showcases the power of Lightning Web stack.
Your app can run where your customers are everywhere.
With our truly transformative technologies, Lightning Data Service and
Lightning Web Runtime, your components are portable.
Lightning Data Service makes it easy for developers access Salesforce data,
all while including powerful client side caching technology.
Lightning Web Runtime makes it a snap to develop locally on your machine.
In combining both Lightning Data Services, Lightning Web Runtime with Salesforce
open source based components, makes running your app anywhere possible.
And with that, I want to walk you through an example of how e-bikes.
A sample app showcasing a fictional online retailer
on how they can create a new delivery scheduling service that can be deployed
both on Salesforce and then on any external website.
Getting right into the demo, I've gone to the Trailhead apps GitHub repo.
This repository is maintained by evangelists and has some great recipes for
getting started.
I chose to use the ebikes Lightning Web Component application and
I deployed that to Salesforce through SFDX and to my Dev Hub.
So let's go ahead and take a peek.
Okay, I've opened up e-bikes, I've pull up in the Product Explorer.
This page is full of Lightning Web components.
I can click on something in the catalog, it sends a message and
it renders over to the detail card on the right.
I can also use filters, so I can select a filter, filter the catalog down,
and also do a quick search to filter the catalog even more.
This is a very rich Lightning Web Component experience, but
today what we're going to do is focus on the reseller orders.
So let's go ahead and click on the order I had already started earlier.
All right, you can see that I've got another page full of
Lightning Web Components.
I can remove something from the order.
I can adjust the numbers of the bikes I would like to be sent to my
bike shop in this order.
And I can even drag, and drop using modern JavaScript and html5 events,
a new bike over to my order and confirm that, and it updates the total.
This is a great experience so far.
It's all built LDPC first, it's all built on Salesforce, and it's working just fine.
However, I had a scenario from the product team where we got feedback
from customers and they said, gee, it'd be nice to be able to deliver,
to figure out when we can deliver these bikes.
And so I mocked up this delivery times component, all on SFDX,
Salesforce CLI, built-in VS code, and I'm using some base components.
I can click on a button, you can see it sends an event and
it picks the time of day in the window for the delivery.
I built this using base components.
So I have a lightning button and a lightning card.
And we're going to get into that in a little bit when we go and
take a peek at the code.
All right, first I want to call your attention over to the data delivery.
This is my container component that pulls the data from an Apex controller.
And so I'm importing my Apex controller up top here.
And then I'm putting that into the wire component down below where it expects to
get a zip code value sent as a string.
And then it takes this data and it propagates it down to the rest
of the UI components in the the delivery window.
You can see here, I've got a lightning card.
And if I expand this, you're going to see that I have a whole bunch of other layout
components for my kind of custom layout of how I'm
organizing the days of the week and the times, and the buttons, and so forth.
Also, you can note, I have a lightning button down at the bottom
where it's handling the click event.
You saw me click and sending the information back up for
the delivery time spot.
This usually precludes you from taking this component off of Salesforce because
you're already like calling our wire adapters.
You're already getting data from Apex.
And it would be hard to like just take this component as it is
off platform and make it work.
Same with the lightning card, like this is a base component.
It's served up to automatically on Salesforce, but
it doesn't exist outside of Salesforce in any meaningful way.
So right now I'm talking about code portability, and
I'm highlighting things that aren't very portable.
However, I'm going to go to a site running locally on my machine right now.
As you can see, this is a consumer based website where I'm just showing my product
catalog, and doing a simple search and filter, just like on SFDX.
These are similar components and it gives you a similar experience.
And so you can see I'm going to go and do a filter really quick.
I'm going to search for a bike I've had my eye on for a while, and
we're going to go and drill into it.
But otherwise, this is all LWC components, and LWC first container.
I like this bike because I like orange, and it's got orange on it,
it drew my eyes to it.
So I'm now going to go click on this, and we're going to drill into a detail page.
Okay, same bike, I'm going to go down, I get a little bit more information.
I could choose to add this to cart, and I could go find new bike, but look,
it's the same component.
This is what is really cool.
This is the exact same component.
I copied and pasted the code.
I'm going to show you the source on the page.
Look at this, a lightning button, it's the same lightning button, and
this like should not work.
Also the lightning card.
What, how does this work?
I didn't change the code.
I'm actually going to go and show you the code so
that we can walk through how this actually works.
Like we've copied and
pasted from Salesforce into a local project, and it's running just fine.
You can see over here I'm using Lightning Web Runtime.
I actually have my own namespaces that I manage.
I have the C namespace, which is key for this,
because C namespace is the default customer namespace.
And I built my components in my default customer namespace.
I copied and pasted them into the structure.
And you can see Visual Studio is snitching on me.
It's showing that I've made an edit to one file, and
we're going to take a peek at that edit in just a second.
But I copied over the XML metadata for Salesforce.
I don't need it, but
I was just showing you the authenticity of like, I can copy and paste this code.
All right, we're going to take a peek at what I did to the data.
First you'll notice, I did comment out the Apex controller, but
I can't really reference it resolve that easily.
I am referencing my own wire adapter that I generated off platform that meets
the same data contract for this wire.
This is super cool.
It's still just expecting the same string data.
I have a local service running,
a node service running on my box that serves up that data.
I still have to have an endpoint.
But I'm using the same wire adapter.
I don't have to change this part of the code.
I just updated the name, I updated the reference.
I could have actually done trickery and
just map the Apex one to something that I made locally.
But that's not very genuine, right?
There is one change, so that's fine.
But the code portability side.
Let's go take a peek at the actual HTML C, same HTML that I showed you before,
it's the same lightning card, and is actually the same lightning button.
Great.
Now there's still a couple mysteries.
You kind of know how I did the wire adapter.
Let's go take a peek at the wire adapter I made to go and
meet the contract here.
So I'm going to go ahead and pull up in that project.
You can see that I worked with my development team to get a raml
definition made for my API.
It's a very simple API.
It's just deliveries and zip code.
And this is the description of it here.
And then in the LDS adapter, all I've done is I've mapped this simple API.
So we're going to go over to the LDS.raml file, and
you're going to see that I have the mapping down below.
So it shows deliveries and it's extracting zip code, and
it's saying I'm going to expose this in this adapter that I'm referencing my code.
And I also can do some other things with LDS.
This is the power of LDS in the robustness.
I can set the time delivery, which is I think about 15 minutes, and
it's seven milliseconds.
And then I also tell what the unique key is for caching.
So it's not just the fact that I can call through the API and
set the wire after it's actually using LDS on the client.
So when I call through and
get the zip code data once, it's going to keep that cache for 15 minutes.
And then if I'm going to refresh the view It's still going to come from my cache.
And I can shorten that if my API requires a shorter time.
Here's the actual generated code, we didn't write this by hand,
it was generated by this project.
You can see that the wire adapter first says, hey, let's go check and
see if I have this in the cache.
If it's in the cache, we just grab it and we return it super fast.
The next thing is it says, hey, what if it's partially in the cache, maybe I've
got some of the data in the cache and some of the data I've not seen before.
So it might go and retrieve the difference in the records.
Like if I had four or five records returning from this based on unique key.
If it doesn't find it says, hey, let's go get it from the network for
the first time in caching.
So, this is LDS and it's code generated for
you on my local machine, and I've got my wire adapter.
That's cool.
We've solved one mystery.
We've solved the mystery of how can I keep my data contracts in sync, and
still leverage my same code for that component.
Okay, great.
Now you can see how all of this comes together.
This wire adapter will call in to my local node service, it'll get its data.
And it will pass that data down to my UI components, and
it will render just fine just like it did on SFDX.
And you can actually see down here in my LWR config,
this is where the rest of the magic is happening.
So we're going to go and open that file.
You can see I've got this highlighted,
this NPM reference to LWC demo UI components.
This is where my lightning components are coming from.
I am able to resolve components through node modules.
This is a recent change made to the LWC engine.
And Lightning Web Runtime is taking advantage of that.
So you can see here, I've got the open source-based components code.
I'm into that repository, this is the code for card.
I took this code for the card, I copied it, I pasted it in my own local package.
And I published it up on NPM, and here now, I'm able to reference it.
So once I did this reference, and I did my NPF install
from my package, you can see I've got my LWC demo UI components.
Sure enough, here's my lightning namespace.
I control the namespaces.
Here's my card.
There's the same code you just saw copying from base components.
It's really exciting that it's this easy,
like we have a repository components online that I can reference now.
Once that's referenced, everything works.
I copied and pasted the code, and it works.
Just had to pay a little attention to the namespace,
I had to make sure the lightning namespace existed.
But that makes sense, right?
Because everything was coming out of the lightning namespace anyway.
And that's the beauty of some of the features we've added to
the core Lightning Web Component engine.
And the fact that we're making everything LWC first makes this ultra portable.
Like all of the data contracts are really clear.
And you can actually see how all of this fits together.
I hope you liked what I just showed you.
What you just saw is a continued push by Salesforce towards being more open, and
more friendly to our developer community.
And our own Salesforce engineers are loving this, and adopting it as well.
Communities is already using Lightning Web Runtime to create
the next gen authoring experience.
There's a talk by Zack,
the product manager on the community's team that you won't want to miss.
The community's product is not the only feature taking advantage of this
transformative technology in Lightning Web Runtime.
Local development for LWC and the Lightning mobile app are already building
new experiences on these modules today.
And we're not stopping there.
We want our entire developer community to keep propelling us forward.
We openly share designs for Lightning Web Components, and
love feedback on our request for comments or RFC docs.
These documents also provide insight into our technology roadmap.
Check out this link to read on some of the features you may have seen today,
like module resolution, and provide us with comments.
We're also very excited to have a new super batch on lightning Web Components
that's going live.
Don't miss this.
We talked about Salesforce being a platform that let you customize with
clicks and code.
Are you confused about when or what to use?
Check out this architect's guide that we authored to show when to use
clicks vs code.
Finally, we started this session by saying user developer have enormous demands on
your time all while having some shortened deadlines and high expectations.
Since we're on this journey together, my call to action
to you is to write and share fantastic components.
Keep pushing the platform and providing feedback.
We're all in this together in Lightning Web stack
is the result of your efforts as Salesforce developers.
[MUSIC]
Isabel Goncalves: Did you know that our brains receive 11 million bits of
information every second, however, we can only consciously process around 40 bits.
This is called unconscious bias.
We all have it, but these mental shortcuts can create harmful stereotypes.
[MUSIC]
Isabel Goncalves: Scaling up on equality makes us a stronger community.
Learn more on Trailhead and earn the impact of unconscious bias badge.
[MUSIC]
Speaker 4: Flosum DevOps and
backup solution, streamlines the development process.
Accelerates release velocity and guarantees data security.
Achieve automation and
scalable deployments based on specified conditions with pipelines.
Save valuable time and resources with declarative components merge editing.
And easily review, and directly comment on code with line-by-line code review.
Check out Flosum on App Exchange to learn more.
[MUSIC]