2017-09-19 2 views
0

Alle Cycle.js-Beispiele, die ich bisher gefunden habe, verwenden ein einziges DOM-Objekt namens "DOM" im drivers-Argument zu run(main, drivers). Ist es möglich, mehr als ein Objekt zu haben, z. B. eines mit dem Namen "DOM1" und ein anderes "DOM2"? Der Zweck davon wäre, zwei separate dynamische DOM-Bereiche innerhalb einer einzelnen HTML-Seite zu steuern, um einen dritten DOM-Bereich statisch definiert in index.html zu halten, und zwischen DOM1 und DOM2 eingegrenzt.Kann es mehr als ein DOM-Objekt in den Cycle.js-Treibern geben?

Als Neben Frage, die Beispiele I typischerweise eine HTML gesehen div mit der ID #app oder #main-container, Target und dann wird die Wanne mit einer @cycle/domdiv Funktion definiert, wodurch eine unnötige AFAICT div innerhalb eines div zu schaffen. Ich habe keine klare Erklärung oder Referenz gefunden, wie die virtuellen Knoten definiert werden sollen. Nehmen wir an, dass DOM2 über ein HTML-Element form zielt und das zwei Elemente enthalten soll: input. Hat es mit einem div wie in allen Beispielen zu starten, oder kann die input s direkt in der .map Anruf definiert werden, und wenn ja, wie?

+0

Hier ist eine [ESNextbin] (https://esnextb.in/?gist=b54baa4131974b7f12d190fb63be8aeb) Demo von zwei unabhängigem Dom. – bloodyKnuckles

+0

Danke @bloodyKnuckles. Also ich denke die Antwort ist * ja *, du kannst zwei oder mehr DOMs haben. Meine Frage lautet nun: "Müssen die DOM * unabhängig sein?" wie Sie erwähnt haben und wie in der Demo gezeigt, oder kann ein DOM zumindest passiv den anderen beeinflussen, z. B. das Eingabefeld in DOM1 und das h1-Element in DOM2. Ich denke, ich kann darüber experimentieren. –

Antwort

1

Es gibt nichts, was Sie daran hindert, DOM1 und DOM2 Senken in Ihrer App zu haben. bloodyKnuckles Beispiel veranschaulichen das perfekt https://esnextb.in/?gist=b54baa4131974b7f12d190fb63be8aeb

Das gesagt, ich bin mir nicht sicher, ob ich wirklich den Punkt sehe, dies zu tun. Wenn es um die Leistung geht, glaube ich nicht, dass Sie beim Rendern Ihrer App in zwei DOM-Treiber viel gewinnen werden. Die virtuelle DOM-Bibliothek (im Falle des Zyklus snabbdom) ist darauf zugeschnitten, Teile des DOM zu erkennen, die sich nicht von denjenigen unterscheiden, die letztere enthalten und nur aktualisieren.

Wenn es eine Frage der Verantwortlichkeiten ist (diese 2 Teile von DOM haben sehr unterschiedliche Zwecke), dann würde ich lieber zwei verschiedene Zyklus-Apps erstellen, die beide in verschiedenen Teilen des DOM rendern. (Und rufen dann run zweimal in Ihrer Hauptdatei)

function app1(sources) { 
    return { 
    DOM: xs.of(div("hello from app1")) 
    } 
} 


function app2(sources) { 
    return { 
    DOM: xs.of(div("hello from app2")) 
    } 
} 

run(app1, { 
    DOM: makeDOMDriver("#app1") 
}) 


run(app2, { 
    DOM: makeDOMDriver("#app2") 
}) 

diese Weise können Sie eine klare Trennung der Anliegen der beiden Anwendungen haben.

Nun, um Ihre Frage zu beantworten, warum ein Stück virtuelles DOM in einem div verpackt werden muss. Es ist, weil ein Stück virtuelles DOM ein einzelnes Wurzel Element haben muss. Anders gesagt: Ein Stück virtuelles DOM muss Standalone sein (genauso wie ein HTML-Dokument nur ein einziges <html>-Element hat, welches der Stamm ist). Es ist eigentlich eine nette Einschränkung zu haben, weil es Sie zwingt, eigenständige Komponenten zu haben. Im Beispiel Sie (mit einem <input> Feld) geben, ist es absolut kein Problem in eine vdom wie diese Rückkehr:

DOM: xs.of(input(/*...*/)) 

Aber wenn Ihre Komponente ein input und ein label hat, dann werden Sie brauchen, um es zu umwickeln ein weiterer V-Knoten

DOM: xs.of(div([label(/*...*/), input(/*...*/)]) 
+0

Es ist weder Leistung noch Verantwortlichkeiten. Ich wollte nur nicht den großen statischen Bereich in JavaScript (eigentlich TypeScript) codieren. Allerdings habe ich jetzt erkannt, dass der "statische" Bereich aktualisiert werden muss, so dass das Problem der Aufteilung der Bereiche ist strittig. –

Verwandte Themen