Lightning ‘16 RoundupTL;DR

Mike Tetlow

Bracket Labs

Co-Founder and Lead Developer

mike@bracketlabs.com

@Mikename

Branding Changes:

Chatter is back

• LEx initially had Chatter being called “Feed” indicating that Salesforce was backing from the Chatter Brand

• Winter ‘17 has the “Feed” references back to being called Chatter

• Maybe nostalgia?

ISV Rebrand

• ISVs were rebranded as “App Vendors”

• ISVs were quickly rebranded again to “App Innovation Partners”

Communities Templates

• Rebranded to “Lightning Bolt”

External Objects

• They were Lightning Connect, now it’s Salesforce Connect

Lightning Experience change highlights:

Sidebar Nav went to the Header

• Brings us back to something very close to Classic tabsets

• Reason = Usability

RIP IE11

• New orgs after Summer ‘16 get redirected to classic, Dec 16 2017 (1yr from now) redirect for everyone

• YAY

Readiness check

• New utility in setup that looks at features and customizations in your org and recommends if ready or work

needs to be done to migrate.

AppExchange in Setup

• New setup tab that allows you to get to the AppExchange in setup without going to appexchange.com

• Neat, hopefully the SSO is easier!

Lightning Experience change highlights(cont):

Custom Record Page by App (Tab Set) or default for all

• Wat?

Lightning Experience change highlights(cont):

Feature Parity

• Lots of work done, worth checking again.

What needs work

• Encrypted data is not masked in Lightning Experience, need developer to apply it manually in custom

component

• No account Hierarchy

• Bug with Account teams, if owd for contacts is private, contacts added to team don’t default to private

• Contract History is missing

• Can’t directly email a quote from the PDF preview

• List view actions are client side and need the data to be fully loaded to client for edits (ie edit when only 50 /

200 are displayed, only the 50 will be edited)

• Lots more at: https://releasenotes.docs.salesforce.com/en-us/winter16/release-

notes/lex_gaps_limitations.htm

Lightning developer change highlights:

lightning: namespace global components

• Abandoning ui:

• Lots of duplicative work with ui: (lightning:select vs force:inputSelect)

• Adhere to SLDS

Access checks live

• No access=“global”/”public” = you’re gonna have a bad time

Locker Rollout Delayed until Spring ‘17

• Should start porting now, some people can’t turn it off unless in managed package

Lightning Out

• Focus seems to have been lost imo, many components only work well within one.app

• Some aren’t documented to only work in one.app, like force:recordView/force:recordEdit

• force:recordPreview only works in one.app, wtf?

Lightning Component State ManagementUnidirectional data flow, smart components, dumb components, and Lightning.

Oh My.

Mike Tetlow

Bracket Labs

Co-Founder and Lead Developer

mike@bracketlabs.com

@Mikename

Common Lightning Development Questions:

How do I tell the parent something happened on the child?

How can a component communicate with a sibling component?

General answer is events!

How do I add/delete a bunch of components via javascript?

How do I pass a value by reference or by value?

Can we make this more obvious/less of a problem via a design pattern?

The Problem:

What is state?

• Data you load from the server

• Pending changes on the client side

• Newly modified data from the server

How do you change state?

• Some kind of user interaction =>

• A non-persisted client side change

• A persisted server side change

• Some random background action

Why do you change state?

• Some kind of user interaction necessitates change of data or how the data is displayed

Can every component have state?

• Sure… should it?

State and where it is held

The Solution:

Keep all state in one spot

• Benefits

• One source of truth

• Lots of times state winds up shared between components as an application grows

• Debugging

• Large teams working on the same codebase

• Cons

• One source of truth means that you have to change your thinking

• More work

• You have to go up the component tree to modify

• You have to pass more stuff down the component tree

How do?

One component holds the state and is “Smart”

• Smart components do

• Fetch data from the server

• Apply changes to the application state

• Persist data on the server

• Smart components do not

• Deal with complex UI layout

Other components are “Dumb”

• Dumb components do

• Deal with complex UI layout and all presentation of data

• Say something has happened from the user

• Dumb components DO NOT

• Mutate State

• Temporarily change the presentation of data

Smart Component Shape

What does a Smart Component look like?

• Needs

• Handle data fetching

• Handle what dumb components say

• Store and handle all application state

• Keep track of how dumb components should present data

Dumb Component Shape

What does a Dumb Component look like?

• Needs

• Do a whole lot of layout

• Say the user has done something

• All UX work

Dumb Component -> Smart Component Communication

When something happens on a dumb component, the smart component needs to be informed to

change application state

• Needs

• Execute something on the parent component

• You can pass a attribute as an AURA.Action that maps to a function on the parent component

• You can fire a component event from the dumb component and handle it in the smart component

• Events approach

• We can make a single generic action event and identify the actions via a key, and provide needed attributes within the

event

• We can make a generic handler component that looks a lot like a Flux store

Communication Flow

Dumb Component Smart Component

Server / Apex

User Interaction

Smart Component

Component event with

attributes describing the action

Smart Component Controller parses

action event and does things:

Server action, Optimistic Updates,

Loading indicators

Server returns transaction to Smart

Component controller

Smart Components updates attributes

appropriately

Attributes from the Smart

Component flow down and

update the dumb component

Optional: Optimistic updates

update the dumb component

Let’s make a component!Smart: Account Editor

(Container)

Dumb: Account Detail

Dumb: Contact Detail

Sample App Demo

https://github.com/mtetlow/Fluxy-Lightning/

What do we think about this approach?• Cons

• Lots of typing

• Component Event bubbling is a little weird

• Events are great, they allow us to do a lot of cross component communication

• But, they don’t bubble like traditional DOM events. WTF is a facet provider? and why does the average lightning developer need to

know that?

• Pros

• Consistency is key

• If you are developing a large set of components, keep them consistent, working between components that have different philosophies

on where state lives will be miserable.

• Large teams all understand

• Possible Gotchyas

• Render speed? Solved in React world via immutable data and lifecycle hooks. How do in Lightning world?

Lessons learned• We all know state is evil

• State is bad because if it mutates and you’re not expecting it, strange things happen in your app

• Keeping the locations where state is mutated contained dramatically increase the speed at which issues can be

resolved

• Apply proven concepts to Salesforce development

• While the APIs and shape of Salesforce front end dev are new and different, lessons learned from all component based front end dev

apply to Lightning Components

Q&Ahttps://github.com/mtetlow/Fluxy-Lightning/

@Mikename