Denver Salesforce Developer User Group dec 2016 lightning components
- 1. Lightning ‘16 Roundup TL;DR Mike Tetlow Bracket Labs Co-Founder and Lead Developer [email protected] @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 [email protected] @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
- 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