Wiederverwendung von Komponenten

Question

Kann mir bitte jemand helfen, Komponenten, Abfragen usw. besser zu verstehen. Ich habe Schwierigkeiten mit einer scheinbar trivialen Aufgabe, ich brauche eine Komponente mit parametrisierter Abfrage. Instanzen dieser Komponente müssen in einer übergeordneten Komponente enthalten sein, zB Ich möchte Listen mit verschiedenen Arten von Früchten, die unter einer Gruppe von Kindern verteilt werden müssen, und jede Zeile würde den Namen eines Kindes und eine Menge von Früchten einer Art anzeigen:

(defui FruitsLedger 

    static om/IQuery 
    (query [this] 
     '[(:data/fruits) {:kind ?kind}]) 

    Object (render [this] 
      (let [{:keys [data/fruits]} (om/props this)] 
       (dom/ul nil (apply #(dom/li nil (str "for " (% :kid) " " (% :qt)))))))) 

jetzt muss ich die zwei Instanzen lassen sagen dieser Komponente in einer anderen Komponente

wo :params

für die erste Instanz wäre: {:kind :apples}

für die zweite Instanz wäre:

| apples  | oranges  | 
    |---------------+---------------| 
    | for Aaron 2 | for Katie 1 | 
    | for Dan 1  | for Rob 3  | 
    | for Charles 0 | for Charles 3 | 
    |    |    | 
    |---------------+---------------| 

Answer 1

Ich bin sicher, dass parametrisierte Abfragen haben ihren Nutzen: {:kind :oranges}

diese 2 Listen ähnlich wie diese machen sollte. Aber vielleicht können dieses Problem und andere ähnliche Probleme gelöst werden, ohne auf sie zurückzugreifen.

Haben Sie :app/fruit-query-kinds in Ihrer Datenbank (Standard-DB-Format). Es wird eine Liste von Früchten sein. Sie haben bereits die Fruchtkomponente, aber Sie benötigen eine andere Komponente, die diese Idee hat, eine Liste von Fruchtarten für Abfragezwecke zu sein. Geben Sie dieser Komponente eine Abfrage und eine ID. Es spielt keine Rolle, ob es angezeigt wird oder nicht. Das Wichtigste ist, die Datenstruktur richtig zu machen. Sein Ident wird nur etwas wie: '[:fruit-query-kind/by-id 1100], und es könnte aus '[:fruit/by-id 10] und '[:fruit/by-id 20] bestehen. Gemäß Ihrem Beispiel wird 10 die ID für Äpfel und 20 für Orangen sein. Das ist der Refs-Wert (ein Vektor von Idents im Standard-DB-Speicher) des Schlüssels :app/fruit-query-kinds. 1100 ist nur eine einzigartige Zahl, von der nicht zu erwarten ist, dass sie sich ändert.

Die Datenstruktur ist die wichtige Sache, und alles kann darin modelliert werden, auch Abfrageparameter.

Sie benötigen Mutationen und einige Tasten (oder andere Eingabe), die transact! irgendwo aufrufen, die direkt die Fruchtabfragearten in Ihrem DB ändern. Wenn Sie kein erneutes Rendern benötigen, rufen Sie transact! mit dem Reconciler der App und nicht mit einer Komponente auf.

Die Idee ist, dass Sie dann eine Komponente/s haben können, die die zuvor vom Benutzer getroffene Auswahl abfragt. So wird Ihre erste Listen-Komponente dort nicht wissen, dass es für Äpfel sein soll - alles was es weiß ist, dass es Früchte der ersten Obst-Abfrage-Art anzeigen soll.

ich gefunden habe, dass Sie so viele zu-ing tun können, und fro-ing zwischen der Ansicht und dem db, wie Sie mögen, die DB mit speichert nicht nur Daten, sondern den aktuellen Stand der Ansicht. Bisher war das einzige Mal, dass ich damit in Konflikt kam, dass ich fälschlicherweise über die not des booleschen Schlüssels in der Abfrage der Komponente gehandelt habe. Das endete natürlich in einem ewig flackernden Bildschirm.

Meiner Meinung nach ist die Art, einfach mit Om Next auf dem Client zu arbeiten, für alle Ihre Lesevorgänge identisch, alle unter Verwendung von db->tree. Sobald Sie diesen Ansatz akzeptiert haben, besteht der nächste Schritt darin, sie alle gemeinsam loszuwerden, was Sie tun können, indem Sie in das Framework Unentleert wechseln.