Ich habe da was übersehen gefunden in den Release Notes für das Winter 17 Salesforce Release, das bei meinem ersten Durchgehen noch gar nicht da war. Das ist so großartig, daß ein Update her muß //

Lightning Base Components

Bei unserer Trailhead DX Viewing Party war Thema Nummer 1: Wir brauchen einen Component Baukasten. Wir wollen uns nicht erst drei Monate einsperren, um grundlegende Components wie Modals, Buttons und Alerts zu konzipieren.

Das hatten unsere Gastgeber damals im Salesforce Büro München deutlich zu spüren bekommen.

Siehe da: Wir haben einen Baukasten bekommen. Er ist noch übersichtlich, aber geht in die ideale Richtung: Als Entwickler kümmere ich mich nicht um das Erstellen von aberdutzenden Components für Buttons und Modals, sondern kann gleich loslegen und Value produzieren ohne mir erst über das Verschrauben der Grundcomponents architektonisch Gedanken machen zu müssen.

Vor Winter 17 war das definitiv ein Thema und für viele Lightning Fans ein großes Kopfzerbrechen.

Die Community hat das Thema auch schon aufgegriffen. Danke an Mohith Shrivastava für seinen Beitrag auf Medium. Mohith hat auch gleich eine Developer freundlichere Übersicht der aktuellen Base Components nebst Attributen und einer Vorschau zusammengestellt: Link

Achtung: Auch in Prerelease Orgs ist nicht zwingend gegeben, daß Ihr Zugriff auf die Base Components habt. Kann noch etwas dauern.

Lightning Data Service

Das hat noch nicht mal einen Link in den aktuellen Release Notes, wird aber schon durch Twitter und Blogs getragen, unter anderem von Dave Carroll: Der Data Service ist in etwa ein Standardcontroller für Lightning Components. Um an Objektdatan ranzukommen, wird damit ein serverseitiger Apex Controller obsolet. Sobald ich die Finger drauf kriege, gibt es hier ein Update.

Kurzum: Für hunderte von UseCases wird damit Apex hinfällig und auch ein Entwickler, der Apex kann.

Update: 17.09.2016 Hier eine Beispielanwendung für Lightning Data Service aus der offiziellen Entwickler-Dokumentation für v38.

Hinter die Ohren schreiben müssen wir uns:

The callback passed to getNewRecord() must be wrapped in $A.getCallback() to ensure correct access context when the callback is invoked. If the callback is passed in without being wrapped in $A.getCallback(), any attempt to access private attributes of your component results in access check failures.
Even if you’re not accessing private attributes, it’s a best practice to always wrap the callback function for getNewRecord() in $A.getCallback(). Never mix (contexts), never worry.
Saleforce Developer Documentation (Hrv. v. Verf.)