画鋲を少し#310と#316で遊んで、私が本当に達成したいことは、多かれ少なかれ、 dat://code.gozala.io/実験で望んでいたことであることに気づきました(これもそうではありません) https://observablehq.com/とは異なります。これは、データの一部を取得して、1つだけのウィジェットまたは再利用可能なウィジェットを作成できるコードを記述する方法です。 特定のタスクに合わせた特注のインターフェイスを除いて、スプレッドシートに沿っていくらか使用していると思います。
実際、ファームはまさにそれであり、実際にははるかに優れていました。ボードは、上下にスクロールしなければならないメモ帳やスプレッドシートよりも、この種のインタラクションにとってはるかに優れた表面であることがわかりました。
だから私は、農場をとても魅力的なものにしているものを復活させることができるかどうか疑問に思っています。 @pvhとの会話から、Elmは本当に素晴らしい言語ですが、実際には非常に制限されていることがわかりました😢(https://で使用しようとしたときに経験したことを反映しているのではないかと思います)。 github.com/browserhtml/browserhtmlまたは前述のhttps://observablehq.com/)。 ただし、ファームのより説得力のある要素は、画面上のすべてが(doc, lens)
を使用して表され、 lens
自体も一部のドキュメントに格納されているコードであるという考えでした。
これを元に戻したいのですが、(少なくとも最初は)Elmコンパイラを省略しています。 また、私がhttps://github.com/mozilla/reflex/ライブラリを使用していたこともあります。これはJSのElmアーキテクチャであり、コンパイル手順は必要ありません(タイプチェッカーは便利ですが) 。
したがって、これらすべてをまとめて、これを試してみたいと思います。
#310を成長させて「レンズ編集」コンポーネントにします。これにより、基本的にJSを少し記述して、URLを介して参照およびロードできるようになります。 残念ながら、 hypermerge:/
URLはhyperfile:/...
のみをロードできないようですが、アドレス指定できるか、最悪の場合、コンポーネントが変更後に新しいhyperfile:/
URLを作成する可能性があります。
別の「パイプライン」コンポーネントを作成します。このコンポーネントには、「レンズオーサリング」コンポーネント、つまり既存のレンズ用のセレクターと、一方を他方に投影するためのデータ「ドキュメント」セレクターが組み込まれています。 _パイプラインをレンズプロジェクト(HTML)ビューの(データ、レンズ)だけに限定せず、データからデータへの投影を可能にして、物事をより大きなパイプラインにチェーンできるようにしたいのですが、今は少し難しいかもしれません) _。 デフォルトのレンズはインスペクター(#316を参照)であるため、ドキュメントだけで何かがレンダリングされ、そこから別のレンズを使用するか、作成するかを選択できます。
このようなものを使用すると、頻繁に使用するツールを簡単に再作成できることに注意してくださいhttps://hackmd.io/マークダウンを入力するための「コードエディタ」コンポーネントと、プレビューを並べてレンダリングするための「パイプライン」コンポーネントを使用できます。または意味のあるものは何でも。
PS:私はまだこのアイデアについて考えていますが、フィードバックのために共有し、それを文書化しようとしています
cc @pfrazeeは、Beakerの「ファイルの表示」で行っていることと似ているようです。
これもWirelineがやろうとしていることと非常に似ていると思います。
私の頭の中で回転し続けるもう1つのことは、 data -> view
とdata -> data
について考えるとき、それはどういうわけか常に最初から2番目への飛躍です。 http://offlinefirst.org/camp/でのディスカッションの1つで、「レンダリングされたビュー」のデータブロック(プッシュピンのコンテキストではドキュメント)へのリンクと「ソースコード」へのリンクを添付するというアイデアがあったことを思い出します。それらのビューをレンダリングします。
data -> view
をdata -> data
に一般化すると、出力はたまたまhtml
ドキュメントになります(実際、そのようなドキュメントとして存続する価値があるかもしれません)。 そうすれば、画鋲はたまたまHTML
であるドキュメントと、 data inspector
ではないドキュメントをレンダリングすることができます。
既存のウィジェットの時点では、それらはNote : data -> html
、 Thread: data -> html
などと考えることができます...
HTMLの永続化と復元に関する主な問題は、イベントリスナーですが、これは、すべてのアプリケーションロジックをメインスレッドから削除しようとしたときに対処した問題でもあり、それに対処する方法についていくつかのアイデアがあると思います。
具体的には、メインスレッドソリューションで機能させるために、 ElmのJSONデコーダーライブラリに触発されたdecoder.flowライブラリを使用しました。デコーダーは、シリアル化してメインスレッドにロードし、使用できる宣言型パーサーコミバンターです。イベントから関連情報を抽出/エンコードし、プログラムが実行されているスレッドに返します。
この特定のユースケースでは、構成されたエンコーダーをレンダリングされたhtml出力と同じドキュメントに保存し、そのアドレス(おそらくコンテンツハッシュ)を使用してハッシュで参照できると考えています。
最も参考になるコメント
cc @pfrazeeは、Beakerの「ファイルの表示」で行っていることと似ているようです。