#Update functionality lwc

[korshubudemycoursesblog]

Salesforce LWC: Your Guide to Mastering Lightning Web Components

Salesforce has revolutionized how businesses manage relationships, automate processes, and analyze data. One of the most exciting developments in this platform is Salesforce LWC (Lightning Web Components). If you're diving into the Salesforce ecosystem or aiming to improve your development skills, understanding Salesforce LWC is crucial.

What is Salesforce LWC?

At its core, Salesforce LWC is a modern, lightweight framework built on web standards. Unlike the previous Aura framework, LWC leverages the latest browser capabilities, making it faster and easier to create reusable components. This shift towards using standard web technologies like JavaScript and HTML makes Salesforce development more flexible and accessible for developers with web development backgrounds.

The Evolution from Aura to Lightning Web Components

Before Lightning Web Components (LWC), Salesforce developers relied on the Aura framework. While Aura served its purpose, it came with several limitations, such as slower performance due to its complex nature. With the advent of Salesforce LWC, things changed dramatically. LWC is more efficient, has better performance, and is easier to use due to its reliance on modern web standards. As a result, developers can now create more responsive and scalable apps, improving the overall user experience.

Why Should You Learn Salesforce LWC?

Faster Development: Since LWC uses standard web technologies like JavaScript, HTML, and CSS, it's easier for web developers to adapt. There's no need to learn proprietary languages or technologies.

Component Reusability: One of the significant advantages of Salesforce LWC is its reusability. You can create components once and reuse them across multiple applications, saving time and effort.

Improved Performance: LWC is lightweight and designed for speed, making it ideal for building high-performance apps. As businesses rely more on mobile and web apps, performance becomes a critical factor.

Enhanced User Experience: With LWC's ability to create fast, interactive, and user-friendly interfaces, the end-users benefit from a smooth experience, which translates to better engagement and satisfaction.

The Structure of Lightning Web Components

When building an app with Salesforce LWC, you'll be working with a set of essential components. These include:

HTML: Responsible for structuring the web components.

CSS: Ensures the web components are visually appealing and match the branding of the app.

JavaScript: Adds functionality to the components, making them interactive and dynamic.

What sets Salesforce LWC apart is that it integrates smoothly with Salesforce’s core platform, ensuring seamless data integration and a robust backend. Additionally, LWC components are encapsulated, ensuring that each component operates independently, which reduces the likelihood of bugs and makes maintenance easier.

Key Features of Salesforce LWC

To better understand why Salesforce LWC is gaining so much traction, let's look at its core features:

Web Standards: LWC uses the latest browser APIs like Web Components, Shadow DOM, and Custom Elements, making it more adaptable and powerful.

Modular Development: With Salesforce LWC, you can break down complex UIs into smaller, manageable components that are easy to develop, test, and maintain.

Declarative Syntax: Developers can leverage a declarative approach, meaning fewer lines of code for better results.

Reactive Programming Model: LWC offers a reactive UI, where the interface updates automatically when the data changes.

These features make Salesforce LWC one of the most efficient tools for building enterprise-grade applications.

Setting Up and Getting Started with Salesforce LWC

Before you can start developing with Salesforce LWC, you'll need the following:

Salesforce Developer Org: You’ll need a Salesforce Developer Edition to begin. Sign up at developer.salesforce.com.

Visual Studio Code: VS Code is the preferred Integrated Development Environment (IDE) for Salesforce development.

Salesforce CLI: This tool helps interact with your Salesforce environments.

Once you have these tools ready, you're set to begin building your first LWC component.

Building Your First Salesforce LWC Component

To get started with Salesforce LWC, you can follow these steps:

Create the Component: Begin by using Visual Studio Code to create a new Lightning Web Component. This will include an HTML file, a JavaScript file, and a CSS file.

Use Standard Web Technologies: In the HTML file, write the structure of the component, and use JavaScript to add interactivity. CSS will ensure that the component matches your organization’s branding.

Deploy the Component: After creating the component, deploy it to your Salesforce org and test it in real-time.

Advanced Salesforce LWC: Going Beyond Basics

After mastering the fundamentals, you can explore more advanced topics like Apex Integration, which allows you to call server-side logic, and third-party JavaScript libraries integration for more complex functionalities. By leveraging these advanced features, you can build highly customizable apps that cater to specific business needs.

Another area to explore is Lightning Data Service (LDS), which provides a way to work with Salesforce data without writing Apex code. LDS ensures that your LWC apps are both efficient and maintainable.

Popular Use Cases for Salesforce LWC

Here are some common use cases where Salesforce LWC shines:

Custom UI Development: Whether you're building custom dashboards or business apps, LWC allows you to create fast and responsive UIs that meet your business needs.

Salesforce Mobile App: As businesses rely more on mobile access, LWC components can be reused in Salesforce's mobile app to ensure consistency.

Integration with External Systems: Using LWC with Salesforce APIs and Apex, you can integrate third-party systems to create unified experiences.

These use cases show how versatile and powerful Salesforce LWC is in today’s development landscape.

Conclusion: The Future of Salesforce LWC

Salesforce LWC is the future of Salesforce development. As more businesses adopt this framework, the demand for developers proficient in LWC will continue to grow. Whether you're just starting or looking to enhance your Salesforce development skills, mastering Salesforce LWC will put you on the fast track to success.

So, what are you waiting for? Dive into Salesforce LWC, and start building the future of web apps today!

[salesforce-developer-1]

Mastering Salesforce Development: What to Expect from the Salesforce Platform Developer 1 Course with TechForce Academy

Salesforce has emerged as one of the most powerful and sought-after CRM platforms, helping businesses enhance customer relationships, optimize workflows, and drive productivity. For aspiring Salesforce developers, gaining the right skills and certification is essential to thriving in this field. That’s where the Salesforce Platform Developer 1 (PD1) certification comes in. In this article, we’ll explore what you can expect from the Salesforce Developer Course offered by TechForce Academy, tailored specifically to prepare you for the Salesforce Platform Developer 1 certification (PD1).

Why Salesforce Development is Crucial

Salesforce development is crucial for companies looking to customize their Salesforce environments, automate complex processes, and create tailored solutions to meet their specific business needs. With Salesforce being widely adopted across industries, the demand for skilled developers is skyrocketing. TechForce Academy offers an in-depth Salesforce Developer Course designed to give professionals the tools and knowledge they need to succeed.

The Salesforce Platform Developer 1 certification is a key stepping stone for developers, validating their ability to build, deploy, and manage applications on the Salesforce platform. By mastering this certification through TechForce Academy, you can stand out in a competitive job market, develop crucial Salesforce skills, and position yourself as an expert in the field.

What is the Salesforce Platform Developer 1 (PD1) Certification?

The Salesforce Platform Developer 1 (PD1) certification is an entry-level credential designed to demonstrate a developer's understanding of building custom applications using Salesforce’s programmatic and declarative features. The PD1 certification covers essential development skills, including:

Writing Apex code

Building Visualforce pages

Using Lightning Web Components (LWC)

Implementing complex business logic

Managing data models and security configurations

At TechForce Academy, the Salesforce Platform Developer 1 course is structured to provide students with hands-on learning, ensuring they can apply these skills in real-world development scenarios.

What to Expect from TechForce Academy’s Salesforce Developer Course

TechForce Academy's Salesforce Developer Course for the PD1 certification is designed to guide students through every aspect of Salesforce development. This is a thorough explanation of what to anticipate.

1. Comprehensive Introduction to Salesforce

The course begins with an overview of Salesforce’s architecture, core functionalities, and cloud solutions. You’ll learn about:

Salesforce CRM and metadata: Understand the basics of Salesforce as a CRM and how metadata plays a crucial role in Salesforce development.

Declarative vs. programmatic development: Learn when to use Salesforce’s declarative tools (clicks) versus writing code (programmatic development).

Custom objects and fields: Create custom objects and fields, and understand how to model data in Salesforce.

Gaining a solid understanding of the Salesforce platform is the first step in becoming a successful developer, and TechForce Academy ensures students are well-prepared from the start.

2. Apex Programming

Apex is Salesforce’s proprietary programming language, used for writing backend logic and automating tasks.

Apex syntax and structure: Learn the basics of writing clean, efficient Apex code, including variables, operators, and loops.

SOQL (Salesforce Object Query Language): Master how to query Salesforce databases using SOQL to retrieve data, filter records, and implement custom searches.

DML operations: Get hands-on experience with Data Manipulation Language (DML) operations like inserting, updating, and deleting records.

Triggers: Understand how to write Apex triggers to automate workflows and perform complex operations when specific conditions are met.

Governor limits: Learn how to optimize your code to stay within Salesforce’s limits on resources, ensuring that your applications run efficiently.

Through practical exercises and real-world use cases, TechForce Academy ensures that students not only learn Apex but are able to apply it effectively in development projects.

3. Visualforce Pages and User Interfaces

While Salesforce’s newer Lightning framework has become increasingly popular, Visualforce remains an essential part of many Salesforce environments.

TechForce Academy’s course covers:

Visualforce pages: Learn how to build custom user interfaces that are tailored to specific business needs.

Custom controllers: Understand how to bind Apex code to Visualforce pages using controllers, providing dynamic, data-driven UI experiences.

Component-based design: Build reusable Visualforce components to simplify and streamline development.

This module ensures that students understand how to create engaging, functional UIs when the out-of-the-box Salesforce interface isn’t enough.

4. Salesforce Lightning and Lightning Web Components (LWC)

Lightning Web Components (LWC) are the future of Salesforce UI development. In this part of the course, TechForce Academy dives into:

Introduction to Lightning: Explore the components, tools, and best practices for developing applications using the Lightning framework.

Building Lightning components: Learn to create modular, reusable components that can enhance functionality across Salesforce apps.

Lightning Web Components: Develop dynamic and responsive web components that integrate seamlessly with Salesforce data.

As more organizations transition to Lightning, learning these cutting-edge development skills through TechForce Academy will give you a competitive edge.

5. Data Modeling and Security

Salesforce development isn’t just about writing code; it’s also about managing data efficiently and securely. TechForce Academy emphasizes best practices in data modeling and security:

Custom objects and relationships: Understand how to create and manage data relationships in Salesforce, from lookup to master-detail relationships.

Validation rules: Use validation rules to enforce data integrity and ensure data accuracy.

Profiles, roles, and permission sets: Configure permissions to control access to data and functionalities across users.

Record-level security: Learn Salesforce’s sharing and security model to protect sensitive information and restrict access where needed.

TechForce Academy prepares you to design scalable, secure data models that align with real-world business needs.

6. Testing and Debugging Apex Code

Testing is a critical aspect of Salesforce development, and TechForce Academy ensures that students understand how to:

Write unit tests: Develop Apex unit tests to verify that your code works as intended.

Use debug logs: Learn how to analyze debug logs for troubleshooting and performance optimization.

Achieve code coverage: Salesforce requires a minimum level of code coverage for all Apex classes and triggers before deployment. TechForce Academy helps students meet and exceed these requirements.

This module ensures you can confidently deploy your code, knowing that it has been thoroughly tested and debugged.

Benefits of Completing the Salesforce Developer Course with TechForce Academy

TechForce Academy’s Salesforce Developer Course offers numerous benefits, including:

Hands-On Learning: The course is designed to give you practical, hands-on experience with Salesforce development, ensuring that you’re ready to apply your knowledge in real-world scenarios.

Career Advancement: By earning your Salesforce Platform Developer 1 (PD1) certification, you position yourself for better job opportunities and higher earning potential in the Salesforce ecosystem.

Comprehensive Curriculum: TechForce Academy’s curriculum covers all major aspects of Salesforce development, from Apex programming and Visualforce to data modeling, security, and testing.

Industry-Recognized Certification: The Salesforce Platform Developer 1 certification is highly respected in the industry. Completing the course at TechForce Academy prepares you to pass the exam with confidence.

Advanced Learning Path: The PD1 certification is the first step toward more advanced Salesforce certifications, including the Salesforce Platform Developer 2 (PD2) and specialized certifications like Marketing Cloud Developer or Service Cloud Consultant.

Conclusion

Enrolling in the Salesforce Developer Course at TechForce Academy is a game-changing step for aspiring Salesforce developers. By mastering core development skills like Apex, Visualforce, Lightning Web Components, and data modeling, you’ll be well-equipped to pass the Salesforce Platform Developer 1 (PD1) certification exam and succeed in a competitive field.

With hands-on labs, expert instructors, and a carefully crafted curriculum, TechForce Academy offers one of the most comprehensive and effective training programs for Salesforce development. Whether you’re just starting your career or looking to advance your skills, this course provides everything you need to become a proficient Salesforce developer and unlock new career opportunities.

Don’t wait—start mastering Salesforce development today with TechForce Academy!

[brainiateshow]

Exploring the Latest UI Features and Updates of Salesforce

The Summer ’24 release is now available, and with it, comes a set of enhancements aimed to please a wide range of businesses. Project managers and Salesforce UI lovers, get ready; there is something for you – right here, right now. The Summer ’24 release brings a number of features that could be really useful once implemented in Salesforce.

Project Management Gets a Kanban Kickstart

Project managers, rejoice! The Summer '24 update brings a revamped Kanban Board designed to streamline your workflow. Effortlessly prioritize tasks using drag-and-drop functionality. Visualize your team's structure with enhanced swimlane management. Gain unparalleled visibility into project flow with real-time progress updates. The Summer '24 update empowers you to manage your projects with greater efficiency.

This update goes beyond aesthetics; it's a strategic upgrade. The enhanced Kanban Board streamlines workflows, allowing for swift identification of roadblocks. It also fosters a collaborative team environment. These features empower Salesforce for project management with a sharper focus, ensuring projects stay on track and deadlines are met.

Welcome to the Era of Hyper-Personalized UIs: Salesforce Genie Makes its Debut

Forget about generic dashboards! Salesforce Genie was launched in September 2022 that marked the dawn of intelligent and dynamic user interface and it has only gotten better and better ever since. Picture the experience of AI presenting the relevant information at the right time, tools that adjust to the user’s responsibilities and needs, and visualizations that adjust to individual preferences. This is what Salesforce Genie, which is also known as Salesforce AI, is all about.

Salesforce Genie, powered by Einstein AI, takes user experience to a whole new level. It leverages AI to understand your behavior and work context, creating an intuitive and efficient interface. No more data overload! Genie anticipates your needs and surfaces the most relevant information at the critical moment. Project managers can expect to see key project health metrics displayed prominently, while sales reps might encounter personalized deal-specific insights. This tailored approach empowers users to focus on what matters most.

Lightning Web Components: Building Custom UIs Just Got Easier

Calling all Salesforce developers! The Summer '24 update brings exciting news for LWC enthusiasts. As a reminder, LWCs are reusable components that empower you to build custom user interfaces within Salesforce. This update streamlines the development process with improved error handling, enhanced testing capabilities, and simplified theming. Get ready to code with greater efficiency and precision!

The result? Faster development cycles, more robust custom applications, and a user experience that blends seamlessly with the familiar Salesforce interface. This empowers businesses to leverage LWCs to tailor Salesforce for project management perfectly to their needs. Imagine unlocking a whole new level of functionality and efficiency for your team.

Embrace the Power and Speed of the Salesforce Mobile App: Manage Projects on the Go

Project managers, rejoice! The Salesforce mobile app on your phone has always been a productivity booster, and the Summer '24 update makes it even better. Get ready for faster loading times, improved offline functionality, and a more intuitive navigation experience. Stay productive on the go with greater efficiency!

Now, you can check and modify project tasks, ratify costs, and work with your team – on your phone or tablet, offline, too. This update means you always stay on top of your projects, connected and efficient at work and on the go.

A Look Ahead: A More Inclusive and Accessible Salesforce Experience

Salesforce is dedicated to inclusion, and the Summer '24 release reflects that commitment. The update prioritizes accessibility features, making the platform more user-friendly for everyone. Project managers who rely on assistive technologies will appreciate the improved keyboard navigation. Additionally, the update boasts better screen reader compatibility and increased color contrast options, ensuring a smooth experience for all users.

Salesforce understands that a diverse workforce brings a wealth of perspectives. The Summer '24 update reflects this by prioritizing accessibility features that empower everyone to leverage the platform's full potential. Project managers with visual impairments, for example, can now utilize improved screen reader compatibility to effortlessly navigate Kanban boards and access crucial project data. This ensures an inclusive experience where everyone can contribute and succeed.

The Final Verdict: A Summer of Transformation for Salesforce Users

Salesforce update Summer ’24 is one of the most revolutionary, especially for project managers and Salesforce UI lovers. It brings a tsunami of new features, starting from AI-based personalization that adapts it to you, your need to improve project management tools that make the job more accessible, and an overhaul in accessibility that brings an easy flow to the platform. Today, Salesforce is not only getting smarter and more efficient but is also getting considerably more straightforward to use.

Ready to conquer the world of Salesforce? The Brainiate Salesforce Bootcamp equips you with the skills and knowledge to navigate the latest updates and features with ease. Led by Salesforce experts, this comprehensive program is your one-stop shop for mastering the platform. Stay ahead of the curve and unlock Salesforce's full potential to propel your career forward.

[yadavti]

How to Invoke Apex class from Lightning web Component?

Call Apex Methods in Salesforce LWC- In this tutorial we are demonstrating a case study in which our experts explaining how to invoke apex class from one salesforce lightning web component to other. LWC can import method from Apex classes into the JavaScript classes after importing the apex class methods we can able to call apex class as functions into the components by either we can call wire service or Imperatively. The Apex method should be marked by aura component. Today's we will check in how many ways we can call Apex method from Lightning Web Components (LWC). Firstly, we need to import the Apex class and its method. Secondly, we need to make a method available to Lightning Web Component (LWC). For more details please watch our video tutorial and if you like to share and subscribe our channel for live updates. We the BISP have 100+ real time professional trainers share their technical and real time professional knowledge with the students and the customer satisfaction is 100%. If you are looking for online training and real time project training you are on the right track, please visit our website BISP Trainings and call +91 769-409-5404 or +1 386-279-6856.

[soljit]

5 Things Salesforce Developers Can Get Excited for in 2022

Introduction

Salesforce is continually evolving to deliver amazing experiences for its end users. The Spring ‘22 release, just like all Salesforce updates - which happen three times a year - had interesting things for developers to be excited about.

In this blog, we take a look at these, as well as a couple of features that aren't exclusive to this release but should be available later this year. 

Foyer

Since we can design applications that connect Slack and Salesforce, you’ll need a middleware layer to connect the two. Foyer is a feature that will be available later this year (safe harbor). The foyer should enable us to focus development time on Slack and Salesforce platforms, drastically reducing the time it takes to build out solutions. Rather than coding the middleware from scratch, Foyer seamlessly integrates it into the system, making configuration simpler. 

Foyer was officially announced at Dreamforce in September 2021 and is now closed in Beta. It will be initially offered to ISV Partners for inclusion in their AppExchange packages, but now is a great time to talk to your administrators to see how these Slack apps can be used to streamline your business processes.

UI Test Automation Model (UTAM)

This will enable a more powerful method for developing automated UI tests. Traditionally, these types of tests have been very difficult to write and maintain, often requiring third-party tooling and solution. 

UTAM claims to make this much better by introducing the common Page Object model design pattern (which you may have seen if you’ve used Selenium for testing). UTAM’s Page Objects are written in JSON, and the big idea is to move away from Xpath locators to target DOM nodes, and instead utilize CSS.

Salesforce plans to make UTAM an open-source, with the possibility of it playing a larger role outside of Salesforce development. 

Lightning Web Security

Salesforce Locker Service has provided an extra layer of security to the web components served by our orgs, irrespective of whether they’re LWC or Aura components written by us, or provided by our suppliers. This crucial security has come as a technological cost, whether in the form of restricted cross-component support or reduced third-party JavaScript libraries that are compatible with Locker Service.

Lightning Locker is a robust security framework for Lightning components. It increases security by separating Lightning Components belonging to one namespace from those belonging to another. 

Flow Trigger order

From the onset, there has been no particular way to specify the order in which the record-triggered flow should run. This led to the adoption of the “one flow per object” practice, which in turn, led to the construction of large flows. 

However, this new update now allows for “trigger order” to be specified against before- or after-save flows. This is a huge thing for Salesforce Admins and Developers. 

Flow is evolving rapidly, and there are still noticeable parity gaps between flow and code from a developer’s perspective. It should be treated seriously and not overlooked for Apex without consideration.

Functions

Since the Winter ‘22 release, Salesforce Functions have been available. Still, relatively high costs and some other factors have led to slow adoption. In my opinion, Functions are the key solutions simpler, and we’re hoping for a price decrease or remodeling to happen this year.

You don’t need a license to get started with Salesforce Function. You can use the Salesforce Developer Tools to design and test functions right now. 

[yadavti]

How to communicate between two lightning web components using Events?

This tutorial describes how to communicate between two lightning web components using events. Events in LWC are built on DOM components. A collection of API’s and objects which is available in every browser. Migrate component events in Aura components to web-standard DOM events in Lightning web components. If you’re familiar with DOM events, you notice the same propagation behavior in Lightning web components. Lightning web components are custom HTML elements built using HTML and modern JavaScript. Lightning web components and Aura components can coexist and interoperate on a page. BISP provide online training for salesforce lightning web components in this training you will learn Why Lightning Web Component, Benefits of Web Component, Communication between Lightning Component and LWC, we are going to learn how we can start working with LWC and all about LWC. In our salesforce training we have adopted Projects based learning in which the candidates engaged with project implementation could be real time and they have to complete by their own along with our expert mentor guidance. In this topic our mentors explain what are lightning component attributes, usage and types. Starting from what is aura attributes and gradually we move towards description. An aura attribute is like a variable that we use in programming language or in Apex class.

[yadavti]

How to implement Update Functionality in Lightning Web Components?

Lightning web components are custom HTML elements built using HTML and modern JavaScript. Lightning web components and Aura components can coexist and interoperate on a page.

Usage of lightning-record-edit-form. If you wanna to learn how to build lightning web components

With real time examples and 03 project scenarios for your better understanding. 02 project include in training and one project is for you to practice for a real hands-on. That will be share after completion of training so you can implement LWC concepts and try to finish by own.  In our Salesforce lightning web component lwc online training you will be experience real scenario project-based training you’ll learn about lightning web components efficiently use of markup, JavaScript, apex and SLDC.

Let us discuss here how to use the lightning-record-edit-form. A lightning-record-edit-form component is a wrapper component that accepts a record ID and is used to display one or more fields and labels associated with that record. The lightning-input-field component is used inside the lightning-record-edit-form to create editable fields. We have already discussed in our previous videos about the Aura components that was how to display contacts using Aura that will really helpful if you have seen our video tutorials.

[tak4hir0]

Content last updated December 2020. Roadmap corresponds to Summer ’21 projections. Our forward-looking statement applies to roadmap projections. Guide Overview Looking to build forms on the Salesforce Platform? You’ve got multiple options, spanning the entire low-code to pro-code continuum. Representing low-code, Dynamic Forms in Lightning App Builder and Screen Flows in Flow Builder. Hanging out in the middle of the continuum is the ability to extend Screen Flows with LWCs. And representing pro-code is the LWC framework and its ever-growing library of base components. Options are great, but how do you determine which one (or which combination) is the right option? That’s where this doc comes in. Takeaway #1: For basic create/edit forms on a Lightning record page on desktop, use Dynamic Forms. Takeaway #2: Use Flow to build multi-screen forms. If you need to also meet precise UX requirements, layer in LWCs. Takeaway #3: If you need test automation, start with LWC. You can write unit tests for any LWC, regardless of where you plan to embed it. This doc focuses on form-building. You’ll see a similar assessment in Architect’s Guide to Building Record-Triggered Automation on Salesforce. A bit later, we’ll go into depth on these use cases and more, including how to choose between click-based tools and code-based tools (and when to combine them), but here are the major considerations to start with when choosing between these three options. Low Code Pro Code Dynamic Forms1 Screen Flow Screen Flow + LWC LWC Custom Object on Desktop Available Available Available Available Any Object on Desktop Roadmap Available Available Available Dynamic Visibility Available Available Available Available Multi-Screen Form Not Available Available Available Not Ideal Cross-Object Not Available Available Available Available Logic or Actions Behind the Form Not Available Available Available Available Dynamic Event Handling Roadmap Not Available Available Available Pixel-Perfect Styling Not Available Not Available Available Available Unit Testing Not Available Not Available Available Available 1Dynamic Forms is a feature of Lightning Pages. Lightning Pages are declaratively configured with the Lightning App Builder. As part of Summer ‘20, Dynamic Forms is a non-GA preview feature, and we aim to GA it in Winter ‘21. Available: works fine with basic considerations. Not Ideal: possible but consider an alternative tool Roadmap: estimated to support by Summer ’21 (targeted go-live mid-June 2021). Our forward-looking statement applies to roadmap projections. Not Available: no plans to support in the next twelve months. tl;dr Quickly, let’s elaborate on the takeaways and table above. If Lightning Pages and Dynamic Forms meet your requirements, use them. That means you need a create or edit form for exactly one object on desktop, and you need to control field visibility. Lightning App Builder may be a declarative tool, but this is where it excels. If your requirements aren’t met by those constraints, keep reading. Either Flow or LWC will be a better fit. If you need additional logic or actions behind the form, use Flow or LWC. Both tools offer ways for your solution to do more than create or edit a single record. That “more” might be more advanced logic, such as branching or iteration, and it might be more actions like integrating with external systems, sending emails, or pushing notifications to a user’s mobile app. If you’re building a multi-page form or a wizard, start with Flow. Flow provides a linear navigation framework for orchestrating multiple forms together. You could use LWC to construct your own framework for navigating between forms, but we recommend letting Flow do the hard work for you, so that you can focus on the forms themselves. Got sophisticated UX requirements? Need to dynamically handle more than visibility? Build that stuff in a LWC. If your requirements can be achieved with simple theming and column-based layouts, you can build your forms directly in a low-code builder. For more fine-grained control over your form’s style, you’ll need the ultimate flexibility of LWC. Keep in mind, your choice doesn’t have to be an either/or – you can combine the power of multiple options. For example, if you need both Flow’s built-in navigation system and the full styling flexibility that LWC offers, use them together. What About Page Layouts? You may notice that Page Layouts are missing from our comparison in this document. Moving forward, the recommended way to configure record detail pages is Dynamic Forms in Lightning App Builder using Lightning Pages. It’s been a long time since we enhanced page layouts, and that trend will continue. Here’s why. Dynamic Forms are more flexible – you can place fields and sections wherever you want directly in Lightning App Builder, where you can take advantage of sections, tabs, and accordions. And just like you can do with components on the Lightning page, you can control the visibility of your fields and sections without defining multiple page layouts or record types. With Accordion and Tab components, you can restrict the amount of fields that are displayed initially. Guess what that means? Faster page load times. Layout management is simpler with Lightning Pages, since you can manage everything about your pages from Lightning App Builder – whether that’s the contents of the page or which users have access to the page. It’s no longer necessary to make updates in your page layout to make a change happen in your Lightning page. Not to mention, with the power of component visibility rules, you no longer have to create multiple pages (or page layouts) to control who sees which fields when. And that also means you only need to assign users a Lightning page rather than doing that and also assigning the page layout. As of this non-GA preview, Dynamic Forms has a handful of limitations. We recommend using Dynamic Forms wherever possible, and falling back to Page Layouts only when necessary. For reference, here are the high-level gaps we’re aware of and when we plan to fill them. Timeline for Lightning Pages & Dynamic Forms Support for standard objects Spring '21 Support on the Salesforce mobile app Summer '21 Support in Community record pages Far Future Configure tab visibility Summer '21 Show, hide, and collapse section headers Spring '21 Conditional formatting of fields Summer '21 Conditionally make a field required Summer '21 Conditionally make a field read-only Summer '21 What About Performance? Any performance considerations related to Dynamic Forms, screen flows, and LWC center on what framework those technologies themselves sit on. The ones that are based in LWC (besides, of course, an LWC) are going to outperform ones that are based in Aura. The LWC framework offers better performance because core features are implemented natively in web engines instead of in JavaScript via framework abstractions. If you’re not familiar give this blog post a read. Back in 2019, we did a case study comparing the performance of the same functionality in Aura vs. in LWC. As a result of converting DreamHouse from Aura to LWC, not only was the development experience far more aligned with current web front-end development standards and patterns, but the performance gains are significant. Lab measurements showed gains in the range of 2.4 percent to 24.7 percent for cold cache and gains in the range of 31.83 percent to 63.32 percent for warm cache on the same two pages. Now, which framework are our form technologies using? In other words, which form technologies benefit from this superior performance? Dynamic Forms, which is integrated in the Lightning pages metadata, are built on a brand new foundation that uses the LWC stack, which will enable us to implement some long-requested features. Building everything from ground up takes time, which is why Dynamic Forms currently has some limitations – like standard object and mobile experience support. Screen flows are built on a mixed stack. Today, the flow runtime client uses an Aura container application, and most of the individual components you can display in a flow screen are Aura. A few have been converted to LWC so far: Text, Checkbox, Date, and DateTime. The Flow team is committed to converting the flow runtime client to use 100% LWC components instead of Aura, with the exception of customer-created (that’s you!) Aura components. We can’t convert those for you, but there is an excellent Trailhead module that explains how to do so: Lightning Web Components for Aura Developers. It goes without saying: if you’re thinking about building a custom component for a screen flow or any other container, always go LWC. LWC is built on ... LWC of course. This is a freebie. 🤓 Navigating the Low-Code to Pro-Code Continuum Most of this doc focuses on helping you understand what functionality and level of customization is possible with Dynamic Forms, screen flows, and LWC. LWC is the most customizable and robust option for building a form, but it has the fewest guardrails in place. It’s up to you to build a component in a way that ensures security and scalability. Dynamic Forms is the least flexible, but there are far fewer opportunities for missteps. Flow sits somewhere in the middle – more powerful than Dynamic Forms but not quite at the level of LWC. By the same token, it has fewer guardrails than Dynamic Forms but is harder to break than custom code. If multiple tools fit the bill, the decision comes down to which tool is the right one for your team. Introducing the Salesforce Architect Decision Guides on the Salesforce Architects blog introduces some aspects to consider when making that decision. We won’t go into the details of each of those aspects here, but what we will do is interpret them for the specific tools this doc is assessing. Specialized Skills: What percentage of your team is already an expert in the tools you’re comparing? How many makers are well-versed and familiar with LWC or Javascript? How about makers who are experts in Flow Builder or have expressed an interest in dipping their toes? Generally speaking, Dynamic Forms and Flow are more attainable for a broader population of makers. Dynamic Forms is the most declarative form-building tool and will always be easier to learn than Flow. That said, the Flow team is committed to getting that bar as low as possible. Delegation of Delivery: Just because part of your requirements require LWC doesn’t mean the entire solution needs to be built with LWC. Consider how you can build your solution modularly, such that the bits that require LWC are coded, and the bits that don’t are built in a low-code solution. Doing so maximizes the impact of a diverse team and ensures that makers are solving problems appropriate for their specialization. Maintainability & Long-Term Ownership: If you anticipate this form will be maintained in the future by pro-code makers and your current team is highly familiar with Javascript frameworks, it makes sense to choose LWC as your solution of choice. If, on the other hand, low-code makers will be responsible for maintaining the form, consider how you can make the solution as configurable as possible for that audience. Diving Deeper As promised, we’re diving deep into a variety of comparison points and functional differences between Dynamic Forms, Screen Flows, Screen Flows with embedded LWCs, and the LWC framework itself. Available: works fine with basic considerations. Not Ideal: possible but consider an alternative tool. Requires ...: possible with help, such as from Apex. Roadmap: estimated to support by Summer ’21 (targeted go-live mid-June 2021). Our forward-looking statement applies to roadmap projections. Not Available: no plans to support in the next twelve months. Low Code Pro Code Dynamic Forms1 Screen Flow Screen Flow + LWC LWC Object Scope Single Object Available (Custom Objects) Available Available Available Cross-Object Not Available Available Available Available Object-Agnostic Not Available Available Available Available Form Scope Single-Screen Form Available Available Available Available Multi-Screen Form Not Available Available Available Not Ideal Location Lightning Record Page Available Available Available Available Lightning Home or App Page Not Available Available Available Available Communities Not Available Available Available Available Embedded Snap-Ins Not Available Available Available Available Utility Bar Not Available Available Available Available Object-Specific Action Not Available Available Available Roadmap Global Action Not Available Not Available Not Available Roadmap Salesforce Mobile App Not Available Available Available Available Field Service Mobile Not Available Available (Object-specific action) Not Available Roadmap Mobile SDK Not Available Not Available Not Available Roadmap External Sites & Apps Not Available Available Available Available Custom LWC Not Available Not Available Not Available Available Controller Logic & Actions Not Available Available Available Available Operation Within One Transaction Not Available Available Available Requires Apex Operate Across Multiple Transactions Not Available Available Available Available Integration Not Available Available Available Requires Apex Modular Design & Reuse Not Available Available Available Available Validation Respect System-Level Validation Available Available Available Available Custom Field Validation Specific to this Form Available Available Available Available Custom Form-Level Validation Not Available Not Available Available Available Security Elevate User Permissions Not Available Available Available Requires Apex Restrict Who Can Access Available Available Available Available Restrict Allowed Locations Not Available Not Available Not Available Available Interaction Design Conditional Visibility Available Available Available Available Conditional Requiredness Roadmap Not Available Available Available Conditional Formatting Roadmap Not Available Available Available Conditional Read-Only State Roadmap Not Available Available Available Standard Event Handling (such as onblur, onfocus) Not Available Not Available Available Available Custom Event Handling Not Available Not Available Available Available Styling Org and Community Themes Available Available Available Available Pixel-Perfect Styling Not Available Not Available Available Available Layout 2 Columns Available Available Available Available 4 Columns Roadmap Roadmap Available Available Beyond 4 Columns Roadmap Not Available Available Available Tab and Accordian Containers Available Not Available Available Available Translation Labels Entered in the Builder Roadmap Available Available* Not Available Labels in the Code Not Available Not Available Available Available UI Test Automation Unit Tests Not Available Not Available Available Available End-to-End Automation Requires Code Requires Code Requires Code Available Metrics Page Views Available Available Available Available* Time Spent on Form Not Available Not Available Available Requires Apex Time Form Completion Not Available Not Available Available Requires Apex Track Success Rate Not Available Not Available Available Requires Apex 1Dynamic Forms is a feature of Lightning Pages. Lightning Pages are declaratively configured with the Lightning App Builder. As part of Summer ‘20, Dynamic Forms is a non-GA preview feature, and we aim to GA it in Winter ‘21. Object Impact What objects will the form operate against? Just one object? Multiple objects? Dynamic Forms Screen Flow Screen Flow + LWC LWC Single Object Available (Custom Objects) Available Available Available Cross-Object Not Available Available Available Available Object-Agnostic Not Available Available Available Available If your form operates against a single Salesforce object, any of the tools we’re comparing will work. Things get a little more complicated with cross-object or object-agnostic forms. By object-agnostic, we mean inputs that don’t map to any Salesforce object. Perhaps your form represents a data structure that you’ll send to an external service, like Stripe or Docusign. Or perhaps you’re using several inputs in your form to calculate a value, and then committing that value to the database. For both cross-object and object-agnostic forms, Flow is a solid option. The components available in flow screens are agnostic by nature, so you can choose what to do with that data behind the scenes. For example, use the data entered in one form to create multiple records behind the scenes, or use the data to perform other actions like generating Chatter posts, sending emails, or connecting to external services. For simple cases, using existing LWC components like lightning-record-form can be a simple way to lower code needed to provide a robust solution. However, for scenarios where multiple objects are involved, Flow provides cohesive control for all objects and removes complexities of developers having to traverse complex relationships and dependencies. Form Scope Do you need a single screen, or will the user need to navigate between multiple screens to complete a task? Dynamic Forms Screen Flow Screen Flow + LWC LWC Single-Screen Form Available Available Available Available Multi-Screen Form Not Available Available Available Not Ideal If you can get all of your user’s inputs from a single-screen form, start with Dynamic Forms. If you need more functionality than what Dynamic Forms offers, the choice between Flow and LWC depends on a few other questions. What skills does your team have? For a more admin-heavy organization, we recommend starting with Flow. For a more developer-heavy organization, start with LWC. Is it OK to display a navigation bar at the bottom of your form? If the flow navigation bar is undesirable UX, swing towards LWC. What needs to happen behind the form? If you need the behavior to be configurable by an admin, build a flow. Otherwise, build a LWC. If you choose Flow, you may need to build a LWC anyway to achieve the right UX. If you’re already building a LWC to style your form correctly, consider whether embedding that component in a flow is overkill. If, on the other hand, your solution looks like a wizard, where the user navigates between multiple screens, think Flow. Flows come with a built-in navigation model, so you don’t have to build and maintain that yourself. The navigation is linear in nature, with forward-moving actions (Next and Finish), backward-moving actions (Previous), and a mechanism for saving the form for later (Pause). You can also build a form with non-linear navigation if it suits your purposes. For a great example of that, check out this Salesforce Labs package: Digital Store Audit. Location Where do you want to embed the form? Dynamic Forms Screen Flow Screen Flow + LWC LWC Lightning Record Page Available (Desktop) Available Available Available Lightning Home or App Page Not Available Available Available Available Communities Not Available Available Available Available Embedded Snap-Ins Not Available Available Available Available Utility Bar Not Available Available Available Available Object-Specific Action Not Available Available Available Roadmap Global Action Not Available Not Available Not Available Roadmap Salesforce Mobile App1 Not Available Available Available Available Field Service Mobile Not Available Available (Object-Specific Action) Not Available Roadmap Mobile SDK Not Available Not Available Not Available Roadmap External Sites & Apps Not Available Available Available Available Custom LWC Not Available Not Available Not Available Available 1 Flows and LWCs are supported in the Salesforce mobile app, but the Salesforce mobile app doesn’t support all the ways you can embed flows and LWCs. For example, object-specific actions are supported in mobile, but utility bar items are not. Since they require a record context, Dynamic Forms are supported only in Lightning Record pages. However, Dynamic Forms aren’t supported in Lightning Community pages. This limitation is in place because Lightning communities don’t use the underlying framework that Dynamic Forms depends on: Lightning Pages. We are definitely evaluating this as we do often hear feedback of wanting Dynamic Forms in Communities. Roadmap! Today, Dynamic Forms are supported only for custom objects on desktop, but Salesforce is actively working on supporting them for standard objects and the Salesforce mobile app as well. You can build flows that require a record context or flows that work globally. As such, you can embed flows in a variety of locations. For the record-contextual flows, that might be a Lightning record page, a Community record page, an object-specific action, or an Actions & Recommendations deployment. For the global flow, that might be the utility bar, other Lightning or Community pages, a snap-in, or an external application. Flows aren’t currently supported as global actions, but as a workaround you can wrap the flow in an Aura component. LWC supports a high degree of reusability, since you are creating components and able to associate with targets via metadata across Salesforce, Communities, and even in Open Source Projects. LWC components can also be embedded inside of your own website via Lightning Out. LWCs aren’t currently supported as quick actions (object-specific or global), but – much like you can with flows – as a workaround you can wrap the LWC in an Aura component. None of the form technologies covered in this doc are officially supported in Mobile SDK templates today. If Mobile SDK is paramount to your use case, you’re better off building your form in natively in your mobile application or building a Visualforce page. Roadmap! The Mobile SDK team is actively working on supporting LWCs within Visualforce pages. Controller What actions or logic do you want to be performed behind the scenes? Dynamic Forms Screen Flow Screen Flow + LWC LWC Logic & Actions Not Available Available Available Available Operate Within One Transaction Not Available Available Available Requires Apex Operate Across Multiple Transactions Not Available Available Available Available Integration Not Available Available Available Requires Apex Modular Design & Reuse Not Available Available Available Available Dynamic Forms is perfect if you need to use the values in your form to create or update a record. For anything beyond that capability, you’ll need to leverage Flow or LWC. That might be a layer of decisioning or iteration, or you might generate Chatter posts or emails using the inputs from the form. Flow offers standard actions for posting to Chatter, sending email, and interacting with Quip documents, so you don’t have to write code for the same operations. LWC offers rich interactions with single records and related objects through the use of wire adapters that interact with UI API. LWC can also interact with multiple records when using the wire for getListUi. Both Flow and LWC integrate with Apex, so you can easily close the gaps in whichever solution you choose. For example, if you require filtering records from an LWC you can always use the wire adapter for Apex to create complex SOQL queries. If you’re swayed by the click-based story, consider Flow as a viable alternative to an Apex controller for your server-side needs. A secondary question to answer here about the actions is whether you want to immediately commit them, or defer them to a particular part of your form. This is especially relevant if you’re in a multi-page form. Flow makes it easy to combine inputs from multiple forms (flow screens) and use them much later in the wizard (flow) to perform some operations. In fact, we recommend designing flows in just that way – perform actions at the end – in case the user bounces back and forth between screens, thereby changing their answers. Do you need to control which operations occur in which transaction? Transactions and governor limits are a way of life on the Salesforce Platform. If your use case is fairly simple, it may not be as important to control what transaction a particular operation occurs in. However, there are a few use cases where you might want to combine multiple operations into a single transaction rather than performing those across multiple transactions. Some examples: To Rollback Or Not to Rollback: That is the question. Let’s say your form creates multiple records behind the scenes. If the third record fails to be created, should the first two records be rolled back? If each of your actions are independent of each other, feel free to execute them in separate transactions. If they’re dependent, however, and you want the failure of one to also rollback the others, implement them in a single transaction. Downstream Impact on Governor Limits: Especially when your form creates or updates a record, consider what the downstream implications of that operation are. What processes, workflow rules, flow triggers, Apex triggers, or other items in the save order are going to fire based on this record change? And how do those collective changes impact the governor limits being consumed in that transaction? If a particular record change will result in a lot of downstream changes that impact your limits, consider isolating that record change into its own transaction. Batch Processing: Even in a UI context, you may need to batch multiple updates together. Let’s say your multi-screen form iterates over a large group of records. Rather than committing a record update after each screen, wait until you’ve collected the updates for all of the records and then submit one request to update all the records. When you use a Dynamic Form to create or edit a record, you’re only ever performing one operation, and that operation is always the start of a net-new transaction. When building a screen flow, you have significant control over what happens in a given transaction. Screens and Local Actions act as boundaries between transactions. Here’s a high-level summary of how transactions are managed in the screen flow architecture. The end user interacts with a screen, and then clicks Next. The client posts a request to the API with the inputs. The API receives the request, and a transaction and database connection are opened. The API then then calls the Flow engine to invoke the request. The Flow engine takes over and follows the appropriate path in the flow definition – until it hits a Screen or Local Action node. The engine then returns information about that node to the API. The API creates a response object that contains the details of the next screen to render, and returns that object to the client. At this point, database changes are committed (cue the save order execution), and the database connection and transaction are closed. The client uses the API response to render the next screen for the user to interact with. Rinse and repeat. In other words, screens “break” transactions. When that happens, any pending actions or DML are committed, the prior transaction is closed, and a new transaction is started. The right design – which operations you group into a given transaction – is your call. On the left, you can see a flow that collects inputs across multiple screens, and then performs several actions in one transaction. The flow on the right performs each operation in a separate transaction. For more details, check out these resources on Salesforce Help: Flows in Transactions and Flow Bulkification in Transactions. Your ability to control the transaction from an LWC comes down to the underlying services that LWC is using to perform its operations. If you’re using the lightning-record-form base component, the underlying operation (creating or updating the record) happen in a standalone transaction as soon as the form is submitted. In general, these rules apply: Each UI API call is isolated into its own transaction. If you need to perform multiple operations within a single transaction, send the inputs off to a server-side technology like an Apex controller or a flow. The regular transaction rules for that technology apply. Do you need to integrate with external systems? Both Flow and LWC support API integrations with an assist from Apex. Additionally, Flow supports External Services – which enables you to declaratively generate process integration building blocks. Anyone can integrate with legacy systems or web apps, as long as those services can be described with an OpenAPI-compliant schema. For example, you can generate actions for integrating with Slack or Google Sheets, and then configure your flow to post to a Slack channel or add a row to a particular Google Sheet. The end-to-end solution involves touching zero lines of code. Regardless of whether you do so with custom Apex or an External Service, a callout is a callout. Here’s what you need to know. A callout can take a long time. When a callout is executed synchronously, it's performed while a database transaction is open. Salesforce doesn't let you keep a database transaction open if you've got pending database operations. The main limitation to keep in mind is the danger of what we call a dirty transaction, where you perform a create, update, or delete operation and then, in the same transaction, execute a callout. This pattern isn’t allowed because of consideration #3, which of course exists because of considerations #1 and #2. You can work around this limitation by breaking the transaction. As we mentioned above, screens and local actions both reintroduce the browser context, which breaks the transaction. Use a Screen to break a transaction if it makes sense to display a new form to the user prior to making the external callout. If it doesn’t, we recommend a no-op local action, like this one available to install from UnofficialSF. Not familiar with local actions? They’re Aura components with no markup; the flow executes the invoke() method in the component’s Javascript controller. They’re the only actions available in Flow that aren’t performed server-side. In addition to being useful for breaking transactions, local actions are great for performing browser-level actions like firing toasts or force navigating the user. On the left is a flow that updates a record, then uses a callout to request a list of Slack channels. This flow fails at runtime, because the callout occurs in the same transaction after a pending database operation (the record update). To the right is a flow that updates a record, executes a no-op local action, and then uses a callout to request a list of Slack channels. This flow succeeds at runtime, because the callout is performed in a separate transaction from the record update. The impact of callouts on the transaction is less complicated with LWC. Generally speaking, you’ll perform your data operations using the Lightning Data Service, and then use an Apex controller to make the external callout. This design protects you from dirty transactions, since the LDS call is isolated in its own transaction separate from the Apex callout. What are your requirements for reusability and modularity? Dynamic Forms doesn’t support reuse. Each Dynamic Form is tied to a specific Lightning record page for a specific object. Though you can assign that Lightning record page to multiple apps, profiles, and so on. Much like you can write libraries, utilities, and components that are intended to be used across multiple other components, you can apply similar design patterns when creating flows with the power of subflows. Save your flows in smaller, more modular buckets, and then call them from other flows by using the Subflow element. If your design calls for it, you can build a flow that both stands on its own and is useful as a subflow of another one. Flow and LWCs can both be built for reuse, such that you can embed them in a variety of locations including external sites and Lightning Out applications. Validation What are your validation requirements? Dynamic Forms Screen Flow Screen Flow + LWC LWC Respect System-Level Validation Available Available Available Available All technologies that attempt to create or update a record adhere to system-level validation – whether those are classic validation rules or custom validation built into an Apex trigger. No matter what technology you use to perform a record change, every change goes through the save order. That means in addition to validation rules, the record change is processed by any number of before- or after-save flows, before or after triggers, escalation rules, assignment rules, and more. If you haven’t already, now’s a good time to bookmark and familiarize yourself with the Order of Execution. Inputs on a flow screen are by nature unbound, so the screen itself doesn’t natively adhere to system-level validation associated with a particular object. Whatever values you use to Create or Update records, however, are processed by the save order, which means they pass through the object’s system-level validation. Dynamic Forms Screen Flow Screen Flow + LWC LWC Custom Field-Level Validation Specific to this Form Available* Available Available Available Custom Form-Level Validation Not Available Not Available Available Available Just like page layouts, Dynamic Forms let you set requiredness and read-only state at the page level. However, you can’t override system-level settings. Flow provides flexibility for customizing validation on a form’s inputs. While some checks are performed in the client (like flagging missing required fields or incompatible values), none of the client-side validation blocks the user from trying to navigate. The real stuff happens on the server. When a user clicks Next, Flow sends the inputs to the server for validation. If any inputs are returned as invalid, navigation is blocked and the appropriate error is displayed. The server validates the inputs by checking: The input’s requiredness setting, or whether the entered value is compatible with the underlying data type. Custom validation on that input: Several standard components (Checkbox, Currency, Date, Date/Time, Long Text Area, Number, Password, and Text) support custom validation on a per-screen basis. Supply a Boolean formula expression and an error message to display when the formula expression isn’t met. Custom validation on the underlying component: If you’re building a custom LWC for a flow, add your own validation code to the validate() method. On the LWC side, most base components perform their own client-side validations. For example, lightning-record-form respects system-level requiredness, but not page-level requiredness. For your custom components, you can build your own validation mechanisms. Security What are your security requirements? Should the form check the user’s access before performing certain operations? (Especially important when building for guest users) Dynamic Forms Screen Flow Screen Flow + LWC LWC Elevate User Permissions Not Available Available* Available Requires Apex Do your users have field-level security to see this field? Do they have permission to create records for this object? What about access to this specific record, based on your org’s sharing rules? When something runs in user context, we enforce those access checks. Users can run a case update form only if they have the ability to update cases, the appropriate field-level security, and access to the record in question. But what if you don’t want to grant users a particular permission? What if you want users to be able to perform a particular operation when they're using your form, but not through any other form or interaction? That’s where system context comes in. System context is a way to elevate the running user’s permissions for the duration of the session, so that the user doesn’t need Update access to the Case object to successfully complete your case update form. This is especially useful for unauthenticated communities. Instead of granting guest users dangerous abilities, set your form to run in system context. Of course, system context is a double-edged sword and you should use it only when necessary. When a form runs in system context, every single CRUD operation bypasses object- and field-level security & sharing – not just the specific operation you care about. Note that system context has no bearing on who Salesforce considers the actor – the name you see in the Last Modified By field. For each operation that your form performs, such as the case update, the actor is the running user even if the form runs in a different context. Dynamic Forms always run in user context, and there’s no way to override this behavior. Screen flows run in user context by default, but you can set them to run in system context. It’s your choice whether the flow should grant access to all data or if it should still enforce record-level access like sharing. If you embed a Lightning component in a flow that runs in system context, the flow doesn’t override the component’s context. If you need to bypass user access checks, we recommend using the flow to perform those operations and pass the appropriate data into or out of the Lightning component. If your flow calls Apex actions, there are some more nuances to understand. If the Apex class is set to inherited sharing, it runs in system context with sharing no matter what the flow is set to. If the class has no explicit sharing declaration, it runs in system context without sharing no matter what the flow is set to. If the class is set to with sharing or without sharing, it does so and overrides the flow's context. Best practices: Leave the flow to run in its default context unless you need to elevate the running user’s access for a specific operation. If the flow performs a variety of operations and not all of them require elevated access, use a subflow to isolate the operations that should run in system context. LWCs run in user context by default, but you can override that in an Apex controller. Operations performed through the UI API are run in user context. Operations performed through an Apex controller depend on that class. To perform those operations in system mode, set the Apex class to with sharing or without sharing. Do you want to control who can access the form? Dynamic Forms Screen Flow Screen Flow + LWC LWC Restrict Who Can Access Available Available Available Available To address this requirement, often you can look to the container you’re embedding your form in. For example, you can assign Lightning pages to be available for particular apps, record types, or profiles. If particular inputs in your form are sensitive, use visibility rules to further control what is displayed to who – this feature applies to both Dynamic Forms and screen flows. You can restrict a flow to particular profiles or permission sets, much like you can an Apex class or Visualforce page. By default, flows are unrestricted, which means that any user with the Run Flows user permission can run it. Best Practices: If you’re exposing a flow to guest users, grant the guest user profile access to only the flows they need. You can add Run Flows to the guest user profile but we consider that a dangerous practice. Be especially careful with flows that operate in system context. We highly recommend you restrict those flows to a particular set of users, since they have fewer checks and balances in place to protect your data. For LWCs, you can check the running user’s permission assignments to confirm if they have a particular standard or custom permission. Directly from Javascript, you can import Salesforce permissions from the @salesforce/userPermission and @salesforce/customPermission scoped modules. Or you can use Apex to check the same. Do you want to control where the form can be embedded? Dynamic Forms Screen Flow Screen Flow + LWC LWC Restrict Allowed Locations Not Available Not Available Not Available Available Once a screen flow is activated, it’s available in all the locations that screen flows are supported, regardless of whether you intended it to be available everywhere or not. That said, Flow Builder supports multiple types of flows that have screens. The bread-and-butter type is Screen Flow, but there are a few other specialized types that are restricted to specific locations. For example, only Field Service Mobile Flows are supported in ... you guessed it, the Field Service mobile app. The same story goes for Contact Request Flows, which are supported only in communities. Regardless of the flow type, the individual making the flow has no control over where the flow can be embedded. The flow will be available in every location supported for that flow type. LWCs, on the other hand, are available in a given location only when it’s been added as a valid target. So you can make a component available on Record pages and not available as a utility bar item. Interaction Design Should your form react dynamically to interactions or conditions? Static forms are a thing of the past. Today, it’s all about dynamically updating the form with the right properties and values for this user, this time, this place. Let’s talk about what’s possible in this vein for Salesforce’s form-building tools. Dynamic Forms Screen Flow Screen Flow + LWC LWC Conditional Visibility Available Available Available Available Conditional Requiredness Roadmap Not Available Available Available Conditional Formatting Roadmap Not Available Available Available Conditional Read-only State Roadmap Not Available Available Available Visibility can be dynamically controlled in all three tools. Both Dynamic Forms and Flow Builder address this with features called Component Visibility. With this, you can declaratively show or hide fields based on other values on the form or whether the user is on a mobile device or not. With Dynamic Forms, you’re limited to fields on the associated object and there are some limitations on the supported field types and operators. With Flow, you can base a visibility rule on other inputs on the screen, as well as other resources populated earlier in the flow like formulas or values from other records. Device-based Rules: It’s not obvious from the get-go, but you can use a formula to show or hide a particular field when the user is on a mobile device. Write a flow formula that checks the value of the $User.UIThemeDisplayed global variable. If the value is Theme4t, the user is on the Salesforce mobile app. Evaluating Other Resources: Manual variable and formula references are evaluated only on the server. So whatever value that resource has when the screen first renders is the value it will have until you navigate to another screen. On navigation, the flow runtime submits a request to the flow engine (the server) and gets back the latest values of the manual variables and formulas. If you expect your visibility rule to update as the user passes through a single screen (aka onblur), make sure that you’re referencing only values from the other components on the screen. If you need to dynamically control any other properties, such as whether a field is required or read-only, your best bet in the short term is LWC, where you get full control. That’s especially true if you have bespoke requirements for what to do onblur or onclick. Roadmap! For Lightning Pages, which includes Dynamic Forms, we anticipate enabling conditional requiredness, conditional formatting, and conditionally setting an input to read-only in the next 12 months. Dynamic Forms Screen Flow Screen Flow + LWC LWC Standard Event Handling (such as `onblur`, `onfocus`) Not Available Not Available Available Available Custom Event Handling Not Available Not Available Available Available Now for custom events. If some of your inputs or the entire form need to communicate with something else in the page, LWC is your only option. For more details, check out Communicate with Events and Communicate Across the DOM in the Lightning Components Dev Guide. Styling How sophisticated is your desired styling and CSS? Dynamic Forms Screen Flow Screen Flow + LWC LWC Org and Community Themes Available Available Available Available Pixel-Perfect Styling Not Available Not Available Available Available Both Dynamic Forms and flows respect declarative theming features. If you need control beyond what Salesforce Themes or Community Branding Sets support, you need the wide open spaces of LWC. Reminder: You can embed Lightning components in flows. So if you need pixel-perfect control over the look-and-feel of your form but want to use the other benefits of flows, like the navigation model, you can have the best of both worlds. Layout What are the layout requirements for your form? Dynamic Forms Screen Flow Screen Flow + LWC LWC 2 Columns Available Available Available Available 4 Columns Roadmap Roadmap Available Available Beyond 4 Columns Roadmap Not Available Available Available Tab and Accordion Containers Available Not Available Available Available Dynamic Forms supports two-column layouts. Dynamic Forms can be broken up into individual sections with fields. These sections can be placed in components such as tabs and accordions to create easy to use and organized layouts. Flows can be rendered using a two-column layout. This feature is supported only when you add a flow to a Lightning or Community page, or when you use a direct flow URL, such as for a custom button. Due to our near-term roadmap, we recommend not using this feature. Roadmap! Salesforce is actively working on multi-column screens for Flow Builder. When this feature ships, you’ll be able to declarative configure screens with up to 4 columns. With LWC, you can use lightning-record-[edit|view]-form and the supporting lightning-[input|output]-field to control layout. The only layout restrictions are those from HTML/CSS. lightning-record-form respects the section configuration in the associated page layout – if a section is two-column in the page layout, it’s two-column in this component. Translation Does your form need to be localized to other languages? Dynamic Forms Screen Flow Screen Flow + LWC LWC Labels Entered in the Builder Roadmap Available Available* Not Available Labels in the Code Not Available Not Available Available Available If you’ve localized your custom fields, those translated labels are respected on Dynamic Forms. However, localization isn’t supported for labels that you add to components in the same Lightning page. For example, the label for a tab in the Tabs component. Roadmap! Salesforce is actively working on filling this gap. Soon, you’ll be able to reference Custom Labels for any string or rich text property in Lightning App Builder, such as to localize a custom Tab or Accordion label or the title you added to a Report component. With the power of Translation Workbench, Flow supports translation of user-facing labels for some, but not all, of the available screen components. For the following screen components, you can localize the label, help text, and error message: Text, Long Text Area, Number, Currency, Checkbox, Radio Buttons, Picklist, Multi-Select Picklist, Checkbox Group, Password, Date, and Date/Time. The other components don’t yet support translation, because they’re Lightning components under the hood and we don’t have a way of identifying which Lightning component attribute should map to label vs. help text vs. error message. The same issue applies for our out-of-the-box actions, like Send Email or Post to Chatter. However, there is a workaround! If you define the translated labels with a Custom Label, you can reference that custom label in the action or component when you configure it in Flow Builder. Create a flow formula that references the custom label, and reference that formula in the appropriate places in your flow. Now for LWC. Certain base components automatically inherit translations of the associated object’s fields, help text, and validation messages if they’ve been configured in Translation Workbench. For example lightning-record-form . If you need to introduce novel translatable labels in your code, Custom Labels are still the unsung hero. Declare the custom label you need, and then import it into your component from the @salesforce/label scoped module. UI Test Automation Do you need automated testing? Dynamic Forms Screen Flow Screen Flow + LWC LWC Unit Tests Not Available Not Available Requires Code Available End-to-End Automation Requires Code Requires Code Requires Code Available Consider your requirements for UI test automation. Unit tests enable more granular automation and validation that works with industry standard CI/CD systems and tools, which can test the components business logic, its Javascript controller, and its outputs. Going exclusively with low-code you will not be able to self author tests, but Salesforce rigorously tests our end-to-end offerings. If your component’s methods are complex enough that you want them to be tested individually, put the methods into dedicated JS files. That way you can import them into a LWC and into a Jest test with something like import { sort } from 'c/utils';. With end-to-end (Selenium) automation, you can simulate how the user interacts with your form. However, these tests can't verify the outputs of each method being performed. You can write these tests for any standard or custom UI – Lightning pages and screen flows inclusive. This recent blog post UI Test Automation on Salesforce compares the various options you have for building end-to-end automation on Salesforce. Included are considerations for when to use a no-code solution from an ISV, build your own custom test automation solution, or use an open source test framework like Selenium WebDriver or WebdriverIO. These solutions are valid for any UI interaction in Salesforce, whether that’s a Dynamic Form in a Lightning page, a screen flow in a utility bar, or an LWC in a flow in a quick action. Metrics Do you need to track usage of your form? Dynamic Forms Screen Flow Screen Flow + LWC LWC Page Views Available Available Available Available* Time Spent on Form Not Available Available Available Available Track Form Completion Not Available Available Available Available Track Success Rate Not Available Available Available Available If you need to track overall usage and adoption of your form, start with the low-code tools. Both Dynamic Forms and Screen Flows are trackable using out-of-the-box custom report types, though you’ll get more granularity from the Screen Flow tracking reports. If you need to track usage of a LWC, out-of-the-box availability depends on where you’re using that LWC. If it’s on a Lightning page, whatever is available for tracking Lightning page usage applies to your LWC. The same story goes for LWCs that are embedded in flows. Dynamic Forms themselves aren’t trackable out-of-the-box, though you can track the usage of the parent Lightning page through Lightning usage objects. To track the standard Lightning pages, use the Users with Lightning Usage by Page Metrics custom report type. For the same on custom Lightning pages, use the Users with Lightning Usage by FlexiPage Metrics custom report type. For tracking adoption of your specific form (not just the page it lives in), Flow’s got you covered. Use the “Sample Flow Report: Screen Flows” to answer questions like: What’s the completion rate for this form? Is it being well-adopted? How long does it take users to complete this form? Which screen do users spend the most time on? How often do users navigate backwards? How often do errors occur? If the standard report doesn’t meet your needs, clone it to make your own changes or build your own from scratch by using the Screen Flows report type. To track the same for an LWC that isn’t embedded in a screen flow or Lightning page, there’s no out-of-the-box option. You can build a DIY solution by using Apex. Closing Remarks Hello, and welcome to the end of this guide! 🏁 Kudos for making it through the equivalent of 9 double-sided pages. Have a good day and thanks for the read. Hope you learned something. Tell us what you think Help us make sure we're publishing what is most relevant to you: take our survey to provide feedback on this content and tell us what you’d like to see next.

[tak4hir0]

Deliver Scalable Experiences Without Limits Using Functions We’re proud to launch the Salesforce Functions Beta in our Summer ‘21 release, and we look forward to its GA in our Winter ’22 release. Salesforce Functions is a new service on the Salesforce Platform that enables you to deliver more scalable experiences by extending the data and workflows that you already have, making them more robust with the power of elastic compute and open language flexibility. You can now significantly accelerate developer productivity on trusted, managed Salesforce infrastructure through pre-authenticated and preconfigured access to Salesforce data and integration with low-code tools like Flow. Functions allows developers to write code that implements their business logic, which can then be assembled as building blocks in Flows or integrated with Lightning Web Components. Salesforce Functions amplifies low-code productivity with the power and flexibility of custom software, including access to open language ecosystems of libraries and packages. Let’s take a deeper look into what this actually means, and along the way, we’ll show you the updated Developer Tools experience. What’s new in the Salesforce Functions Beta Higher performance with no limits and elastic scale Build applications faster and without limits for more complex business logic or compute-intensive traffic/request activity. Salesforce Functions retains all the security and compliance you trust Salesforce to provide, so you no longer need to deal with VPNs, security tokens, Cloud IAM, and all the DIY complexity when you go off of the Salesforce Platform. Open languages and framework support in your SFDX project, including Java and Node.js Functions let you program in industry-standard languages, such as Node.js and Java. This brings the expressive power of these languages to your apps, as well as the entire ecosystem of tools, libraries, and developers to accelerate your time to market. Familiar tools and native low code integration Functions are fully integrated into the Salesforce Developer Experience and are invoked directly from Apex, making them easy to add to Flows and the simplest way to add complex business logic to your apps. One CLI for development The Salesforce CLI is being enhanced with a new global executable, sf, that simplifies how you build, manage, and deploy across Salesforce.   Functions use case: running compute heavy and high-performance workloads In this blog post, we’re going to create a Java Function that processes a very large data set. Without Functions, it would be impossible to handle a data set this large in Apex, and many users would have had to implement complex workarounds to remain within their Apex limits. With Functions, you can overcome these kinds of computational limitations. In this example, the Function loads the complete six-thousand-record data set into memory. In the following example, we will use Functions to find a code school that is closest to a specific geographic point. It will also iterate over the data set to calculate the distance from a point of origin, sorting the results by distance, and then returning the ones that are closer to the provided location. This can be done in a few simple steps: Write a Function in an SFDX project Run and debug your Function locally to validate logic Deploy the Function to a Salesforce Org Integrate with low code: invoke the Function through Apex Done – you’ve leveraged the compute capabilities from declarative tools. Functions can be written in a Salesforce DX project by using the Salesforce CLI or Visual Studio Code editor with the Salesforce Extension Pack. To create a project with this new command structure using the Salesforce CLI, run: $ sfdx generate:project -n sfdx_functions_project The Visual Studio Code editor with the Salesforce Extension Pack will create a project with the necessary files to start developing for the Salesforce Platform. After creating the project, we can start writing our Functions, by using either Java or JavaScript. Let’s generate the processlargedata function in Java with the Salesforce CLI: $ sfdx generate:function -n processlargedata -l java Or using the Visual Studio Code SFDX: Create Function command: Generate a Function from Visual Studio Code This will generate a Java project under the functions folder with all the necessary files to write your Function and run tests locally. Let’s update the auto-generated Function with the use case we described above. The full source code for this project in the Functions Recipes Sample Application is available on Github.com. { school.setDistance( distance( latitudeSt, longitudeSt, school.getLatitude(), school.getLongitude())); return school; }) .sorted(Comparator.comparingDouble(School::getDistance)) .limit(length) .collect(Collectors.toList()); LOGGER.info("Function successfully filtered {} schools", schools.size()); return new FunctionOutput(schools); } // ... A Java Salesforce Function receives two parameters: an InvocationEvent that contains the input payload of the Function the Context, which has access to the authenticated Salesforce Org and the SDK. (Note: Node.js Functions contains a 3rd parameter Logger, which is used for logging operations). This ProcessLargeDataFunction receives a JSON payload with latitude, longitude, and length, and returns a list of the nearest schools to that starting point specified in the input payload. Now, let’s see how can we run this Function locally. Running your first Function A Salesforce Function can be executed locally by using the CLI, which is a useful way to develop and test your Function without deploying it to a Salesforce Org. Local execution can be also integrated with an authenticated Salesforce Org when doing the invocation. You can start this Function locally by running: $ sfdx run:function:start Or by using the Visual Studio Code SFDX: Start Function command: Start a Function from Visual Studio Code This will build and run the Function locally, and it will be ready to start receiving invocation requests. A Function running locally from Visual Studio Code Now that our Function is running locally, we will use a JSON payload to invoke the Function. Let’s create a payload.json in the function folder with the following information: { "latitude": "36.169090", "longitude": "-115.140579", "length": 5 } This payload information represents the point of origin and the number of results it will return. It will be received by the Function in the InvocationEvent object. You can invoke the Function with this input payload from the CLI by running: $ sfdx run:function --url=http://localhost:8080 --payload=@payload.json Or, you can do this from Visual Studio Code by opening the payload.json file, and clicking on the Invoke CodeLens action: Invoking a Function from Visual Studio Code with CodeLens You have seen how to generate, run, and invoke your first Salesforce Function using the Salesforce Developer Tools. Now it is time to connect to a Salesforce Organization, create a compute environment, and deploy the Function. Deploying your first Function We have been able to run our Function locally thanks to the Salesforce Developer Tools, but the real power of Salesforce Functions comes when they are running in our serverless compute environment. Let’s deploy our Function to a Salesforce Organization. To do that, we need to create a Compute Environment and connect it to an Org by running: $ sfdx env:create:compute -o connected_org_alias -a compute_env_alias Then, we need to deploy our Salesforce project and Functions. The upcoming sf CLI will allow you to deploy your project metadata along with the Function in a single command. But until then, we have to do that using sfdx in two steps: $ sfdx force:source:push $ sfdx project:deploy:functions -o connected_org_alias Now that our project is deployed, we can invoke the Function from Apex by using the new Function class: functions.Function fn = functions.Function.get('sfdx_functions_project.processlargedata'); functions.FunctionInvocation invocation = fn.invoke('{"latitude": "36.169090", "longitude": "-115.140579", "length": 5}'); String jsonResponse = invocation.getResponse(); System.debug('Got response' + jsonResponse); Triggering a Function with Apex from the Developer Console Integrating your Function with low-code tools Now that our Function can be invoked through Apex, we can integrate it with a Flow or Lightning Web Component. Let’s create an Apex class, FindCodeSchools.cls, that invokes the ProcessLargeData Function from a Flow. The full source code for this project in the Functions Recipes Sample Application repo is available on Github.com. input) { Input payload = input.get(0); // Get a Reference of the ProcessLargeData Function functions.Function fn = functions.Function.get( 'sfdx_functions_project.processlargedata' ); // Invoke the ProcessLargeData Function functions.FunctionInvocation invocation = fn.invoke( JSON.serialize(payload) ); String response = invocation.getResponse(); // Serialize the Response into an Object Output output = (Output) JSON.deserialize(response, Output.class); return output.schools; } // ... } With this Apex class with an @InvocableMethod, we will create a new Flow that triggers this method as an Apex action and use the output as we see fit. You can also trigger the Function from an LWC component by using the @AuraEnabled annotation. Invoke the FindSchools Apex Method from a Flow As you can see below, we seamlessly integrate the power of the compute capabilities of Salesforce Functions with the low-code simplicity of Flow. Flow integrated with a Salesforce Function Learn more We’re excited to see what you build using Salesforce Functions. Please nominate yourself for the Invite Beta. About the authors Julián Duque is a Lead Developer Advocate at Salesforce. Connect with him on Twitter @julian_duque. Khushboo Goel is a Sr. Product Marketing Manager at Salesforce. Connect with her on Twitter @kgoel31.

[tak4hir0]

This is an update from a 2017 Post.   Lightning Web Components run on the client-side, in a single page, where they are created and destroyed as needed, alongside other components that work on the same data. We will discuss how these characteristics impact performance, and review a list of best practices to optimize the performance of your Lightning Components. Our original Performance Best Practices blog post from 2017 focused on Aura components. A lot can change in three years, and in this updated post we’ll be focusing on Lightning Web Components. If you are just starting out with Lightning Web Components, consider completing the Build Lightning Web Components Trail, watching some of the topic specific videos in the Lightning Web Components Video Gallery and checking out some of our sample apps in the Sample Gallery before diving deeper.   The list of performance best practices discussed in this document includes: Lightning Web Components vs Aura components Data retrieval Data caching Component instantiation Conditional rendering Lists Events Third-party JavaScript libraries and custom style sheets Base Lightning components Image optimization Component lifecycle rendering and reflow Developer settings and tools Lightning Web Components vs Aura components Lightning Web Components (LWC) align closely with modern web standards, which makes them more efficient for developers to build with and for browsers to render. The LWC bundle has a simpler structure than that of Aura components, and the development of LWC feels much more like other modern JavaScript frameworks. This can increase developer productivity. And not only is it easier for developers to build with LWC, but they can also increase the performance of applications when compared to Aura components. In one case study, Aura components migrated to LWC showed anywhere between a 20-60% decrease in Experience Page Time (EPT). So when it comes to making a choice between LWC and Aura, LWC is usually the recommended option. While there are still some cases where Aura components are required, we’re working hard to advance the LWC framework so that this will no longer be the case. More information: Read Case Study: DreamHouse Gains Speed by Switching to LWC. Take the Trailhead module Lightning Web Components for Aura Developers. Review the Migrate Aura Components to Lightning Web Components developer guide. Data retrieval A component with no data is not a very useful component. With Lightning Web Components, you have various options available to you when retrieving data from the server. To optimize all of your server round-trips, keep these things in mind: Use the Lightning Data Service or cache data when ever possible (see Data caching). Before making a call to the server, make sure there’s no other option to obtain the data. When appropriate, consider passing data between components using attributes, events, or methods rather than retrieving the same data in different components. If multiple components on a given page retrieve the same data, consider creating a service component that has no UI elements and can query data once so that it can pass data on to other components. When making a call to the server, limit the fields and rows of the result set: Only SELECT the fields you need. Set a LIMIT on the query, don’t return huge numbers of rows at once. Implement pagination when queries may have large results sets. Lazy load occasionally accessed data. Don’t preload data that the user may never need. For example, put least accessed components in a secondary tab that the user may not click. Don’t make a call to the server to filter or sort data you already have at the client-side. JavaScript Arrays have built in functions to do things like sort, filter and find values. As opposed to using Apex, leverage the Lightning Data Service and UI API to not only retrieve records, but also retrieve list views, metadata and picklist values. When using the getRecord wire service (part of the UI API) in LWC, avoid calling the full layout when you only need a few fields. Potentially hundreds of fields: @wire(getRecord, { recordId: '$recordId', layoutTypes: ['Full'] }) One field: @wire(getRecord, { recordId: '$recordId', fields: ‘Contact.Name’ }) More information: Read the Modularizing Code in Lightning Components blog post to learn more about service components. Review the pagination section from the Designing Lightning Pages for Scale blog post. Application composition is a powerful way to build apps by assembling self-contained components. However, without proper planning, the autonomous nature of the components you assemble can have an adverse impact on performance. For example, if all the components you build make their own isolated calls to the server to retrieve data they need, you’ll probably end up with lots of redundant server calls. This can dramatically impact performance. Client-side data caching can solve this problem by sharing data among components. This can significantly reduce the number of server round-trips, and improve the performance of your Lightning Web Components. The Lightning Component framework has two built-in mechanisms for client-side caching. These are Lightning Data Service and cacheable Apex methods. If neither of these work for your purposes, you can also implement a custom caching solution. Lightning Data Service Lightning Data Service provides a managed record approach: you’re not responsible for writing data access logic, so no Apex here. It also handles security for you by checking the accessibility of records and fields. The framework is responsible for managing records; this includes fetching them from the server when requested the first time, storing them in a highly efficient client cache, sharing them between all components that request them, and sending changes to the server and invalidated cache entries when dependent Salesforce data changes. Lightning Data Service can also handle progressive loading by allowing developers to specify which fields to load. When using the getRecord wire adapter, be sure to only request the needed data since it does allow developers to return entire page layouts (which may include unneeded data). This is also true for the getRecordUi wire adapter which can return full layout information, metadata, and data for a record or records. When leveraging either of these Lightning Data Service wire adapters, be sure to only request the data you need and nothing more. If another component subsequently requires additional fields, these fields are loaded transparently and added to the record in the cache. Unlike storable actions that can cache any type of response returned by an Apex method, Lightning Data Service caches a discrete Salesforce sObject. The Lightning Data Service also improves user interface consistency: when a component updates a record, all the other components using that record are notified and in most cases refreshed automatically. More information: Review the Lightning Data Service section of the Lightning Web Components Dev Guide. Review the Get Record Data and Understand the Wire Service section of the Lightning Web Components Dev Guide to learn more about the wire service. Watch the Wire an Apex Method to a Property video in our LWC Video Gallery. Review the getRecord and getRecordUi wire adaptors. Check out the following components in the DreamHouseApp.io (repo) to see the Lightning Data Service in action: mapCard, propertySummary, mortgageCalculator. Cacheable Apex Methods A Cacheable Apex Method is a server action whose response is stored in the client cache so that subsequent requests for the same server method with the same set of arguments can be accessed from that cache instead of the server. Cacheable Apex Methods enable you to access data using a traditional Remote Procedure Call (RPC) approach: You implement some logic in Apex that you expose as a remotely invocable method. Cacheable Apex Methods enable you to cache virtually anything, whatever the server method call returns. This could be a record or collection of records, a composite object, a custom data structure, data returned by a callout to a third-party service, and so on. The general guideline is to cache (mark as storable) any action that is idempotent and non-mutating. Creating a Cacheable Apex Method is easy. Simply annotate your Apex methods with @AuraEnabled(cacheable=true) @AuraEnabled(cacheable=true) public static someObject getIceCream(string flavor) { // your code here } More information: Review the Call Apex Methods section of the Lightning Web Components Dev Guide. See the Enable Client-Side Caching in the Call Apex Methods section of the Lightning Web Components Dev Guide. Check out the DreamHouse sample application for examples of storable actions in: similarProperties, propertyCarousel, propertyTileList. Component instantiation Showing every available piece of data and every available tool on the screen just in case the user may need it is generally not considered a good UX practice. It can also significantly impact the performance of your application. Lightning Components added to a page layout are instantiated when the page is loaded, contributing to the overall loading time of the page. Today’s interactive design guidelines favor progressive disclosure. “Progressive disclosure is an interaction design technique often used in human computer interaction to help maintain the focus of a user’s attention by reducing clutter, confusion, and cognitive workload. This improves usability by presenting only the minimum data required for the task at hand” (Wikipedia). Put another way, “progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone” (Jakob Nielsen). In Lightning Experience, it’s easy to implement progressive disclosure and defer data or features that aren’t essential to the task at hand. There are several approaches to defer component creation, let’s take a look at two of them in detail: Lazy instantiation (sometimes referred to as lazy loading) and conditional rendering. Lazy instantiation in Lightning Experience Lightning App Builders can implement progressive disclosure declaratively by placing components within specific areas in the Lightning Experience where they are lazily instantiated. These areas include: Standard tabs and accordion components allow information to be hidden and only loaded when the user selects that tab or accordion. Lightning Component Actions or Quick Actions allow components to be loaded only when the user clicks on a button. Utility Bar can be added to any app and also includes buttons that can load components when the user clicks on them. Lazy instantiation in your own components Leverage the set of tab components like and that support lazy instantiation by default. Leverage the set of accordion compoments like and that support lazy instantiation by default. Note: TabSet and the App Builder tabs component are lazy-loaded however the tabs within the Lightning Console are loaded as workspaces and sub-tabs are not lazy-loaded. Conditional rendering There are three methods to enable the conditional rendering of your Lightning Web Components: Dynamic component visibility Using if:true|false Toggling visibility using CSS The first method is declarative and built directly into App Builder. Dynamic component visibility can control when a component appears on a Lightning page by adding filter conditions and logic to its properties in the Lightning App Builder. For example, you can construct a filter that causes a rich text component on an opportunity page to display when the opportunity’s amount is greater than or equal to $1 million. The second method allows developers to conditionally render DOM elements using if:true|false to lazily instantiate parts of the UI: In this case, if “something” = true, the first tag and all its children are created, while the second tag and all its children, are not rendered. This would swap when the “something” expression changes to false. In this situation, the first tag would be destroyed and the second would be rendered. The third method leverages CSS styles to toggle visibility and can be implemented using the following template and JavaScript. Template: JavaScript: get className(){ return isError ? 'slds-show': 'slds-hide'; } The component and all of its children are created and rendered up front, but are hidden from the user until the JavaScript is run. Keep in mind that this method does create the component upfront so there’s no performance gain on page load like there is with methods one and two. However, when the JavaScript is run the component will show immediately to the user without the need to initialize or render. The general guidance here is to use these methods in the order presented. The first option should be the declarative option discussed in method one, though this is only available on components configured for Lightning App Builder. Method two’s if:true|false approach should be your second option and works with all components. Both methods help your pages load faster initially by deferring the creation and rendering of the component or enclosed element tree until the condition is fulfilled. The third method may be useful when developers want to preload a component and then show it in the UI when the condition is fulfilled. More information: Read more about Dynamic Lightning Pages. Review the Render DOM Elements Conditionally section of the developer guide. In the DreamHouse sample application see the propertyCarousel component which uses if:true|false to component render different elements based on if the property has images or not. Lists Lists should be created using either for:each or iterator. The difference between these is that iterator has first and last properties that let you apply special behaviors to the first and last items in an array. When creating custom list components, don’t support the creation of an infinite number of list items. This can severely hamper performance, especially in large orgs with lots of records. Either provide a pagination mechanism, or virtualize the list (reuse and rehydrate a limited number of list item components). More information: Review the Render lists section of the Lightning Web Components Dev Guide to learn more about for:each or iterator. In the DreamHouse sample application check out propertyTileList component that uses for:each in combination with the paginator component to allow for interacting with long lists. Events Leveraging events is a great way to communicate between components and even allows developers to listen for events within the DOM as Lightning Web Components dispatch standard DOM events. Components can also create and dispatch custom events. Use events to communicate up the component containment hierarchy. Event listeners can be attached declaratively or programmatically using addEventListener(). Keep the following in mind when leveraging events and event handlers: Minimize the number of event handlers to only those absolutely required. Each handler requires overhead and if too many are created it can slow the performance of your app. Be sure to understand event propagation of parent-child components using bubbles and composed. Typically you should use events configured with bubbles: false and composed: false because they’re the least disruptive. These events don’t bubble up through the DOM and don’t cross the shadow boundary. To communicate between sibling components within a single Lightning page or across multiple pages, you can use Lightning Message Service. It has the advantage of working across Visualforce, Aura, LWC, utility bar components and across page tabs in a console app. If you add a listener to something that is not part of the component lifecycle (like the window object, the document object, and so on), you’re responsible for removing the listener yourself. To remove the event listeners use removeEventListener() in the disconnectedCallback lifecycle hook. Failing to do so can result in memory leaks, which will progressively degrade the performance of the entire Lightning app, until the user closes or refreshes their browser tab. When working with lists, letting events bubble, and registering a single event listener on a parent element instead of a separate event listener on every list item can significantly reduce the number of event listeners in your application. This can have a positive impact on performance. More information: Review the Communicate with Events and Configure Event Propagation sections of the Lightning Web Components Dev Guide to learn more. Review Communicate Across the DOM with Lightning Message Service (Beta) and this blog post to learn more about the new Lightning Message Service. Watch the Parent-Child Components video in our LWC Video Gallery to see how to send data from a child component to a parent component. In the DreamHouse sample application check out propertyTileList and paginator for an example of using the Lightning Message service to communicate between components. Third-party JavaScript libraries and Style Sheets Whenever possible, remove dependencies on unneeded libraries. Furthermore, before you decide to use a third-party library in a Lightning component, you should reevaluate if you really need that library. DOM manipulation libraries (like jQuery) and UI libraries (like Bootstrap or jQuery UI) in particular may no longer be needed when working with the Lightning Component Framework. Using third party or your own Custom Style Sheets should only be used if Salesforce Lightning Design System (SLDS) doesn’t meet your needs. DOM manipulation libraries JavaScript has come a long way in recent years. Many DOM manipulation utilities we couldn’t live without like jQuery are now standard in the language. Modern frameworks like the Lightning Component Framework also provide abstractions that make jQuery less relevant. UI libraries You may want to avoid the use of UI libraries like Bootstrap and jQuery UI. Although these libraries provide useful components, they have their own UI identity that can clash with the Lightning Experience identity. The base Lightning components and the SLDS offer similar capabilities while providing a consistent user experience. MVC (Model-View-Controller) frameworks At a high level, libraries like React and AngularJS have the same focus as the Lightning Component Framework: They provide code organization and utilities to create components. Using another MVC framework together with the Lightning Component Framework inside a component isn’t recommended. You can, however, use a Lightning component as a container to host components built with other frameworks (like React and AngularJS) inside the Lightning Experience. However, that is outside the scope of this document. See the LockerService and Lightning Container Component: Securely Using Third-Party Libraries in Lightning Components blog post for details. Custom style sheets Using third party CSS style sheets or creating our own styles can cause performance issues and may make your UI look inconsistent to end users. Developers should become familiar with the Salesforce Lightning Design System (SLDS) that was developed by Salesforce to create beautiful and rich UI experiences for end users. It’s also much more than just styles and CSS, it includes design guidelines and principals used by our own engineers and component blueprints that cover common developer needs like Breadcrumbs, Modals, Alerts and much more. It has an incredible list of Design Tokens that store visual design attributes for color, fonts, spacing, sizing and even touch.   Levering the SLDS can also save developers time when building components since it’s built right into Lightning and doesn’t require developers to create and maintain their own CSS. Use Minified versions of libraries and style sheets If you absolutely need to use a third-party library, make sure you use minified versions of the library and style sheet to increase the performance of your app. More information: Review the Salesforce Lightning Design System (SLDS) to learn how to best use its styling in custom components. See the libsChartjs component in the LWC Recipes app for an example of Chart.js in Lightning components. Base Lightning components Before you start building your own custom Lightning components you should familiarize yourself with the library of base components offered. These include listView, recordForm, and many more. Leveraging these base components can significantly speed up your development time. For example if you want a big red button presented to a user, simply use the lightning-button: To produce this: Additional benefits include: Styles: Base Lightning components are styled with the native Lightning look and feel. Performance: Base Lightning components are already loaded at the client-side and don’t require additional download or processing. Our performance optimization efforts are also focused on components in the lightning namespace. Responsiveness: By default base Lightning components are responsive in their design. Innovation: The Lightning namespace is where components are being actively developed. This is where you can expect to see new and improved components moving forward. Accessibility: Base Lightning components are built for accessibility. Client-side validation: Base Lightning components include client-side validation when applicable. More information: Review the Component Reference tab of the Lightning Web Components Dev Guide to learn more about the many components offered. Image optimization Whenever possible, use the (sprite-based) SLDS icons (using and ) instead of custom icons. Salesforce has prebuilt hundreds of icons for you to choose from, so before spending time creating your own custom icons, reuse the ones that SLDS offers. To give you a quick sample here are a few of our favorites: When using other images, be sure to lock image dimensions to avoid reflows and serve the image in those dimensions when possible. For example, don’t load a high-resolution image to display a thumbnail. More information: Review the icons section of the SLDS guide to see all available icons. Component lifecycle rendering and reflow Lightning Web Components have a lifecycle managed by the framework. The framework creates components, inserts them into the DOM, renders them, and removes them from the DOM. Read the rendering lifecycle to understand what happens during this lifecycle and which methods fire at what time. Minimize the number of times your component is being re-rendered. In some cases, it may be helpful to lock DOM regions to specific dimensions to avoid browser reflows of surrounding areas. Development settings and tools This section covers settings and tools that can aid a developer when building high performance applications. The best practices here are focused on helping developers work faster and more efficiently when building in Lightning. Debug mode & component caching Optimizations for a production environment and a development environment are different. Here is a typical question asked in the developer forums: “When I make changes in a component, I need to refresh the page a few times in the browser for my changes to take effect. Why do I have to do that, and how can I avoid it?” The reason is that to optimize performance in a production environment, component definitions are cached at the client-side. As a result, when you make a change to a component, and then reload the page hosting the component, you can still get the previous version of the component served from the client cache. You can usually get the new version of the component by refreshing the page a couple of times, but that isn’t a suitable developer experience. The solution is to enable debug mode and disable client-side caching during development. Debug mode also makes it easier to debug JavaScript code from Lightning components as framework JavaScript code isn’t minified and is easier to read. Recommended settings: A Development Production Debug mode On Off Component caching Off On To enable debug mode: Debug Mode. Select the users you want to enable debug mode for. To disable component caching: Caching, and uncheck Enable secure and persistent browser caching to improve performance IMPORTANT NOTE: Client-side caching is an org-wide setting. Disabling client-side caching and enabling debugging has a significant impact on performance. Only do this in your development environment, not in a production environment. Similarly, if you run tests to assess the performance of your environment, remember to turn these settings back to the production values before running those tests. Performance profiling & debugging tools If you face a problem in a component, make sure you understand what the real problem is before trying to solve it. Don’t make assumptions. Use profiling tools to identify the bugs and performance bottlenecks. You can leverage Chrome’s built in DevTools to help in a number of areas: You can use them to step through JavaScript as it runs to help debug issues. Examine network traffic using the Network panel to watch when the server method is called and when it’s not, for example when working with a storable action. Profile component performance with the Performance panel to watch which actions or requests are taking the most time. Note that is helpful to run Chrome in Guest or Incognito mode when leveraging the developer tools to reduce any noice created by Chrome Extensions Use the Salesforce Lightning Inspector Chrome Extension which is similar to the Performance panel. Analyze with the Salesforce Community Page Optimizer for working with communities. More Information: Review the Debug Lightning Web Components section of the Developer Guide. Watch the Debug LWC using browser-based tools video. Learn how to Enable debug mode for Lightning components. Learn more about Chrome Developer Tools. Summary The performance of an application is impacted by many different factors. The Lightning Web Components performance optimization techniques described in this article are general guidelines that should help you build faster and more responsive applications. Try them out in your application, and let us know what your favorite performance optimization techniques are. If you’re curious about how to assemble blazing fast Lightning pages at scale, check out the Designing Lightning Pages for Scale blog post.

[tak4hir0]

Salesforce is bringing you a completely reimagined experience. TrailheaDX ’20 will be a one-of-a-kind virtual experience that connects makers, builders, doers, and dreamers looking to improve their Salesforce skill set. This year’s event includes exciting new demos, customer testimonials, content episodes featuring the latest technology, Q&A with product experts, awesome networking opportunities, special announcements from Salesforce executives, and an unforgettable broadcast featuring a luminary speaker. TrailheaDX. It’s new, it’s virtual, it’s live. We’ll be broadcasting live, interactive, expert-led content across four broadcast channels on June 25 starting at 8:45 a.m. PT. Those channels include Admin, Architect, Developer, and Entrepreneur. You can also check out the virtual expo to explore Salesforce features, what’s new with the platform, our cloud products, how we support sustainability, and of course, the latest on Trailhead and certifications. Use our live Q&A system to get information and answers straight from the people who helped create these new features and products. Whether you’re planning to join in live or host a virtual watch party with friends, you’ll find a lot in store for Salesforce Developers at TrailheaDX ’20. Let’s take a look at what you can look forward to. Main Event Trailblazing Together, Innovating Through Change Start your day with the keynote, streaming across all channels. Join host Sarah Franklin, EVP and GM Platform, Trailhead, & AppExchange, and special guests as we look at how Trailblazers across the ecosystem are rapidly building solutions for their businesses in our new normal. We’ll show you how the Customer 360 Platform is your key to success with it now being more important than ever to innovate fast, scale with confidence, and empower everyone to build on the platform. Don’t miss this keynote packed with special guests, Trailblazers, and product announcements. Follow along with the Keynote Watch at Home Guide available here on June 25, before the broadcast begins. Developer Channel While tuned into the developer channel, you’ll learn about the low-code and pro-code resources and tools you can use to develop industry-leading enterprise apps, get the latest guidance on how to innovate through change, and see what’s possible with the Customer 360 Platform, straight from Salesforce product managers and engineers.   Build Integrated and Scalable Apps using Salesforce Functions Speakers: Asavari Tayal, Product Management Director; Joe Kutner, Software Engineering Architect Salesforce Functions is a new addition to the platform that gives users the ability to extend their existing solutions by building custom code applications using serverless Functions. Functions are event-driven, elastically scalable, and can be written in a language of your choice such as Node.js, Java or Apex. They provide seamless access to data in your org and can be integrated with other low-code and pro-code services. Join us to learn more about the exciting new capabilities of Functions.   Improving Quality of Life: Apex Updates to Ship Better Code, Faster Speakers: Kevin Poorman, Developer Evangelist; Chris Peterson, Product Management Director Learn about a new language operator coming in Winter ’21, as well at the latest on what’s possible when leveraging the transaction finalizers pilot.   Ask the Experts: Developer Experience on the Customer 360 Platform Speakers: Heather Dykstra, Developer Program Manager; Claire Bianchi, Product Management Director; Michael Friis, Product Management Senior Director; Kevin Hill, Product Management Senior Director; Alba Rivas, Developer Evangelist We’ve been hard at work here at Salesforce to unify your developer experience, laser focused on enhancing what works today and expanding our tools to be more inclusive of the things you need to be your most productive. Join us to ask about what is happening in development globally, as well as your questions about the newest enhancements and announcements around the Salesforce Developer Experience. Do you have an idea or topic you’d like to ask for one of the Ask the Experts sessions? Head to http://sforce.co/TDX20ASK to submit your questions!   How to Harness Einstein Vision and Language in Any App Speakers: Sarin Devraj, Associate Product Marketing Manager; Einstein, Zineb Laraki, Senior Product Manager; Jimmy Au, Senior Product Manager, Einstein What if you could predict everything your customer felt, expressed, and needed from a block of text or an image? Words and images are powerful snippets of data. With Einstein Vision & Language, you can iterate quickly to build the most accurate models without the complexity of managing and maintaining their infrastructure. Join us to learn how to leverage these APIs to make your applications smarter across industry use-cases to automate and streamline workflows. This session will cover specific applications around our Einstein OCR (optical character recognition), Einstein Image Classification, Einstein Intent, and Einstein Sentiment.   Do More With Less Code Using Salesforce APIs Speakers: Kris Harrison, Product Management Director Ready for a surfing safari through the wild world of Salesforce APIs? APIs are critical to just about any app or business process, but there’s a lot more to what Salesforce provides than REST or SOAP. Join us for the API primer you’ve dreamed of, as we take you beyond the basics into the deep waters of APIs. We’ll show you how we’re helping you do more with less code using newer APIs like Composite Graph and the Composite API, and talk a bit about how we’re helping you innovate faster with less effort through changes to API limits and brand new, never before seen features for SOQL. You’ll see live demos, API roadmaps, and walk away ready to do less and benefit more!   Build and Run Trusted Web Apps Anywhere with Lightning Web Stack Speakers: Kevin Hill, Product Management Senior Director In today’s environment, developers want to use their favorite tools to innovate fast, however, speed often comes at the cost of security and governance required for enterprise-grade solutions. This is where Lightning Web Stack comes in, a collection of open, web standards-based modules and services designed to build and run enterprise apps anywhere. Join this episode to learn how you can build amazing experiences fast without sacrificing trust. We will start with an LWC component inside Salesforce and show how you can deploy the same component onto a Heroku app.   Salesforce Heroku Extends Your CRM to Deliver Seamless Customer Experiences Speakers: Julián Duque, Lead Developer Advocate Join us to hear about how Sales and Service teams work in sync to deliver consistent and personalized experiences to their customers. With a seamless connection to CRM data, customers can interact bi-directionally with their data through highly engaging apps. The Customer 360 Platform provides the flexibility for developers to choose their choice of development language and easily collaborate with remote teams to ship features faster.   Unlock Developer Productivity with Modern, Open Tooling Speakers: Nathan Totten, Senior Director of Product Management; Stephanie Maddox, Senior Product Manager One of the most important things you can do as someone who builds on Salesforce is to fully understand the tools at your disposal. But with so many different options to choose from, we can understand if the task feels daunting. In this session, we’re going to take you on a fast, focused, and demo-centric tour of all of the latest innovations in the world of developer tools. You’ll see how we’re empowering you to work the way you want, from where you want, with our powerful extensions for VS Code, the Salesforce CLI, Local Development, and more. We’ll also give you a first look at new capabilities that will empower you to be even more productive than ever before, and talk about our open roadmap for the tools you already know and love. You’ll walk away ready to build, debug, and deploy new apps faster, more productively, and on your terms.   Blockchain for Developers: Building an Intercompany Transaction Network Speakers: Doc Tran, VP Finance; Madhu Seela, Senior Architect; Sudeep Verma, Senior Developer Pull back the curtains on how Salesforce Finance used blockchain to build an inter-company transaction network to strengthen controls and reduce reconciliation efforts on all transactions made across company entities worldwide. Through the lens of Salesforce Finance, you will learn how to use Salesforce Blockchain to automate and execute processes, reduce the burden of excess infrastructure, and harness the full power of the Customer 360 Platform.   Salesforce Analytics Developer Experience Speakers: Skip Sauls, Senior Director of Product Management; Geraldine Zanolli, Tableau Developer Advocate Einstein Analytics and Tableau have a set of APIs and Developer Tools which enable developers to extend the capabilities of what you can do with your data. In this session, we will show you how to use EA and Tableau APIs to unleash the power of these two tools combined. Admin, Architect, and Ecosystem channels Don’t forget to check out the content on our other channels as well. The Architect channel is all about what you need to know now to guide your teams and customers through change. Tune into the Admin channel to learn about the latest innovations on the platform in automation, app building, mobile, security, analytics and more, straight from the product managers who built them. Finally, on the Community & Ecosystem channel, learn how to drive your company’s digital transformation, develop faster than ever with the Customer 360 Platform, leverage best-in-class apps and solutions from AppExchange, discover new marketable skills, and earn resume-worthy Salesforce credentials with Trailhead. True to the Core wrap session Join Salesforce executives Bret Taylor, President & Chief Operating Officer, Parker Harris, Co-founder and CTO, Sarah Franklin, EVP & GM Platform, Trailhead, & AppExchange, and Salesforce Product Managers for the True to the Core session. We will round out TrailheaDX with this opportunity to virtually engage with our execs and get your questions answered. Do you have an idea or topic you’d like addressed during the live True to the Core session? Head to http://sforce.co/TDX20ASK to submit your questions! What you can do now Register for TrailheaDX ’20 Add the Developer sessions to your agenda Head to http://sforce.co/TDX20ASK to submit your questions for Ask the Experts and True to the Core!

[tak4hir0]

Another Summer, another Salesforce release. While this release was delayed and its mascot icon changed due to the COVID-19 pandemic, Summer ‘20 is finally here. A lot of great new features coming to an org near you and a ton of cool stuff to stay excited about in the future as well! While these features are not GA yet, this was my top most wanted feature in my 2020 Outlook and I’m super excited about it! Dynamic Forms (Non-GA Preview) Your users can now customize their Lightning App Builder pages down to the Layout Section or even Field level based on certain conditions. No more having to create tons of layouts just to add one field, or having to have a bunch of extra fields crowd the screen if they’re not needed at a certain point. I’m super excited to try this out and the PM from Salesforce, Vin Addala, is soliciting feedback and has some resources for you to get started too. Dynamic Forms in Summer ’20! Prepare by: 1) Join Community – https://t.co/lSwxj9F0eq 2) Release notes – https://t.co/5wsVsH5bYq 3) Podcast – https://t.co/m1smynVejq 4) try in pre-release org-https://t.co/OoADnmqpmG 5) complete https://t.co/AwdZHvPlVk@salesforceadmns #LowCodeLove — Vin Addala (@vinaddala) May 8, 2020 Dynamic Actions to Highlight Panel (Beta) In addition to Dynamic Forms, I’m also pretty excited that a new Beta feature allows us to customize the Actions that appear in the Highlights Panel. Once again, we can cut down on page layouts by providing conditions on actions showing up. I love the idea of decluttering my layouts and only showing the actions when they’re needed. Flows Once again, following the Spring ‘20 Release, Flow takes a MAJOR step forward in this release. Following the “Before Save Flows” functionality we got in Spring, we now have the next logical step: “After Save Flows” After Save Flows I think the line that stands out the most for me is “You can replace most of your workflows and record-change processes that you created in Process Builder.” If you’re already familiar with code, “A flow that performs after-save actions is similar to an after trigger”. If you’re not already familiar with code, consider yourself that much closer to being an Apex Developer! With After-Save Flows, you can fire off a flow automatically after a record is saved. The implication of this means that you’ll have access to the record’s ID as well as the LastModified information. As Flows continue to get stronger, if you aren’t already familiar with how to build flows, it’s time to start. I think it’s pretty clear that the new automation in Salesforce on the declarative side is coming to Flow while Process Builder and Workflow appear to be falling out of style. Count this as another win for “clicks before code” as well, as there is now more we can do without needing an Apex Trigger. Debug Flows Faster and Track Flow Resource Usage in Debug Logs One of the reasons I’ve preferred code to Flows in the past is because, in my opinion, existing flows are hard to troubleshoot, or debug, and are also hard to start building. The troubleshooting/debug piece is considerably addressed in this release. Now you can configure Debug options including “rollback mode”, which will undo, or “rollback”, all records changes done as a result of the flow if something goes wrong. Flows will also show you more information in the Debug Logs that you can run for yourself or another user about how many Salesforce resources they’re using and how close they are about hitting limits. This should help determine why Flows are hitting errors as well and resolve them quicker. Flow Builder Guidance Salesforce addressed my other concern with Flow in this release as well, by showing Tips to help you build your flows while you’re building them! Access Apex-Defined Variables in Flows Yet another Apex/code feature being brought to flow, custom variable types. For those unaware with writing code, you’re not necessarily limited to just having a variable of type Number, Text, Account, etc, but can create your own types or structures with properties that you define. For example, maybe you want a single variable that has multiple properties. I could have a variable in Apex defined as follows: Type: Bank Account Bank Account.Customer Name (Text) Bank Account.Amount (Decimal) Bank Account.Account Number (Number) Bank Account.Bank Name (Text) I can now reference such an Apex-Defined variable in my flow! Development Share CSS Across LWC I love the ability of Lightning Web Components to import almost anything. I also hate having to duplicate things, including styling. Now you can develop a CSS component and import it into your other components to create a consistent look and feel across your components. Import User Permissions LWC Yet another thing to import into LWC! Check whether users have specific permissions specified by importing them. Track Source Changes in Sandboxes (Beta) I love using Scratch Orgs but sometimes it just isn’t feasible for a specific use case or bug fix. One of the difficult things about developing with SFDX with sandboxes is having to manually track your changes. I’m excited about this new Beta feature to start letting SFDX track your sandbox changes like it’s a scratch org. LWC Test Create Commands CLI While Lightning Components don’t (yet) require tests, it’s always best practice to be testing your code. That’s why I’m glad to see these new SFDX commands to focus on testing your components, including creating some boilerplate code to get you started. Other Customizations Outside of Development, Flow, and the Dynamic items, there are a few other items that I’m excited about in this release. Split List View I loved the Kanban view when it first launched and I’m a big fan of this new List View type as well. Far too often I find myself having to open a bunch of new tabs from a list view to make modifications or look at details to a bunch of records. Now I can choose the Split List View to view them all from one tab and keep my browser RAM to a minimum. Minimum User Access Profile With Salesforce security being shifted to Permission Sets, I think this is a long time coming; an empty Profile where ALL security for a user can be managed by Permission Sets. In App Guidance Builder I haven’t used this feature yet, but I’m glad to see that Salesforce is focusing on helping with User Adoption by providing tools to help build in-app guidance for end users. Related Record Component This is another nice way Salesforce is extending the capabilities of the Lightning Experience. Now with the “Related Record” component for the Lightning App Builder, you can show and edit fields on a record 2 levels up. My friend Jagannathan walked through a good example on Slalom’s Medium blog.  Reasons to get Excited Lastly, I’m always interested to see what Salesforce is working on that I’ll be able to start using in a few releases. Here are a few of the Beta and Pilot features that I’m looking forward to becoming Generally Available.  Release Updates (Beta) This appears to be a complete overhaul of the Critical Updates functionality and based on the initial release notes, I’m a fan. I think it’ll help provide context and better understanding for the impacts of the critical updates that need to be implemented. LWC Based Community Template (Pilot) I recently started supporting a Visualforce + Tabs Community for Mobile and it leaves a lot to be desired. I was surprised that we were still so reliant on Visualforce to get our customized Community working. I think this will be the start of something great that will vastly improve the customized Communities experience. Einstein Natural Language Search (Beta) This requires a separate Permission Set license, but like many Einstein features, this one looks pretty cool. Use natural language to search for records and Salesforce will find them for you. Tremendous possibilities! Let me know if you found anything else I missed. Hope everyone is staying safe and healthy and hope to be able to connect with you in person someday soon. Until then, make sure to take advantage of all the virtual events happening across the globe that you can now attend from your own home. I’m “speaking” in New Delhi, India later this week and hope to see you there!

[tak4hir0]

wire Service LWC Lightning Web Components(LWC) @wire Service LWC Lightning web components(LWC) use a reactive wire service, which is built on Lightning Data Service. Components use @wire in their JavaScript class to read data from one of the wire adapters in the lightning/ui*Apimodules and also to call the apex controller server-side methods using wire services. The wire service provisions an immutable stream of data to the component. Each value in the stream is a newer version of the value that precedes it. We call the wire service reactive in part because it supports reactive variables, which are prefixed with $. If a reactive variable changes, the wire service provisions new data. We say “provisions” instead of “requests” or “fetches” because if the data exists in the client cache, a network request may not be involved. The wire service delegates control flow to the Lightning Web Components engine. Delegating control is great for read operations, but it isn’t great for create, update, and delete operations. As a developer, you want complete control over operations that change data. That’s why you perform create, update, and delete operations with a JavaScript API instead of with the wire service. Wire Service Syntax Import a wire adapter using named import syntax. import { wire} from 'lwc'; Decorate a property or function with @wire and specify the wire adapter. @wire(adapterId, adapterConfig) propertyOrFunction; Here is full code syntax and its detail for using wire import { wire} from 'lwc'; @wire(adapterId, adapterConfig) propertyOrFunction; adapterId (Identifier)—The identifier of the wire adapter. adapterModule (String)—The identifier of the module that contains the wire adapter function, in the format namespace/moduleName. Look at the format! To import a module in JavaScript, use lightning/ui*Api instead of lightning-ui-*-api. adapterConfig (Object)—A configuration object specific to the wire adapter. Configuration object property values can be either strings or references to objects and fields imported from @salesforce/schema. Properties in the adapterConfig object can’t be undefined. If a property is undefined, the wire service doesn’t provision data. Don’t update a wire adapter configuration object property in renderedCallback() as it can result in an infinite loop. propertyOrFunction—A private property or function that receives the stream of data from the wire service. If a property is decorated with @wire, the results are returned to the property’s data property or error property. If a function is decorated with @wire, the results are returned in an object with a data property and an error property.   Import References to Salesforce Objects and Fields When you use a wire adapter in a lightning/ui*Api module, we strongly recommend importing references to objects and fields. Salesforce verifies that the objects and fields exist, prevents objects and fields from being deleted, and cascades any renamed objects and fields into your component’s source code. It also ensures that dependent objects and fields are included in change sets and packages. Importing references to objects and fields ensures that your code works, even when object and field names change. If a component isn’t aware of which object it’s using, use strings instead of imported references. Use getObjectInfo to return the object’s fields. All wire adapters in the lightning/ui*Api modules respect object CRUD rules, field-level security, and sharing. If a user doesn’t have access to a field, it isn’t included in the response. To import a reference to an object, use this syntax. import objectName from '@salesforce/schema/object'; import objectName from '@salesforce/schema/namespace__object'; import POSITION_OBJECT from '@salesforce/schema/Position__c'; import ACCOUNT_OBJECT from '@salesforce/schema/Account';   To import a reference to a field, use this syntax. import FIELD_NAME from '@salesforce/schema/object.field'; import POSITION_LEVEL_FIELD from '@salesforce/schema/Position__c.Level__c'; import ACCOUNT_NAME_FIELD from '@salesforce/schema/Account.Name';   To import a reference to a field via a relationship, use this syntax. You can use relationship fields to traverse to parent objects and fields. You can specify up to three relationship fields, which results in four objects and the field being referenced. For example, Opportunity.Account.CreatedBy.LastModifiedById returns 4 levels of spanning fields. import SPANNING_FIELD_NAME from '@salesforce/schema/object.relationship.field'; import POSITION_HIRINGMANAGER_NAME_FIELD__c from '@salesforce/schema/Position__c.HiringManager__r.Name__c'; import ACCOUNT_OWNER_NAME_FIELD from '@salesforce/schema/Account.Owner.Name';   This code imports the Account.Name field and uses it in a wire adapter’s configuration object. import { LightningElement, api, wire } from 'lwc'; import { getRecord } from 'lightning/uiRecordApi'; import ACCOUNT_NAME_FIELD from '@salesforce/schema/Account.Name'; export default class Record extends LightningElement { @api recordId; @wire(getRecord, { recordId: '$recordId', fields: [ACCOUNT_NAME_FIELD] }) record; } This code is almost identical, but it uses a string to identify the Account.Name field. This code doesn’t get the benefits that you get from importing a reference to the field. import { LightningElement, api, wire } from 'lwc'; import { getRecord } from 'lightning/uiRecordApi'; export default class Record extends LightningElement { @api recordId; @wire(getRecord, { recordId: '$recordId', fields: ['Account.Name'] }) record; } Mark a Configuration Object Property as Dynamic and Reactive n the wire adapter’s configuration object, prefix a value with $ to reference a property of the component instance. The $ prefix tells the wire service to treat it as a property of the class and evaluate it as this.propertyName. The property is reactive. If the property’s value changes, new data is provisioned and the component rerenders. In this example, $recordId is dynamic and reactive. import { LightningElement, api, wire } from 'lwc'; import { getRecord } from 'lightning/uiRecordApi'; const FIELDS = [ 'Contact.Name', 'Contact.Title', 'Contact.Phone', 'Contact.Email', ]; export default class WireGetRecordDynamicContact extends LightningElement { @api recordId; @wire(getRecord, { recordId: '$recordId', fields: FIELDS }) contact; get name() { return this.contact.data.fields.Name.value; } get title() { return this.contact.data.fields.Title.value; } get phone() { return this.contact.data.fields.Phone.value; } get email() { return this.contact.data.fields.Email.value; } } Decorate a Property with @wire Wiring a property is useful when you want to consume the data or error as-is. If the property decorated with @wire is used as an attribute in the template and its value changes, the wire service provisions the data and triggers the component to rerender. The property is private, but reactive. This code applies @wire to the record property. import { LightningElement, api, wire } from 'lwc'; import { getRecord } from 'lightning/uiRecordApi'; import ACCOUNT_NAME_FIELD from '@salesforce/schema/Account.Name'; export default class Record extends LightningElement { @api recordId; @wire(getRecord, { recordId: '$recordId', fields: [ACCOUNT_NAME_FIELD] }) record; } Decorate a Function with @wire Wiring a function is useful to perform logic whenever new data is provided or when an error occurs. The wire service provisions the function an object with error and data properties, just like a wired property. The function is invoked whenever a value is available, which can be before or after the component is connected or rendered. wire Service LWC Example by decorating a Function with @wire wireFunctionLWC.js // WireFunctionLWC.js import { LightningElement, api, track, wire } from 'lwc'; import { getRecord } from 'lightning/uiRecordApi'; export default class WireFunctionLWC extends LightningElement { @api recordId; @track record; @track error; @wire(getRecord, { recordId: '$recordId', fields: ['Account.Name'] }) wiredAccount({ error, data }) { if (data) { this.record = data; this.error = undefined; } else if (error) { this.error = error; this.record = undefined; } } get name() { return this.record.fields.Name.value; } } wireFunctionLWC.html wireFunctionLWC.js-meta.xml   Now we can add this lwc component on the account detail page. Go to Home page Click Setup (Gear Icon) and select Edit Page. Under Custom Components, find your wireFunctionLWC component and drag it on Account detail page. Click Save and activate. We will have the following output.   Call Apex Methods using wire Lightning web components can import methods from Apex classes into the JavaScript classes. Once after importing the apex class method you can able call the apex methods as functions into the component by calling either via the wire service or imperatively. The Apex Method should be marked with @AuraEnabled. Before you use an Apex method, make sure that there isn’t an easier way to get the data. See whether a base Lightning component, like lightning-record-form, lightning-record-view-form, or lightning-record-edit-form works for your use case. If they don’t give you enough flexibility, use a wire adapter like getListUi or getRecordUi. And if you can’t use a wire adapter, write an Apex method. Apex wire Import Syntax We need to import the @salesforce/apex scoped module into JavaScript controller class. import apexMethodName from '@salesforce/apex/Namespace.Classname.apexMethodReference'; Here is list of important point of importing apex method: apexMethodName : An imported symbol that identifies the Apex method. apexMethodReference : The name of the Apex method to import. Classname : The name of the Apex class. Namespace—The namespace of the Salesforce organization. Specify a namespace unless the organization uses the default namespace (c), in which case don’t specify it.   For more details refer to Call Apex Methods In Lightning web components Most of the information in this article is copied from the official link. For more details about wire Service LWC please refer official link. The post wire Service LWC Lightning Web Component appeared first on Salesforce Blog.

[tak4hir0]

Special thanks to my co-author Naren Somisetty, with help from Sangita Gupta, Jaswinder Rattanpal and Evan Weaver. With the release notes for Spring ’20 being over 650 pages long, it’s clear that this latest Salesforce release is all about expanded innovations across the entire Customer 360 Platform. We’re here to help you discover the most impactful new features for ISVs, so you can continue pushing the envelope of innovation and customer success by extending the capabilities of Salesforce Partner integrations. We’ve compiled the top 10 features ISVs should take advantage of in Salesforce Spring ’20. Keep on reading to learn more about each feature. Lightning Web Component running from localhostLightning Web Components now offers Local Development so that you can develop component modules and view your changes live without publishing your components to an org. The new Salesforce CLI plugin lwc-dev-server configures and runs a Lightning Web Components-enabled server directly on your computer. You can access the local development server from the command line or through Visual Studio Code by having the Lightning Web Components Extension installed and authorized against a Developer Hub-enabled org such as your Partner Business Org. Although this feature only speeds up development, please keep in mind that this feature is still in Beta.. Additional Resources: Increase Productivity with Local Development for Lightning Web Components Developers can now use the URLENCODE function when constructing links and buttons allowing the ability to pre-populate default values on a record’s creation page. Note that this feature doesn’t work in Lightning Out, Lightning Communities, or the Salesforce mobile app and works only when creating custom buttons and links, not custom fields. Additional Resources: Navigate to a Record’s Create Page with Default Field Values The maximum daily cap of 1,000,000 API requests that had previously applied to Enterprise Edition and Professional Edition with API Access Enabled has been removed. Rather than cutting off API access abruptly in subscriber orgs, the call limit increase was added to allow orgs to handle temporary spikes in API usage. However, with great power comes great responsibilities. Partners should still continue to write efficient API queries by making use of indexing, batching and implementing Platform Events instead of polling in order to ensure predictable and reliable performance. Additional Resources: View Monthly API Calls with a New Usage-Based Entitlement What Happens If You Reach or Exceed Your API Request Limit Admins can now mask data and clone sandboxes that are on a different major Salesforce release version from the source production org. These features allow ISVs to deploy beta versions of their application to sandbox copies of subscriber orgs; ensuring reliability, usability, and consistency before publishing a new revision of their application onto the AppExchange. Additional Resources: Secure Your Sandbox Data with Salesforce Data Mask The wait time is now much less when creating a new package version when using Salesforce CLI or the Tooling API. This feature allows ISVs to create and install Managed packages into production orgs with less delay after promoting a package version to released. Similarly, iterate package development more efficiently by skipping validation of dependencies, package ancestors, and metadata for the creation of Unlocked and 2nd Generation Packages by using the --skipvalidation flag in SFDX. However, these features should only be used in conjunction with a Continuous Integration process. It’s a best practice to create package versions without skipping validation to catch errors that developers might otherwise miss. Running the package:version:list and package:version:report commands shows more information on package code coverage, package ancestors, and whether validation was skipped all within the SFDX CLI. Additional Resources: Create and Install Package Versions Faster View More Packaging Details in List and Report Salesforce CLI Commands Viewing app usage information though Einstein Analytics LensesBeginning March 2nd, 2020, all newly provisioned Partner Business Orgs will come included with Free Einstein Analytics Licenses. The bundling of Einstein Analytics is designed to help Partners better understand and visualize how often subscribers use Custom Objects, Lightning Apps and Record Pages in order to inform future feature development decisions, analyze adoption and understand user behavior. Existing Partner Business Org users should log two cases along with the orgID of your PBO via the Partner Community to enable App Analytics and Einstein Analytics Licenses. Additional Resources: Analyze Lightning Page Usage and Company Information with AppExchange App Analytics Get App Smart: How to Use AppExchange App Analytics View installed apps and pending updates directly from AppExchangeThe AppExchange and Trailblazer product teams have been hard at work revamping and adding new features for customer subscribers. Your customers will be pleased to learn that they have even more control of the applications installed in their orgs by being able to manage AppExchange installs and settings directly through the AppExchange. Customers can also choose to publish feedback on consultant projects via the Customer Satisfaction Survey directly on AppExchange. Verified Project Reviews help customers evaluate consultants for potential projects, and help consultants understand potential areas of improvement. Additional Resources: Manage AppExchange Installs and Settings with Ease Using Trailblazer.me Hire Confidently with Enhanced Salesforce Consultant Reviews on AppExchange With Action Plan Template Packaging, you can now include action plan templates within your Managed Packages. Action Plan Templates allow you to create actionable follow up activities for sales personnel and can be associated with Standard Objects, and even for Tasks associated to Custom Objects that have Activities enabled. Additional Resources: Share Action Plan Templates Using Packaging Salesforce Security Alerts viewed from the Setup MenuFor partners that make use of Salesforce Communities, Sites, Portals or Chatter External, the External Sharing Model is enabled by default in all Salesforce orgs created in Spring ’20 or later; these changes don’t affect existing customers.External org-wide defaults let you set more restrictive levels of access for external users, instead of giving internal and external users the same default access. In these newly created orgs, external access levels are initially set to Private for all objects. Ensure that your managed packages are up-to-date and work for the default private changes to the external sharing model. Additional Resources: Sharing: Enhancements to External Organization-Wide Defaults The Google Chrome 80 release changes the default cross-domain (SameSite) behavior of cookies. While this change enhances security and privacy, it requires customers and partners to verify that Salesforce integrations continue to work properly. This change particularly affects partner integrations that use cookies, iFrames or connect to external data sources via HTTP endpoints. Before the Chrome 80 release, test any custom Salesforce integrations that rely on cookies owned and set by ISV integrations. If regressions are found, update the SameSite attribute on cookies used for cross-domain communication to explicitly set SameSite=None; Secure. Additional Resources: Prepare for Google Chrome’s Changes in SameSite Cookie Behavior Curious about what’s coming out in the future? This section of resources outlines Beta and Pilot features that have yet to be marked as Generally Available, so please do not include any components that make use of these features in Managed Packages. Communicate Across Salesforce UI Technologies with Lightning Message Service (Beta) Increase Productivity with Local Development for Lightning Web Components (Beta)Protect Custom Settings in Developer and Scratch Orgs Protect Custom Metadata Types in Developer and Scratch Orgs Sharing: Enhancements to External Organization-Wide Defaults Update Managed Packages for External Sharing Model Changes Update New and Changed Records 10 Times Faster by Using Before-Save Updates in Flows Make Flows Respect Access Modifiers for Legacy Apex Actions (Critical Update)

[tak4hir0]

As usual, Spring arrives early for the Salesforce world, and with it, our latest release. During this prerelease cycle, the developer evangelist team has been busy updating our gallery of sample apps with the latest and greatest features. Here’s a list of items that you can find if you pull down the latest from GitHub. What is the Sample Gallery? The sample gallery is a set of reference apps that showcase a range of low-code to pro-code developer features of the Salesforce platform. Each sample app takes an idea and implements it in the Salesforce platform along with other related apps and features e.g. mobile apps, external-facing web apps, integrations, etc. You can read about all the apps on the Sample Gallery landing page, which also contains links to source repos for each app. LWC Properties Are Automatically Reactive In Spring ‘20, the Lightning Web Component core framework has an added feature that makes all properties reactive without the need to be explicitly decorated as such. In the past, where you would have seen @track used to trigger a DOM refresh in LWC, this becomes no longer necessary. To address this, we’ve removed the @track decorator. The code below from the todoList component in the LWC Recipes app shows one instance of how this looks in our sample apps. Previously, the filteredTodos array property was decorated with @track. @track filteredTodos = []; Again, with the new “all properties are reactive” feature, this is no longer necessary; with one important exception. You must use @track to observe changes in the properties of an object or elements of an array. In other words, if you mutate an object or array in place and you want to update the DOM based on that, @track is required. Understanding array or object mutation in JavaScript is not always straightforward. However, every instance of our sample apps follows the practice of not mutating objects or arrays in place, but rather reassigning them when we need to change their state. In the filteredTodos example above, we have removed @track. todo.priority === true ); } else { this.filteredTodos = this._todos; } } ... } When the filterTodos() function is invoked, we use the Array.prototype.filter() higher order function on the “master” list of todo items in the private _todos array. The filter function always returns a new array instance, meaning the line this.filteredTodos = this._todos.filter... will always cause a new object to be assigned to this.filteredTodos and trigger the now implicit reactivity of that property. But be careful, some higher-order array functions (like Array.prototype.sort()) modify an array in place. If you find yourself using one of these, you might want to look into explicitly creating a new array or alternatively, actually use the @track decorator on that array. For more on the implementation of reactive data types in LWC, we recommend reading the documentation on that topic from the LWC open source project. Lightning Pages on Desktop and Mobile Prior to Spring ‘20, there was no easy way to bring Lightning Pages to mobile. Now, you can design your Lightning Pages for mobile as well as desktop. This includes some of the standard templates, but you can also raise the bar by creating your own custom templates. To bring this to life, we updated the custom Lightning page template in the Dreamhouse app. Custom page templates are implemented in Aura today. Above you can see the markup used to define whether the template will use a layout that supports desktop or mobile, based on information provided by the browser. We reviewed components and modified any we needed to in order for them to work in a small form factor. In addition to ensuring the components themselves were responsive, we also needed to configure the metadata file to indicate which form factors a given component supports. Finally, we configured the app as well as several record pages to be available for mobile, and we were now all set for our pages to work in both mobile and desktop. Check In Your Community For developers working with Communities, the Communities Experience Bundle is a long awaited improvement to your application lifecycle management. This new way to store your community configuration creates a bundle of files which allows you to build, configure, and customize your community as well as check the entire configuration in version control, in a JSON-based format. No more binary .site file! This change also now makes it possible to create and test your community in a scratch org and manage its deployment from the Salesforce CLI. The experience bundle feature has been in closed pilot… until now. In moving to being generally available, the experience bundle feature adds support for unlocked packages, as well as support for additional Communities configurations that weren’t in the pilot. You can see this in use and test it out in the e-bikes sample app. Please note that the effort to migrate an existing community to the experience bundle format varies greatly between orgs. If you decide to make the transition, be sure to budget time to investigate how this change will impact you. If you would like to read more about using the experience bundle, be sure to check out the Communities developer guide, or read about the implementation specs in the Metadata API developer guide. You can also watch this segment on experience bundles from the release readiness live webinar. SOQL SECURITY_ENFORCED Queries Apex has been introducing some exciting new features, and nothing is more exciting to you (and your compliance team) than more secure data access. While some of these are still in beta, we’re pleased to include the new SOQL WITH SECURITY_ENFORCED clause in most Apex classes that use SOQL (where the SOQL fits the restrictions of that feature) Here’s an example: findContacts(String searchKey) { String key = '%' + searchKey + '%'; return [ SELECT Id, Name, Title, Phone, Email, Picture__c FROM Contact WHERE Name LIKE :key AND Picture__c != null WITH SECURITY_ENFORCED LIMIT 10 ]; } The WITH SECURITY_ENFORCED clause allows you to bring object and field security into your Apex SOQL queries with one simple statement. There are a few rules around using it correctly, so be sure to check out the documentation and the release notes for implementation details. A segment from the release readiness webinar that covers the new Apex security features can be seen here. Navigating to New Records with Default Values The term “url hack” has long been fabled in the annals of Salesforce developer lore as a by-the-seat-of-your-pants “pattern”. Well, hack no longer! In Lightning, both Aura and LWC components support the ability to navigate to a new record with default values. We’ve implemented this in its own recipe in the LWC Recipes app. import { LightningElement } from 'lwc'; import { NavigationMixin } from 'lightning/navigation'; import { encodeDefaultFieldValues } from 'lightning/pageReferenceUtils'; export default class NavToNewRecord extends NavigationMixin(LightningElement) { navigateToNewContactWithDefaults() { // get encoded default values const defaultValues = encodeDefaultFieldValues({ FirstName: 'Morag', LastName: 'de Fault', LeadSource: 'Other', AccountId: '011xxxxxxxxxxxxXXX' }); console.log(defaultValues); this[NavigationMixin.Navigate]({ type: 'standard__objectPage', attributes: { objectApiName: 'Contact', actionName: 'new' }, state: { // assign default values for nav pageReference defaultFieldValues: defaultValues } }); } } Note that for the time being, sfdx-lwc-jest framework does not support the lightning/pageReferenceUtils package, so we’ve implemented a dummy test. We will however be updating this once a better solution appears.   When initiating navigation, the PageReference supports a state value to set default values, and the lightning/pageReferenceUtils utility has been added to correctly encode and decode default values. In Aura, this utility is referenced in markup as a component called Other Items of Note Coming Changes to the sample apps We’re constantly working to improve our sample apps for you. Some great things are planned to ship throughout this year. If you want to get a sneak peak of one of these you should check out Trailhead Live, where developer evangelist Kevin Poorman codes live on…drumroll…Apex Recipes! Stay tuned! You too can contribute If you have an idea for a feature to add to a sample app, or see a bug or potential improvement, we welcome your contributions to the sample apps! Details for how to contribute are located in each sample app repo. So if you see something, file an issue and we can discuss it with you; if you can write the solution, we welcome the PRs. Summing It Up As always, releases are a bit like a birthday present that comes three times a year. We hope you enjoy exploring these features in our gallery of sample apps as we all welcome Spring ‘20 to our orgs.

[tak4hir0]

Web components are a new set of APIs built on web standards that are widely adopted by browsers (see browser support at webcomponents.org). They allow developers to make flexible custom components–but with that flexibility comes responsibility. In this two-part blog, we will outline what web components are and the specific accessibility considerations they have, so you can integrate web components into your own products with all users in mind.  Web Components Web components allow developers to make their own custom components with native HTML and JavaScript. They are built of three parts: Custom elements HTML templates Shadow DOM Salesforce’s Lightning Web Components (LWC) component framework is built on top of web components to make it easy to create fast, lightweight components. Let’s explore an example web component to see how we can best leverage them. Custom Elements This is the custom tag itself, which extends either an existing tag (like HTMLButton) or the base HTMLElement. For my example component, I am going to extend the base HTML element. I have to define the custom element for the browser and connect it to the CustomButton class I made (live finished CustomButton). class CustomButton extends HTMLElement { constructor() { super(); } } window.customElements.define('custom-button', CustomButton); Right now, I have this awesome new tag , but it doesn’t have anything inside of it and it can’t do anything. There are a couple ways to build this component. I could add functionality directly to the custom tag, but in this example I will use HTML templates. HTML Templates There are two ways to create reusable snippets of HTML: and elements. Templates Templates have display=”none” by default and can be referenced with JavaScript, which makes them good for HTML that will be reused in your component. Looking at the CustomButton, using a template makes sense for now. I don’t need a lot of flexibility since it is just a button that developers can pass a custom string to. To begin building my component, I add a template tag in the DOM (Document Object Model) and add a button inside of it. Then, in the constructor I append the contents of the template to the custom element itself.  `; class CustomButton extends HTMLElement { constructor() { super(); this.appendChild(myTemplate.content.cloneNode(true)); this.button = this.querySelector('button'); this.updateText = this.updateText.bind(this); } connectedCallback() { if (this.hasAttribute('text') this.updateText(); } updateText() { let buttonSpan = this.button.querySelector('span'); buttonSpan.innerText = this.getAttribute('text'); } } window.customElements.define('custom-button', CustomButton); My button template has a span inside of it with default text that the user can then replace by passing a string to the custom element with the text attribute. I also added a connectedCallback function, which is a web component lifecycle function that happens when the component is connected to the DOM. In that function I set the innerText of the button to the value passed from the custom component. I can use the CustomButton in my HTML like this: So now, if I use my CustomButton component, the browser DOM will look like this:  Slots Slots allow flexibility, since they let you put anything within them. This is especially useful if you need to allow consumers of your component to add custom HTML. One thing to keep in mind is that slots require that shadow DOM is enabled to work correctly. For my CustomButton component, people might want to add an icon – so I can use a slot! I update the contents of the template to be: Someone using my button can add any icon in their HTML: Which, if shadow DOM is enabled, the browser will render as: For more on the differences between the two, check out Mozilla’s article on templates and slots. Since I have to use shadow DOM for the icon slot, the next step is to look into what the shadow DOM is and how it works. Shadow DOM Up until this point, when I talk about the DOM, it is the main DOM that the browser generates – which is also called the light DOM. If you view the page source of a site, you can see the light DOM, every HTML element on the page.  The shadow DOM is a scoped document object model tree that is only within your custom element. If shadow DOM is enabled in your component, the component’s elements are in a separate tree from the rest of the page. No Shadow vs Open vs Closed Web components don’t need to have shadow DOM enabled, but if it is enabled, it can either be open or closed.  If shadow DOM is not enabled: the component is in the main DOM. JavaScript and CSS on the page can affect the contents of the component. If the shadow DOM is open: the main DOM can’t access the sub tree in the traditional ways, but you can still access the sub tree with Element.shadowRoot. document.getElementById, other query selectors, and CSS from outside the component will not affect it. If the shadow DOM is closed: the main DOM cannot access the elements inside of the component at all. JavaScript and CSS from outside the component will not affect it. There are very few instances where having a fully closed shadow is necessary and the current industry standard is to use open shadow.   To look at the source code for the CustomButton example, I enable the open shadow DOM like this: `; class CustomButton extends HTMLElement { constructor() { super(); let shadowRoot = this.attachShadow({ 'mode': 'open' }); shadowRoot.appendChild(myTemplate.content.cloneNode(true)); } } window.customElements.define('custom-button', CustomButton); The contents of the template are now added to the shadow root, not directly to the custom element. Finishing the Custom Button The HTML is the way I want it to be, so it is time to make the CustomButton interactive. When people click the button, I want to toggle the aria-pressed attribute so users know if it is pressed. `; class CustomButton extends HTMLElement { constructor() { super(); let shadowRoot = this.attachShadow({ 'mode': 'open' }); shadowRoot.appendChild(myTemplate.content.cloneNode(true)); this.button = this.shadowRoot.querySelector('button'); this.handleClick = this.handleClick.bind(this); this.updateText = this.updateText.bind(this); } get ariaPressed() { const value = this.button.getAttribute('aria-pressed'); return (value === 'true'); } set ariaPressed(value) { this.button.setAttribute('aria-pressed', value); } connectedCallback() { this.button.addEventListener('click', this.handleClick); if (this.hasAttribute('text')) this.updateText(); } handleClick() { this.ariaPressed = !this.ariaPressed; } updateText() { let buttonSpan = this.button.querySelector('span'); buttonSpan.innerText = this.getAttribute('text'); } } window.customElements.define('custom-button', CustomButton); Live version This is the final code for my CustomButton, I have added a couple functions: get ariaPressed: returns the value of the aria-pressed attribute on the button inside the custom-button element set ariaPressed: sets the value of the aria-pressed attribute on the button inside the custom-button element. connectedCallback: adds an onClick listener when the component connects to the DOM. handleClick: toggles the value of ariaPressed when the button is clicked Now, I can add my custom button to my HTML like this: And I can programatically set the ariaPressed property like this: document.getElementById('important-button').ariaPressed = true; Conclusion We now have a button component with a property called ariaPressed that can be set with JavaScript. The component combines custom elements, HTML templates, and shadow DOM all with plain JavaScript and HTML, no frameworks required! In part two, I will cover the accessibility concerns related to web components. Resources webcomponents.org Lightning Web Components Mozilla: Using Templates and Slots Mozilla: Web Components Google: Shadow DOM v1 About the Author Lee White is an accessibility engineer at Salesforce, where she focuses on Lightning Platform accessibility. You can follow her on Twitter @shleewhite.