- The document summarizes changes to Lightning Experience and development in Winter '17. Key points include Chatter being rebranded back to its original name, ISVs being renamed, and sidebar navigation moving to the header for improved usability. It also discusses state management best practices for Lightning components using a unidirectional data flow approach with smart and dumb components.

1. Lightning ‘16 Roundup
TL;DR
Mike Tetlow
Bracket Labs
Co-Founder and Lead Developer
mike@bracketlabs.com
@Mikename

2. 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

3. 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!

4. Lightning Experience change highlights(cont):
Custom Record Page by App (Tab Set) or default for all
• Wat?

6. 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

7. 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?

8. Lightning Component State Management
Unidirectional data flow, smart components, dumb components, and Lightning.
Oh My.
Mike Tetlow
Bracket Labs
Co-Founder and Lead Developer
mike@bracketlabs.com
@Mikename

9. 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?

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. Let’s make a component!
Smart: Account Editor
(Container)
Dumb: Account Detail
Dumb: Contact Detail

18. Sample App Demo
https://github.com/mtetlow/Fluxy-Lightning/

19. 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?

20. 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

21. Q&A
https://github.com/mtetlow/Fluxy-Lightning/
@Mikename