Pushpin: Ideen vom Bauernhof mitbringen

Erstellt am 6. Nov. 2019  ·  4Kommentare  ·  Quelle: automerge/pushpin

Ich habe ein bisschen mit Pins herumgespielt #310 und #316 Ich habe erkannt, dass das, was ich wirklich erreichen möchte, mehr oder weniger das ist, was ich mit meinem dat://code.gozala.io/-Experiment wollte (was nicht so ist anders als https://observablehq.com/), das ist eine Möglichkeit, Code zu schreiben, mit dem ich Daten nehmen und entweder ein einzelnes Widget oder ein wiederverwendbares Widget erstellen kann. Ich nehme an, ich verwende es etwas ähnlich wie Tabellenkalkulationen, außer mit einer maßgeschneiderten Oberfläche, die auf eine bestimmte Aufgabe zugeschnitten ist.

Tatsächlich war Farm genau das, na ja, eigentlich viel besser, da ich finde, dass Board eine viel bessere Oberfläche für diese Art von Interaktionen ist als ein Notizblock, auf dem Sie nach oben und unten scrollen müssen, oder eine Tabellenkalkulation für diese Angelegenheit.

Also habe ich mich gefragt, ob wir wiederbeleben könnten, was Farm so überzeugend macht. Aus meinem Gespräch mit @pvh habe ich das Gefühl, dass Elm zwar eine wirklich nette Sprache ist, sich aber in der Praxis als sehr einschränkend erwiesen hat 😢 (was leider die Erfahrungen widerspiegelt, die ich damit bei meinen Versuchen hatte, es für https:// github.com/browserhtml/browserhtml oder sogar in erwähntem https://observablehq.com/). Ich denke jedoch, dass das überzeugendere Element der Farm die Idee war, dass alles auf dem Bildschirm mit (doc, lens) dargestellt wurde, wobei lens selbst ein Stück Code war, der auch in einem Dokument gespeichert war.

Ich möchte dies zurückbringen, aber (zumindest anfangs) den Elm-Compiler weglassen. Es kommt auch einfach so vor, dass ich die https://github.com/mozilla/reflex/ Bibliothek verwendet habe, die mehr oder weniger Elm-Architektur in JS ist, die keine Kompilierungsschritte erfordert (Typprüfer wäre jedoch nett). .

Das alles zusammenzufügen, möchte ich versuchen:

  1. Grow #310 wird zu einer "Lens Editing"-Komponente, die es im Wesentlichen ermöglicht, ein kleines bisschen JS zu schreiben, das dann über eine URL verwiesen und geladen werden kann. Leider scheint es, dass hypermerge:/ URLs nicht geladen werden können, nur hyperfile:/... könnte eine sein, aber vielleicht könnte das behoben werden oder im schlimmsten Fall könnte die Komponente nach Änderungen neue hyperfile:/ URLs erstellen.

  2. Erstellen Sie eine weitere „Pipeline“-Komponente, die die „Objektiv-Authoring“-Komponente oder vielmehr einen Selektor für vorhandene Objektive und einen Daten-„Doc“-Selektor einbettet, um sie miteinander zu projizieren. _Ich möchte, dass die Pipeline nicht nur auf die Ansicht (Daten, Linse) des Linsenprojekts (HTML) beschränkt ist, sondern dass Daten zu Datenprojektionen zugelassen werden, damit die Dinge in größeren Pipelines verkettet werden können, aber das könnte im Moment ein bisschen weit hergeholt sein. _. Das Standardobjektiv könnte Inspektor sein (siehe #316), so dass nur das Dokument etwas rendern würde und von dort aus könnte man wählen, ob man ein anderes verwenden oder eines erstellen möchte.

Beachten Sie, dass ich mit so etwas leicht das von mir häufig verwendete Tool https://hackmd.io/ neu erstellen könnte, wo ich die Komponente „Code Editor“ zum Eingeben von Markdown und die Komponente „Pipeline“ verwenden könnte, um die Vorschau nebeneinander zu rendern oder was auch immer Sinn macht.

PS: Ich denke immer noch über diese Idee nach, aber ich würde sie für Feedback teilen und versuchen, sie zu dokumentieren

Hilfreichster Kommentar

cc @pfrazee scheint dem zu ähneln, was Sie mit "Dateien anzeigen" in Beaker tun.

Alle 4 Kommentare

cc @pfrazee scheint dem zu ähneln, was Sie mit "Dateien anzeigen" in Beaker tun.

Das ist auch sehr ähnlich zu dem, was Wireline zu tun versucht, denke ich.

Eine andere Sache, die mir immer wieder durch den Kopf geht, ist, wenn ich an data -> view und data -> data denke, ist es irgendwie immer der Sprung vom ersten zum zweiten. Ich erinnere mich, dass es in einer der Diskussionen auf http://offlinefirst.org/camp/ die Idee gab, Links zu den Datenblöcken (doc im Kontext von Pin) für "gerenderte Ansichten" und Links zu "Quellcode" für anzuhängen Wiedergabe dieser Ansichten.

Was wäre, wenn wir data -> view zu data -> data verallgemeinern würden, wobei die Ausgabe zufällig ein html -Dokument wäre (das es vielleicht sogar wert wäre, als solches Dokument beibehalten zu werden). Auf diese Weise könnte Pushpin nur Dokumente rendern, die zufällig HTML direkt sind und solche, die nicht data inspector sind.

Als vorhandene Widgets könnten sie als Note : data -> html , Thread: data -> html usw. angesehen werden.

Das Hauptproblem beim Persistieren und Wiederherstellen von HTML sind Ereignis-Listener, aber das ist auch das Problem, mit dem ich mich befasst habe, als ich versucht habe, die gesamte Anwendungslogik aus dem Hauptthread zu entfernen, und ich denke, ich habe einige Ideen, wie ich das angehen kann.

Um genau zu sein, damit es von der Haupt-Thread-Lösung funktioniert, auf die ich mich festgelegt habe, war die Verwendung einer decoder.flow- Bibliothek, die von Elms JSON-Decoder- Bibliothek inspiriert ist, in der Decoder deklarative Parser-Komibantoren sind, die serialisiert, in den Haupt-Thread geladen und verwendet werden können um relevante Informationen aus dem Ereignis zu extrahieren / zu codieren und an den Thread zurückzugeben, in dem das Programm ausgeführt wird.

In diesem speziellen Anwendungsfall denke ich, dass komponierte Encoder im selben Dokument wie die gerenderte HTML-Ausgabe gespeichert und mit ihrer Adresse im Hash referenziert werden könnten (es ist wahrscheinlich der Inhaltshash).

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

edrex picture edrex  ·  7Kommentare

radio-alice picture radio-alice  ·  7Kommentare

Gozala picture Gozala  ·  13Kommentare

pvh picture pvh  ·  4Kommentare

Gozala picture Gozala  ·  9Kommentare