Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Erstellen einer Benutzeroberfläche zum Anzeigen eines Datensatzes

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
  • Stellen Sie einer Anforderung an die User Interface API, um Datensatzdaten und Metadaten abzurufen
  • Erläutern, warum und wie man Formfaktoren, Layouttypen und Zugriffsmodi anfordert
  • Erklären, warum und wie man untergeordnete Datensätze anfordert

Abrufen eines Datensatzes

Ein weiteres Plus der User Interface API ist, dass sie die Dinge zusammenstellt, die Sie zum Erstellen der Benutzeroberfläche benötigen. Wissen Sie, wie viele HTTP-Anforderungen erforderlich sind, um die Objekt-Metadaten, Layout-Metadaten und Felddaten abzurufen, die für die Anzeige des Universal Containers-Datensatzes benötigt werden? Eine.

/ui-api/record-ui/{recordIds}

Schauen wir uns an, wie diese Anforderung im Record Viewer-Code aussieht. Navigieren Sie zur Datei /client-src/sagas/recordFetcher.js. Sie können sie sich in GitHub oder auf Ihrem lokalen Rechner ansehen.

Diese Zeile bildet den Ziel-URL der UI API.
let recordViewUrl = action.creds.instanceUrl + '/services/data/v48.0/ui-api/record-ui/' 
  + action.recordId + '?formFactor=' + action.context.formFactor + '&layoutTypes=Full&modes=View,Edit';

Die Anforderung sendet eine Datensatz-ID, action.recordId, bei der es sich um den Datensatz handelt, den der Benutzer aus der Liste "Zuletzt verwendete Elemente" auswählt. (Der Endpunkt unterstützt mehrere Datensatz-IDs, doch die Record Viewer-Anwendung fordert nur einen an.)

Die Antwort enthält die Layoutinformationen, die angeben, wo die Felder platziert werden und in welchen Abschnitten der Benutzeroberfläche sie sich befinden. Außerdem erfahren Sie, welche Abschnitte ausgeblendet sind – dies bezeichnen wir als den Layout-Benutzerstatus.

Mit den folgenden Parametern wird für die Anforderung angegeben, was in die Layoutinformationen aufgenommen werden soll: formFactor, layoutTypes und modes.

Der Formfaktor ändert das Layout von Feldern. Wählen Sie einen Formfaktor, der dem Gerätetyp entspricht, auf dem die Anwendung ausgeführt wird. Large ist ein Layout für Desktop-Clients. Medium ist ein Layout für Tablets und Small ein Layout für Mobiltelefone. Beim großen und mittleren Formfaktor haben Abschnitte ein zweispaltiges Layout. Beim kleinen Formfaktor sind Abschnitte einspaltig.

Der Layouttyp bestimmt, wie viele Felder zurückgegeben werden. Die möglichen Layouttypen sind Full und Compact. Das standardmäßige vollständige (full) Layout enthält alle Felder des Seitenlayouts, das dem aktuellen Benutzer zugeordnet ist. Das kompakte (compact) Layout enthält alle Felder des kompakten Layouts, das dem aktuellen Benutzer zugeordnet ist. Sie können beide Layouttypen in Setup bearbeiten. Unabhängig vom Layouttyp enthält die Antwort nur Felder, auf die der Benutzer Zugriff hat.

Der Modus entspricht der Aufgabe, die der Benutzer ausführt: Create, View oder Edit. Die Layoutinformationen variieren je nach Modus. Im Create-Modus enthält das Layout beispielsweise nicht den Abschnitt "Systeminformationen", der Felder wie "Erstellt von" und "Zuletzt geändert von" beinhaltet.

Die Record Viewer­Anwendung fordert den View- und Edit-Modus an, wenn also ein Benutzer auf Edit klickt, hat die Anwendung bereits die Informationen, die sie benötigt, um die Benutzeroberfläche zu rendern.

Tipp

Tipp

Um untergeordnete Datensätze zurückzugeben, ohne Abfragen erstellen zu müssen, die zwei Datensätze verbinden, verwenden Sie den Parameter childRelationships. Die Antwort ist paginiert und enthält eine Ebene mit untergeordneten Beziehungen. Diese Anforderung gibt beispielsweise einen Account-Datensatz und seine untergeordneten Opportunity-Datensätze zurück.

/ui-api/record-ui/001R0000003IG0vIAG?childRelationships=Account.Opportunities

Senden von Anforderungen und Aktualisieren des globalen Zustands

Die RecordViewer-Anwendung sendet REST-Anforderungen an Endpunkte der UI API und aktualisiert ihren Redux-Zustand asynchron mit diesen Informationen. Anschließend reagiert die React-Komponentenstruktur auf den geänderten Zustand und aktualisiert die UI.

Redux Sagas verwalten die REST-Anforderungen der Anwendung. Die Anforderung /ui-api/record-ui/{recordIds} wird unter Verwendung der Saga recordFetcher.js durchgeführt. Dieser Code bildet den REST-URL und gibt die Anforderung aus, wobei das OAuth-Zugriffstoken als Bearer verwendet wird. Außerdem wird die Kopfzeile X-Chatter-Entity-Encoding auf false eingestellt, um sicherzustellen, dass Sonderzeichen in JSON nicht HTML-geschützt zurückgegeben werden.

Wenn die Antwort zurückgegeben und ihre JSON-Nutzlast erfolgreich analysiert wurde, wird die Saga durch Senden einer RECEIVE_RECORD-Aktion, die die JSON-Antwort enthält, abgeschlossen. Im Redux-Modell werden Aktionen ausgegeben, um die Absicht auszudrücken, den globalen Zustand zu ändern. Indem wir die Vorgänge trennen, also erst die externe Anforderung stellen, dann den Zustand ändern und anschließend die Komponente aktualisieren, bleiben die Schritte lose gekoppelt.

In Redux fangen Reducer Aktionen ab und nutzen sie, um Aspekte des globalen Zustands zu verändern. Damit in diesem Fall der Teil "record" des globalen Zustands geändert wird, fängt der Reducer record.js die Aktion RECEIVE_RECORD ab und verarbeitet ihre JSON-Nutzlast.
/* /reducers/record.js */
case 'RECEIVE_RECORD':
      return {
        record: recordLayout.getLayoutModel(action.recordId, action.record),
        mode: 'View'
      }

Die JSON-Nutzlast ist in action.record enthalten. Der entstandene neue Zustand steht Komponenten über state.record zur Verfügung. Dieser Teil des Zustands aus dem Reducer record.js wird mit dem globalen Zustand in reducers/index.js zusammengesetzt.

Analysieren der JSON-Antwort und Anzeigen des Datensatzes

Werfen wir jetzt einen Blick in die Hilfsfunkton recordLayout.getLayoutModel(), die im Zustands-Reducer record.js verwendet wird. Diese Funktion ordnet die Datensatzdaten, Layouts und Objektinformationen aus der JSON-Antwort /ui-api/record-ui/{recordIds} und erstellt daraus eine Datenstruktur. Diese Datenstruktur ist der Zustand, auf dem die React-Komponenten der Anwendung basieren.

Am Ende der Datei /client-src/helpers/recordLayout.js setzt getLayoutModel() ein Objekt zusammen, das Folgendes enthält:
  • die Layoutinformationen
  • die Zuordnung von editValues, die für die Nachverfolgung von Änderungen an Feldwerten in der Benutzeroberfläche verwendet werden
  • die einzelne objectInfo, die dem vorliegenden Datensatz entspricht
  • die Datensatz-ID

Die Funktion recordLayout.getLayoutModel() verarbeitet die Layoutinformationen beim Durchlaufen der Layouts. Für jeden Abschnitt in jedem Layout in der Antwort rufen wir getLayoutSectionModel() auf. Diese Methode ruft die Informationen aus der Abschnittskopfzeile des Abschnitts JSON ab. Dann durchläuft sie jede Zeile des Abschnitts, und innerhalb jeder Zeile durchläuft sie jedes Element im Layout.

Für jedes Layoutelement setzt getLayoutItemModel() ein Objekt zusammen, das Folgendes enthält:
  • eine verschachtelte Liste mit Werten (es kann mehrere Werte in einem Element geben, z. B. bei Adressen)
  • Link-Informationen (Links zu anderen Datensätzen)
  • Benutzerdefinierte Link-Informationen (Links zu externen URLs)

Jeder der Werte enthält Informationen darüber, was als Text angezeigt werden soll, die Bezeichnung, die Feldmetadaten, die Bearbeitbarkeit und gegebenenfalls den entsprechenden Auswahllisten-URL der UI API.

Es gibt ein paar Sonderfälle in dieser Methode, da wir spezielle Dinge für Auswahllistenwerte, Verweise, Datumsangaben und Elemente tun, die keine Felder sind. In einem typischen Fall extrahieren wir für ein Layoutelement, das auf einem Nicht-Datumsfeld basiert, die Eigenschaften displayValue und value aus dem zugehörigen Eintrag im JSON-Code der Datensatzdaten.
} else if (record.fields[compValue]) {
        var displayValue = record.fields[compValue].displayValue;
        let rawValue = record.fields[compValue].value;
        if (displayValue == null && rawValue != null) {
          displayValue = rawValue.toString();
        }
        values.push(
          {displayValue: displayValue,
           value: rawValue,
           label:component.label,
           field:compValue,
           fieldInfo,
           picklistUrl,
           editableForNew:item.editableForNew,
           editableForUpdate:item.editableForUpdate,
           isNull:displayValue == null})

Rendern von Layoutkomponenten

Wir haben bereits gelernt, dass das von recordLayout.getLayoutModel() zurückgegebene Objekt als state.record.record im globalen Zustand gespeichert wird. Dieser Zustand wird verwendet, um zugehörige Komponenten in der Benutzeroberfläche zu rendern. Der Container der obersten Ebene, RecordViewerWrapper.js, prüft, ob state.record.record verfügbar ist, und übergibt es nach unten an eine verschachtelte RecordViewer.js-Komponente in der Eigenschaft record. Die in der Komponente RecordViewer.js verschachtelten Dateien RecordSection.js und RecordRow.js rendern ihre Abschnitte und Zeilen.

Sehen Sie sich besonders RecordRow.jsgetViewItemCells() an. Wenn wir jede Zelle in der Zeile rendern, erstellt die Basisfunktionalität ein <div> für jede Komponente im Element. Der <div> erhält einen Schlüssel, da die für React erforderlich ist. Wir verwenden den displayValue, um den Text zu rendern, den Sie auf dem Bildschirm sehen.
{ item.values.map((component, i) => {
             if (component.displayValue && component.displayValue.length > 0) {
               if (component.fieldInfo.htmlFormatted) {
                 return (
                   <div key={'component' + itemLabel + ',' + i} dangerouslySetInnerHTML={{__html: component.displayValue}}></div>
                 )
               } else {
                 return (
                   <div key={'component' + itemLabel + ',' + i}>{component.displayValue}</div>
                 )
               }
             } else {
               return null
             }
           }
          )}

Das Ergebnis ist, dass unsere Anwendung dynamisch durch die Layout- und Objektinformationen, die von der UI API zurückgegeben werden, verändert wird. Anstatt Felder und Feldpositionen im Layout fest zu kodieren, verwenden Sie die UI API, um eine Benutzeroberfläche zu erstellen, die sich selbst neu anordnen kann, wenn der Administrator Layouts und Objekte in Salesforce aktualisiert.