What is involved in moving over to Lightning Web Components?
up vote
5
down vote
favorite
I read:
- Aura Components, leveraging its own component model, templates, and modular development programming model.
- Lightning Web Components, built on top of the web standards breakthroughs of the last five years: web components, custom elements, Shadow DOM, etc.
Apart from both using SLDS, and perhaps common component names, at first sight, these look as different as Angular 1 and 2 are.
Can anyone who has worked hands-on with both Aura Components and Lightning Web Components - pilot participants? - comment about how much commonality there is in the framework and tools, and what the learning curve is like for Lightning Web Components?
(I'm hoping this doesn't get closed for being a matter of opinion; my aim is to get some insight into how easy or hard it will be to switch over.)
lightning-components aura lightning-web-components
add a comment |
up vote
5
down vote
favorite
I read:
- Aura Components, leveraging its own component model, templates, and modular development programming model.
- Lightning Web Components, built on top of the web standards breakthroughs of the last five years: web components, custom elements, Shadow DOM, etc.
Apart from both using SLDS, and perhaps common component names, at first sight, these look as different as Angular 1 and 2 are.
Can anyone who has worked hands-on with both Aura Components and Lightning Web Components - pilot participants? - comment about how much commonality there is in the framework and tools, and what the learning curve is like for Lightning Web Components?
(I'm hoping this doesn't get closed for being a matter of opinion; my aim is to get some insight into how easy or hard it will be to switch over.)
lightning-components aura lightning-web-components
add a comment |
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I read:
- Aura Components, leveraging its own component model, templates, and modular development programming model.
- Lightning Web Components, built on top of the web standards breakthroughs of the last five years: web components, custom elements, Shadow DOM, etc.
Apart from both using SLDS, and perhaps common component names, at first sight, these look as different as Angular 1 and 2 are.
Can anyone who has worked hands-on with both Aura Components and Lightning Web Components - pilot participants? - comment about how much commonality there is in the framework and tools, and what the learning curve is like for Lightning Web Components?
(I'm hoping this doesn't get closed for being a matter of opinion; my aim is to get some insight into how easy or hard it will be to switch over.)
lightning-components aura lightning-web-components
I read:
- Aura Components, leveraging its own component model, templates, and modular development programming model.
- Lightning Web Components, built on top of the web standards breakthroughs of the last five years: web components, custom elements, Shadow DOM, etc.
Apart from both using SLDS, and perhaps common component names, at first sight, these look as different as Angular 1 and 2 are.
Can anyone who has worked hands-on with both Aura Components and Lightning Web Components - pilot participants? - comment about how much commonality there is in the framework and tools, and what the learning curve is like for Lightning Web Components?
(I'm hoping this doesn't get closed for being a matter of opinion; my aim is to get some insight into how easy or hard it will be to switch over.)
lightning-components aura lightning-web-components
lightning-components aura lightning-web-components
edited 1 hour ago
asked 1 hour ago
Keith C
93.8k1088199
93.8k1088199
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
up vote
4
down vote
My take on this.
I have only been playing around with LWC since it was officially announced yesterday. I am not sure if a broader audience would have a detailed hands-on in LWC unless they were part of Pilot. With LWC announced only yesterday, it still has a long way to go before it can be widely adapted. Going through the documentation this morning, Salesforce seems to be working on quite a few things as LWC is not yet available on all Salesforce Experiences, viz., Lightning Out, or Standalone apps (as of today).
In my opinion, you don't need to make an immediate switch necessarily - it's more about choice of the framework you want for your UI customizations: Lightning Components OR Lightning Web Components, they both can/will co-exist. But over the time and with the recommended approach to go the route of Web Standards, it has to be LWC.
From a commonality perspective, even though the bundle structure of Lightning Web Component is different from Lighting Component, you will still find the markups and JS all around. Primarily the HTML Template and ES Modules.
From Learning curve perspective, I would think as long as you have a good hold of markups and JS, the learning curve will not be that significant. Whoever has worked with Lighting Components, will be easily able to co-relate things going around in Lightning Web Components. However, there will be significant learning required if one is not very familiar with ES6+ JS modules.
Based on my "limited experience", below are the key takeaways when going for LWC:
- Learn about Web Components. Brush up your HTML and Javascript skills
- Get yourself started with Salesforce DX (if you haven’t already done)
- Make VS Code your choice of IDE. With what I could see on the Spring ’19 pre-release Scratch org, you cannot create LWC from Developer Console
I have a quick run down on LWC on my blog post here, if at all that provides any further insight.
Any insight into VSCode extensions for LWC?
– Keith C
1 hour ago
There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
– Jayant Das
1 hour ago
P.S. While we don't have Developer Console support, the Playground can serve as a suitable quick mock up tool (log in your spring 19 org, and visit/docs/component-library/overview/components
. I've been playing with this, it's pretty cool, like jsfiddle but for LWC.
– sfdcfox
1 hour ago
Just a side note, The playground can’t access Salesforce organizations, so it doesn’t support features that require data from Salesforce. For example, the playground doesn’t support the wire service, Apex methods, scoped @salesforce modules, or components that require a record ID, like lightning-record-form, lightning-record-view-form, and lightning-record-edit-form. as quoted in the developer guide
– codeyinthecloud
1 hour ago
@sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
– Jayant Das
1 hour ago
add a comment |
up vote
3
down vote
LWC follows the "web standards breakthroughs of the last five years", which means it resembles coding similar to React and other languages that have moved on to ES6+. There is a learning curve, as things have changed (for the better!).
Having Aura familiarity isn't a bad thing, though. While things have changed, they've done so in a mostly predictable manner. For example:
<!-- Aura-based -->
<aura:iteration items="{!c.items}" var="item">
<ui:outputText value="{!item.name}" />
</aura:iteration>
<!-- LWC -->
<template for:each={items} for:item="item">
<ui-output-text value={item.name}></ui-output-text>
</template>
As you can see, everything changes subtly, but not significantly. The component names change based on a predictable pattern, things are shifted around, etc, but with the documentation in hand, you should find it's not too far off from what you already know. It's mostly the small "gotchas" that will take a while to solidify in your brain. I feel that any experienced Aura-based developer should be able to pick up most of the stuff in a few hours/days (I've only had a day with it, so far...).
Instead of Developer Console support, we have a Playground where we can write code and watch our changes practically live. It has solid DX support, allows new types of components like Service components (no UI required), shared JavaScript libraries without using static resources, faster loading/rendering times based on standards-based optimizations, much better ES6 support with automatic polyfills for IE 11 (so whatever code you write will work without needing to detect support), and so on.
add a comment |
up vote
2
down vote
On top of others answers salesforce had a good documentation in the developer guide about migration too.
The programming model for Lightning Web Components is fundamentally different than the model for Aura components. Migrating a component is not a line-by-line conversion, and it's a good opportunity to revisit your component's design. Before you migrate an Aura component, evaluate the component’s attributes, interfaces, structures, patterns, and data flow.
The easiest components to migrate are simple components that only render UI. You get more gains in performance and developer productivity by migrating larger trees of components (components within components) rather than an individual component. However, it's a useful learning experience to migrate one component and see how concepts in the Aura programming model map to concepts in the Lightning Web Components programming model.
After migrating one component, you'll be in a better position to determine whether it makes sense for you and your org to:
- Undertake a larger migration effort
- Use Lightning web components for new components only
- Stick with Aura components for now
The choice is down to you and differs for everyone, depending on use
cases and available resources. Whatever decision you make, migrating a
component is a valuable learning exercise.
Read more about migration strategy at: https://yourdomainforspring19prerelaseorg/docs/component-library/documentation/lwc/lwc.migrate_strategy
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "459"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f242664%2fwhat-is-involved-in-moving-over-to-lightning-web-components%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
My take on this.
I have only been playing around with LWC since it was officially announced yesterday. I am not sure if a broader audience would have a detailed hands-on in LWC unless they were part of Pilot. With LWC announced only yesterday, it still has a long way to go before it can be widely adapted. Going through the documentation this morning, Salesforce seems to be working on quite a few things as LWC is not yet available on all Salesforce Experiences, viz., Lightning Out, or Standalone apps (as of today).
In my opinion, you don't need to make an immediate switch necessarily - it's more about choice of the framework you want for your UI customizations: Lightning Components OR Lightning Web Components, they both can/will co-exist. But over the time and with the recommended approach to go the route of Web Standards, it has to be LWC.
From a commonality perspective, even though the bundle structure of Lightning Web Component is different from Lighting Component, you will still find the markups and JS all around. Primarily the HTML Template and ES Modules.
From Learning curve perspective, I would think as long as you have a good hold of markups and JS, the learning curve will not be that significant. Whoever has worked with Lighting Components, will be easily able to co-relate things going around in Lightning Web Components. However, there will be significant learning required if one is not very familiar with ES6+ JS modules.
Based on my "limited experience", below are the key takeaways when going for LWC:
- Learn about Web Components. Brush up your HTML and Javascript skills
- Get yourself started with Salesforce DX (if you haven’t already done)
- Make VS Code your choice of IDE. With what I could see on the Spring ’19 pre-release Scratch org, you cannot create LWC from Developer Console
I have a quick run down on LWC on my blog post here, if at all that provides any further insight.
Any insight into VSCode extensions for LWC?
– Keith C
1 hour ago
There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
– Jayant Das
1 hour ago
P.S. While we don't have Developer Console support, the Playground can serve as a suitable quick mock up tool (log in your spring 19 org, and visit/docs/component-library/overview/components
. I've been playing with this, it's pretty cool, like jsfiddle but for LWC.
– sfdcfox
1 hour ago
Just a side note, The playground can’t access Salesforce organizations, so it doesn’t support features that require data from Salesforce. For example, the playground doesn’t support the wire service, Apex methods, scoped @salesforce modules, or components that require a record ID, like lightning-record-form, lightning-record-view-form, and lightning-record-edit-form. as quoted in the developer guide
– codeyinthecloud
1 hour ago
@sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
– Jayant Das
1 hour ago
add a comment |
up vote
4
down vote
My take on this.
I have only been playing around with LWC since it was officially announced yesterday. I am not sure if a broader audience would have a detailed hands-on in LWC unless they were part of Pilot. With LWC announced only yesterday, it still has a long way to go before it can be widely adapted. Going through the documentation this morning, Salesforce seems to be working on quite a few things as LWC is not yet available on all Salesforce Experiences, viz., Lightning Out, or Standalone apps (as of today).
In my opinion, you don't need to make an immediate switch necessarily - it's more about choice of the framework you want for your UI customizations: Lightning Components OR Lightning Web Components, they both can/will co-exist. But over the time and with the recommended approach to go the route of Web Standards, it has to be LWC.
From a commonality perspective, even though the bundle structure of Lightning Web Component is different from Lighting Component, you will still find the markups and JS all around. Primarily the HTML Template and ES Modules.
From Learning curve perspective, I would think as long as you have a good hold of markups and JS, the learning curve will not be that significant. Whoever has worked with Lighting Components, will be easily able to co-relate things going around in Lightning Web Components. However, there will be significant learning required if one is not very familiar with ES6+ JS modules.
Based on my "limited experience", below are the key takeaways when going for LWC:
- Learn about Web Components. Brush up your HTML and Javascript skills
- Get yourself started with Salesforce DX (if you haven’t already done)
- Make VS Code your choice of IDE. With what I could see on the Spring ’19 pre-release Scratch org, you cannot create LWC from Developer Console
I have a quick run down on LWC on my blog post here, if at all that provides any further insight.
Any insight into VSCode extensions for LWC?
– Keith C
1 hour ago
There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
– Jayant Das
1 hour ago
P.S. While we don't have Developer Console support, the Playground can serve as a suitable quick mock up tool (log in your spring 19 org, and visit/docs/component-library/overview/components
. I've been playing with this, it's pretty cool, like jsfiddle but for LWC.
– sfdcfox
1 hour ago
Just a side note, The playground can’t access Salesforce organizations, so it doesn’t support features that require data from Salesforce. For example, the playground doesn’t support the wire service, Apex methods, scoped @salesforce modules, or components that require a record ID, like lightning-record-form, lightning-record-view-form, and lightning-record-edit-form. as quoted in the developer guide
– codeyinthecloud
1 hour ago
@sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
– Jayant Das
1 hour ago
add a comment |
up vote
4
down vote
up vote
4
down vote
My take on this.
I have only been playing around with LWC since it was officially announced yesterday. I am not sure if a broader audience would have a detailed hands-on in LWC unless they were part of Pilot. With LWC announced only yesterday, it still has a long way to go before it can be widely adapted. Going through the documentation this morning, Salesforce seems to be working on quite a few things as LWC is not yet available on all Salesforce Experiences, viz., Lightning Out, or Standalone apps (as of today).
In my opinion, you don't need to make an immediate switch necessarily - it's more about choice of the framework you want for your UI customizations: Lightning Components OR Lightning Web Components, they both can/will co-exist. But over the time and with the recommended approach to go the route of Web Standards, it has to be LWC.
From a commonality perspective, even though the bundle structure of Lightning Web Component is different from Lighting Component, you will still find the markups and JS all around. Primarily the HTML Template and ES Modules.
From Learning curve perspective, I would think as long as you have a good hold of markups and JS, the learning curve will not be that significant. Whoever has worked with Lighting Components, will be easily able to co-relate things going around in Lightning Web Components. However, there will be significant learning required if one is not very familiar with ES6+ JS modules.
Based on my "limited experience", below are the key takeaways when going for LWC:
- Learn about Web Components. Brush up your HTML and Javascript skills
- Get yourself started with Salesforce DX (if you haven’t already done)
- Make VS Code your choice of IDE. With what I could see on the Spring ’19 pre-release Scratch org, you cannot create LWC from Developer Console
I have a quick run down on LWC on my blog post here, if at all that provides any further insight.
My take on this.
I have only been playing around with LWC since it was officially announced yesterday. I am not sure if a broader audience would have a detailed hands-on in LWC unless they were part of Pilot. With LWC announced only yesterday, it still has a long way to go before it can be widely adapted. Going through the documentation this morning, Salesforce seems to be working on quite a few things as LWC is not yet available on all Salesforce Experiences, viz., Lightning Out, or Standalone apps (as of today).
In my opinion, you don't need to make an immediate switch necessarily - it's more about choice of the framework you want for your UI customizations: Lightning Components OR Lightning Web Components, they both can/will co-exist. But over the time and with the recommended approach to go the route of Web Standards, it has to be LWC.
From a commonality perspective, even though the bundle structure of Lightning Web Component is different from Lighting Component, you will still find the markups and JS all around. Primarily the HTML Template and ES Modules.
From Learning curve perspective, I would think as long as you have a good hold of markups and JS, the learning curve will not be that significant. Whoever has worked with Lighting Components, will be easily able to co-relate things going around in Lightning Web Components. However, there will be significant learning required if one is not very familiar with ES6+ JS modules.
Based on my "limited experience", below are the key takeaways when going for LWC:
- Learn about Web Components. Brush up your HTML and Javascript skills
- Get yourself started with Salesforce DX (if you haven’t already done)
- Make VS Code your choice of IDE. With what I could see on the Spring ’19 pre-release Scratch org, you cannot create LWC from Developer Console
I have a quick run down on LWC on my blog post here, if at all that provides any further insight.
edited 55 mins ago
answered 1 hour ago
Jayant Das
11.6k2523
11.6k2523
Any insight into VSCode extensions for LWC?
– Keith C
1 hour ago
There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
– Jayant Das
1 hour ago
P.S. While we don't have Developer Console support, the Playground can serve as a suitable quick mock up tool (log in your spring 19 org, and visit/docs/component-library/overview/components
. I've been playing with this, it's pretty cool, like jsfiddle but for LWC.
– sfdcfox
1 hour ago
Just a side note, The playground can’t access Salesforce organizations, so it doesn’t support features that require data from Salesforce. For example, the playground doesn’t support the wire service, Apex methods, scoped @salesforce modules, or components that require a record ID, like lightning-record-form, lightning-record-view-form, and lightning-record-edit-form. as quoted in the developer guide
– codeyinthecloud
1 hour ago
@sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
– Jayant Das
1 hour ago
add a comment |
Any insight into VSCode extensions for LWC?
– Keith C
1 hour ago
There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
– Jayant Das
1 hour ago
P.S. While we don't have Developer Console support, the Playground can serve as a suitable quick mock up tool (log in your spring 19 org, and visit/docs/component-library/overview/components
. I've been playing with this, it's pretty cool, like jsfiddle but for LWC.
– sfdcfox
1 hour ago
Just a side note, The playground can’t access Salesforce organizations, so it doesn’t support features that require data from Salesforce. For example, the playground doesn’t support the wire service, Apex methods, scoped @salesforce modules, or components that require a record ID, like lightning-record-form, lightning-record-view-form, and lightning-record-edit-form. as quoted in the developer guide
– codeyinthecloud
1 hour ago
@sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
– Jayant Das
1 hour ago
Any insight into VSCode extensions for LWC?
– Keith C
1 hour ago
Any insight into VSCode extensions for LWC?
– Keith C
1 hour ago
There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
– Jayant Das
1 hour ago
There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
– Jayant Das
1 hour ago
P.S. While we don't have Developer Console support, the Playground can serve as a suitable quick mock up tool (log in your spring 19 org, and visit
/docs/component-library/overview/components
. I've been playing with this, it's pretty cool, like jsfiddle but for LWC.– sfdcfox
1 hour ago
P.S. While we don't have Developer Console support, the Playground can serve as a suitable quick mock up tool (log in your spring 19 org, and visit
/docs/component-library/overview/components
. I've been playing with this, it's pretty cool, like jsfiddle but for LWC.– sfdcfox
1 hour ago
Just a side note, The playground can’t access Salesforce organizations, so it doesn’t support features that require data from Salesforce. For example, the playground doesn’t support the wire service, Apex methods, scoped @salesforce modules, or components that require a record ID, like lightning-record-form, lightning-record-view-form, and lightning-record-edit-form. as quoted in the developer guide
– codeyinthecloud
1 hour ago
Just a side note, The playground can’t access Salesforce organizations, so it doesn’t support features that require data from Salesforce. For example, the playground doesn’t support the wire service, Apex methods, scoped @salesforce modules, or components that require a record ID, like lightning-record-form, lightning-record-view-form, and lightning-record-edit-form. as quoted in the developer guide
– codeyinthecloud
1 hour ago
@sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
– Jayant Das
1 hour ago
@sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
– Jayant Das
1 hour ago
add a comment |
up vote
3
down vote
LWC follows the "web standards breakthroughs of the last five years", which means it resembles coding similar to React and other languages that have moved on to ES6+. There is a learning curve, as things have changed (for the better!).
Having Aura familiarity isn't a bad thing, though. While things have changed, they've done so in a mostly predictable manner. For example:
<!-- Aura-based -->
<aura:iteration items="{!c.items}" var="item">
<ui:outputText value="{!item.name}" />
</aura:iteration>
<!-- LWC -->
<template for:each={items} for:item="item">
<ui-output-text value={item.name}></ui-output-text>
</template>
As you can see, everything changes subtly, but not significantly. The component names change based on a predictable pattern, things are shifted around, etc, but with the documentation in hand, you should find it's not too far off from what you already know. It's mostly the small "gotchas" that will take a while to solidify in your brain. I feel that any experienced Aura-based developer should be able to pick up most of the stuff in a few hours/days (I've only had a day with it, so far...).
Instead of Developer Console support, we have a Playground where we can write code and watch our changes practically live. It has solid DX support, allows new types of components like Service components (no UI required), shared JavaScript libraries without using static resources, faster loading/rendering times based on standards-based optimizations, much better ES6 support with automatic polyfills for IE 11 (so whatever code you write will work without needing to detect support), and so on.
add a comment |
up vote
3
down vote
LWC follows the "web standards breakthroughs of the last five years", which means it resembles coding similar to React and other languages that have moved on to ES6+. There is a learning curve, as things have changed (for the better!).
Having Aura familiarity isn't a bad thing, though. While things have changed, they've done so in a mostly predictable manner. For example:
<!-- Aura-based -->
<aura:iteration items="{!c.items}" var="item">
<ui:outputText value="{!item.name}" />
</aura:iteration>
<!-- LWC -->
<template for:each={items} for:item="item">
<ui-output-text value={item.name}></ui-output-text>
</template>
As you can see, everything changes subtly, but not significantly. The component names change based on a predictable pattern, things are shifted around, etc, but with the documentation in hand, you should find it's not too far off from what you already know. It's mostly the small "gotchas" that will take a while to solidify in your brain. I feel that any experienced Aura-based developer should be able to pick up most of the stuff in a few hours/days (I've only had a day with it, so far...).
Instead of Developer Console support, we have a Playground where we can write code and watch our changes practically live. It has solid DX support, allows new types of components like Service components (no UI required), shared JavaScript libraries without using static resources, faster loading/rendering times based on standards-based optimizations, much better ES6 support with automatic polyfills for IE 11 (so whatever code you write will work without needing to detect support), and so on.
add a comment |
up vote
3
down vote
up vote
3
down vote
LWC follows the "web standards breakthroughs of the last five years", which means it resembles coding similar to React and other languages that have moved on to ES6+. There is a learning curve, as things have changed (for the better!).
Having Aura familiarity isn't a bad thing, though. While things have changed, they've done so in a mostly predictable manner. For example:
<!-- Aura-based -->
<aura:iteration items="{!c.items}" var="item">
<ui:outputText value="{!item.name}" />
</aura:iteration>
<!-- LWC -->
<template for:each={items} for:item="item">
<ui-output-text value={item.name}></ui-output-text>
</template>
As you can see, everything changes subtly, but not significantly. The component names change based on a predictable pattern, things are shifted around, etc, but with the documentation in hand, you should find it's not too far off from what you already know. It's mostly the small "gotchas" that will take a while to solidify in your brain. I feel that any experienced Aura-based developer should be able to pick up most of the stuff in a few hours/days (I've only had a day with it, so far...).
Instead of Developer Console support, we have a Playground where we can write code and watch our changes practically live. It has solid DX support, allows new types of components like Service components (no UI required), shared JavaScript libraries without using static resources, faster loading/rendering times based on standards-based optimizations, much better ES6 support with automatic polyfills for IE 11 (so whatever code you write will work without needing to detect support), and so on.
LWC follows the "web standards breakthroughs of the last five years", which means it resembles coding similar to React and other languages that have moved on to ES6+. There is a learning curve, as things have changed (for the better!).
Having Aura familiarity isn't a bad thing, though. While things have changed, they've done so in a mostly predictable manner. For example:
<!-- Aura-based -->
<aura:iteration items="{!c.items}" var="item">
<ui:outputText value="{!item.name}" />
</aura:iteration>
<!-- LWC -->
<template for:each={items} for:item="item">
<ui-output-text value={item.name}></ui-output-text>
</template>
As you can see, everything changes subtly, but not significantly. The component names change based on a predictable pattern, things are shifted around, etc, but with the documentation in hand, you should find it's not too far off from what you already know. It's mostly the small "gotchas" that will take a while to solidify in your brain. I feel that any experienced Aura-based developer should be able to pick up most of the stuff in a few hours/days (I've only had a day with it, so far...).
Instead of Developer Console support, we have a Playground where we can write code and watch our changes practically live. It has solid DX support, allows new types of components like Service components (no UI required), shared JavaScript libraries without using static resources, faster loading/rendering times based on standards-based optimizations, much better ES6 support with automatic polyfills for IE 11 (so whatever code you write will work without needing to detect support), and so on.
answered 1 hour ago
sfdcfox
244k10185418
244k10185418
add a comment |
add a comment |
up vote
2
down vote
On top of others answers salesforce had a good documentation in the developer guide about migration too.
The programming model for Lightning Web Components is fundamentally different than the model for Aura components. Migrating a component is not a line-by-line conversion, and it's a good opportunity to revisit your component's design. Before you migrate an Aura component, evaluate the component’s attributes, interfaces, structures, patterns, and data flow.
The easiest components to migrate are simple components that only render UI. You get more gains in performance and developer productivity by migrating larger trees of components (components within components) rather than an individual component. However, it's a useful learning experience to migrate one component and see how concepts in the Aura programming model map to concepts in the Lightning Web Components programming model.
After migrating one component, you'll be in a better position to determine whether it makes sense for you and your org to:
- Undertake a larger migration effort
- Use Lightning web components for new components only
- Stick with Aura components for now
The choice is down to you and differs for everyone, depending on use
cases and available resources. Whatever decision you make, migrating a
component is a valuable learning exercise.
Read more about migration strategy at: https://yourdomainforspring19prerelaseorg/docs/component-library/documentation/lwc/lwc.migrate_strategy
add a comment |
up vote
2
down vote
On top of others answers salesforce had a good documentation in the developer guide about migration too.
The programming model for Lightning Web Components is fundamentally different than the model for Aura components. Migrating a component is not a line-by-line conversion, and it's a good opportunity to revisit your component's design. Before you migrate an Aura component, evaluate the component’s attributes, interfaces, structures, patterns, and data flow.
The easiest components to migrate are simple components that only render UI. You get more gains in performance and developer productivity by migrating larger trees of components (components within components) rather than an individual component. However, it's a useful learning experience to migrate one component and see how concepts in the Aura programming model map to concepts in the Lightning Web Components programming model.
After migrating one component, you'll be in a better position to determine whether it makes sense for you and your org to:
- Undertake a larger migration effort
- Use Lightning web components for new components only
- Stick with Aura components for now
The choice is down to you and differs for everyone, depending on use
cases and available resources. Whatever decision you make, migrating a
component is a valuable learning exercise.
Read more about migration strategy at: https://yourdomainforspring19prerelaseorg/docs/component-library/documentation/lwc/lwc.migrate_strategy
add a comment |
up vote
2
down vote
up vote
2
down vote
On top of others answers salesforce had a good documentation in the developer guide about migration too.
The programming model for Lightning Web Components is fundamentally different than the model for Aura components. Migrating a component is not a line-by-line conversion, and it's a good opportunity to revisit your component's design. Before you migrate an Aura component, evaluate the component’s attributes, interfaces, structures, patterns, and data flow.
The easiest components to migrate are simple components that only render UI. You get more gains in performance and developer productivity by migrating larger trees of components (components within components) rather than an individual component. However, it's a useful learning experience to migrate one component and see how concepts in the Aura programming model map to concepts in the Lightning Web Components programming model.
After migrating one component, you'll be in a better position to determine whether it makes sense for you and your org to:
- Undertake a larger migration effort
- Use Lightning web components for new components only
- Stick with Aura components for now
The choice is down to you and differs for everyone, depending on use
cases and available resources. Whatever decision you make, migrating a
component is a valuable learning exercise.
Read more about migration strategy at: https://yourdomainforspring19prerelaseorg/docs/component-library/documentation/lwc/lwc.migrate_strategy
On top of others answers salesforce had a good documentation in the developer guide about migration too.
The programming model for Lightning Web Components is fundamentally different than the model for Aura components. Migrating a component is not a line-by-line conversion, and it's a good opportunity to revisit your component's design. Before you migrate an Aura component, evaluate the component’s attributes, interfaces, structures, patterns, and data flow.
The easiest components to migrate are simple components that only render UI. You get more gains in performance and developer productivity by migrating larger trees of components (components within components) rather than an individual component. However, it's a useful learning experience to migrate one component and see how concepts in the Aura programming model map to concepts in the Lightning Web Components programming model.
After migrating one component, you'll be in a better position to determine whether it makes sense for you and your org to:
- Undertake a larger migration effort
- Use Lightning web components for new components only
- Stick with Aura components for now
The choice is down to you and differs for everyone, depending on use
cases and available resources. Whatever decision you make, migrating a
component is a valuable learning exercise.
Read more about migration strategy at: https://yourdomainforspring19prerelaseorg/docs/component-library/documentation/lwc/lwc.migrate_strategy
answered 1 hour ago
codeyinthecloud
2,778321
2,778321
add a comment |
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f242664%2fwhat-is-involved-in-moving-over-to-lightning-web-components%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown