Feliz: フェリスとの私の旅| Fable.ReactとFelizの比較

素晴らしい分析。

個人的には、ダブルリストのフォーマットが面倒なこともありますが、Fable.Reactコードを見ると、基になるhtmlの構造がよくわかります。 div [..、Html.div [....（など）ではありません。 それは大したことではありませんが、私の脳はFable.Reactをより簡単に解析できるようです。

@MangelMaximeを書いて

私が集めたものから、これの主なポイントは、主にライブラリの拡張方法に関する問題と、最適に行われなかった場合に発生する問題です。

Felizライブラリを作成すると、開発者の作業が大幅に増えることに間違いなく同意できますが、結果のAPIが非常に使いやすい場合は、努力する価値があると思います。

私はFelizに対してかなりの数の拡張機能を作成したので、これらの問題の多くを軽減する方法についていくつかの洞察を提供できると思います。

過負荷

Visual Studioを使用していますが、使用可能なオーバーロードを見つけるのに問題はありません。これは、ionide側で改善できるものでしょうか。

prop.text 、メンバーtoStringを必要とし、任意のタイプを受け入れる単一のインライン関数にすることができますか？

コールバック：

それ以外の：

[<Erase>]
type editor =
    /// <summary>Triggered when the Editor has been mounted</summary>
    static member inline editorDidMount (f : System.Func<Monaco.Editor.IStandaloneCodeEditor, Monaco.IExports, unit>) = Interop.mkAttr "editorDidMount" f

書く：

[<Erase>]
type editor =
    /// <summary>Triggered when the Editor has been mounted</summary>
    static member inline editorDidMount (f : Monaco.Editor.IStandaloneCodeEditor -> Monaco.IExports -> unit) = Interop.mkAttr "editorDidMount" (Func<_,_,_> f)

その後、クライアント側で期待するようにプロパティを呼び出すことができます。

無効なコードを書く

私のライブラリのいくつかで私が持っている範囲でこれを完全に適用する人を見たことがなく、 Html拡張するときに完全に適用できるとは限りません。 これを防ぐ方法は、定義したプロパティにインターフェイスタイプを追加することです。これは、私の最大のFelizライブラリFeliz.Plotly 、次の場合にコンパイラエラーが発生するように設定しています。無効なプロパティを使用してみてください。 唯一の欠点は、ライブラリ開発者にとってかなりの作業になることです。

[<AutoOpen;EditorBrowsable(EditorBrowsableState.Never)>]
module Types =
  type IPlotProperty = interface end
  type IModeBarButtonsProperty = interface end
  type IAaxisProperty = interface end
  type IAggregateProperty = interface end
  type IAggregationProperty = interface end
  type IAggregationsProperty = interface end
  type IAngularaxisProperty = interface end
  type IAnimationProperty = interface end
  type IAnnotationProperty = interface end
  type IAnnotationsProperty = interface end
  type IAreaProperty = interface end
  type IAspectratioProperty = interface end
  type IAxisProperty = interface end
  type IBarProperty = interface end
  type IBarpolarProperty = interface end
  type IBaxisProperty = interface end
  type IBorderProperty = interface end
  type IBoxProperty = interface end
  type IButtonProperty = interface end
  type ICameraProperty = interface end
  type ICandlestickProperty = interface end
  type ICapsProperty = interface end
  type ICarpetProperty = interface end
  type ICaxisProperty = interface end
  type ICellsProperty = interface end
  type ICenterProperty = interface end
  type IChoroplethProperty = interface end
  type IChoroplethmapboxProperty = interface end
  type ICircleProperty = interface end
  type IColoraxisProperty = interface end
  type IColorbarProperty = interface end
  type IColorscaleProperty = interface end
  type IColorscalesProperty = interface end
  type IConcentrationscalesProperty = interface end
  type IConeProperty = interface end
  type IConfigProperty = interface end
  type IConnectorProperty = interface end
  type IContourProperty = interface end
  type IContourcarpetProperty = interface end
  type IContoursProperty = interface end
  type ICumulativeProperty = interface end
  type ICurrentvalueProperty = interface end
  type IDecreasingProperty = interface end
  type IDeltaProperty = interface end
  type IDensitymapboxProperty = interface end
  type IDiagonalProperty = interface end
  type IDimensionProperty = interface end
  type IDimensionsProperty = interface end
  type IDomainProperty = interface end
  type IEditsProperty = interface end
  type IErrorXProperty = interface end
  type IErrorYProperty = interface end
  type IErrorZProperty = interface end
  type IEyeProperty = interface end
  type IFillProperty = interface end
  type IFilterProperty = interface end
  type IFontProperty = interface end
  type IFrameProperty = interface end
  type IFramesEntryProperty = interface end
  type IFramesProperty = interface end
  type IFunnelProperty = interface end
  type IFunnelareaProperty = interface end
  type IGaugeProperty = interface end
  type IGeoProperty = interface end
  type IGradientProperty = interface end
  type IGridProperty = interface end
  type IGroupbyProperty = interface end
  type IHeaderProperty = interface end
  type IHeatmapProperty = interface end
  type IHeatmapglProperty = interface end
  type IHistogram2dProperty = interface end
  type IHistogram2dcontourProperty = interface end
  type IHistogramProperty = interface end
  type IHoverlabelProperty = interface end
  type IImageProperty = interface end
  type IImagesProperty = interface end
  type IIncreasingProperty = interface end
  type IIndicatorProperty = interface end
  type IInsidetextfontProperty = interface end
  type IIsosurfaceProperty = interface end
  type ILabelfontProperty = interface end
  type ILataxisProperty = interface end
  type ILayerProperty = interface end
  type ILayersProperty = interface end
  type ILayoutProperty = interface end
  type ILeafProperty = interface end
  type ILegendProperty = interface end
  type ILightingProperty = interface end
  type ILightpositionProperty = interface end
  type ILineProperty = interface end
  type ILinkProperty = interface end
  type ILonaxisProperty = interface end
  type IMapboxProperty = interface end
  type IMarginProperty = interface end
  type IMarkerProperty = interface end
  type IMeanlineProperty = interface end
  type IMesh3dProperty = interface end
  type IModebarProperty = interface end
  type INodeProperty = interface end
  type INumberProperty = interface end
  type IOhlcProperty = interface end
  type IOutsidetextfontProperty = interface end
  type IPadProperty = interface end
  type IParcatsProperty = interface end
  type IParcoordsProperty = interface end
  type IPathbarProperty = interface end
  type IPieProperty = interface end
  type IPointcloudProperty = interface end
  type IPolarProperty = interface end
  type IProjectProperty = interface end
  type IProjectionProperty = interface end
  type IRadialaxisProperty = interface end
  type IRangebreakProperty = interface end
  type IRangebreaksProperty = interface end
  type IRangefontProperty = interface end
  type IRangeselectorProperty = interface end
  type IRangesliderProperty = interface end
  type IRotationProperty = interface end
  type ISankeyProperty = interface end
  type IScatter3dProperty = interface end
  type IScatterProperty = interface end
  type IScattercarpetProperty = interface end
  type IScattergeoProperty = interface end
  type IScatterglProperty = interface end
  type IScattermapboxProperty = interface end
  type IScatterpolarProperty = interface end
  type IScatterpolarglProperty = interface end
  type IScatterternaryProperty = interface end
  type ISceneProperty = interface end
  type ISelectedProperty = interface end
  type IShapeProperty = interface end
  type IShapesProperty = interface end
  type ISlicesProperty = interface end
  type ISliderProperty = interface end
  type ISlidersProperty = interface end
  type ISortProperty = interface end
  type ISpaceframeProperty = interface end
  type ISplomProperty = interface end
  type IStartsProperty = interface end
  type IStepProperty = interface end
  type IStepsProperty = interface end
  type IStreamProperty = interface end
  type IStreamtubeProperty = interface end
  type IStyleProperty = interface end
  type IStylesProperty = interface end
  type ISunburstProperty = interface end
  type ISurfaceProperty = interface end
  type ISymbolProperty = interface end
  type ITableProperty = interface end
  type ITernaryProperty = interface end
  type ITextfontProperty = interface end
  type IThresholdProperty = interface end
  type ITickfontProperty = interface end
  type ITickformatstopProperty = interface end
  type ITickformatstopsProperty = interface end
  type ITilingProperty = interface end
  type ITitleProperty = interface end
  type ITotalsProperty = interface end
  type ITracesProperty = interface end
  type ITransformsProperty = interface end
  type ITransitionProperty = interface end
  type ITreemapProperty = interface end
  type IUniformtextProperty = interface end
  type IUnselectedProperty = interface end
  type IUpProperty = interface end
  type IUpdatemenuProperty = interface end
  type IUpdatemenusProperty = interface end
  type IViolinProperty = interface end
  type IVolumeProperty = interface end
  type IWaterfallProperty = interface end
  type IXProperty = interface end
  type IXaxisProperty = interface end
  type IXbinsProperty = interface end
  type IYProperty = interface end
  type IYaxisProperty = interface end
  type IYbinsProperty = interface end
  type IZProperty = interface end
  type IZaxisProperty = interface end
  type IButtonsProperty = inherit IModeBarButtonsProperty
  type IMeasureProperty = interface end
  type ITemplateProperty = interface end

同様に、必要に応じて、ライブラリコードに実装して、プロパティを「自動的に」組み合わせることができます。 ただし、自分のライブラリ以外のものを使用する場合、これがどのように機能するかはわかりません。 これの秘訣は、これらのアイテムを単なるIReactPropertyは異なるタイプにすることです。 たとえば、 Feliz.Plotlyでは、指定された構成に応じて、ユーザー入力を変更/収集/変更して、実際のコードが必要なものに適切に変換する多くのことを行います。 常に存在するものを削除することは、いくつかの点で本当に素晴らしいです。

結論

あなたが抱えていた苦痛の多くは、「フェリス」の方法で独自のライブラリを作成する方法についてのより良いドキュメントで解決できると思います。 たぶん@ Zaid-Ajajと私は将来それに取り組むことができます。

ありがとう@ l3m

個人的には、ダブルリストのフォーマットが面倒なこともありますが、Fable.Reactコードを見ると、基になるhtmlの構造がよくわかります。 div [..、Html.div [....（など）ではありません。 それは大したことではありませんが、私の脳はFable.Reactをより簡単に解析できるようです。

実際、コードの読み取り方法を切り替えるのは簡単ではありません。そのため、私の場合はHTMLとして表示すべきではないと述べたので、切り替えに役立ちました。

F＃5と「静的クラスを開く」機能により、Felizは、Htmlクラスを開くかどうかに応じて、 Html.divとdiv両方の構文をサポートできるようになると思います。

コメントをありがとう@Shmew 、そして確かに私はフェリスのための「ライブラリ」のいくつかのタイプがあることを忘れました。

「無効なコードの書き込み」についてはい。ただし、一部のライブラリでは、 Propsなどの特別なヘルパーを介して標準プロパティを渡す必要があるFulmaの状況を回避するために、 IReactPropertyタイプを「拡張」する必要があります。 Props 。 その理由は、Bulmaの「コンポーネント」はDOM要素の単なる特殊化であるためです。

これらは、HTML要素にデフォルトでクラスを挿入する単なるコードです。

Bulma.buttonは<div class="button">

「実際の」コンポーネントで動作するライブラリの場合（申し訳ありませんが、別の名前を付ける方法がわかりません）、ソリューションは確かに正しいものです。 たとえば、これはFable.ReactLeafletが採用したアプローチであり、各コンポーネントの特定のプロパティを定義しています。 したがって、コンポーネントはすべての標準HTMLプロパティをサポートする必要はありません。

「コールバック」の解決策については、私にはうまくいきませんでした。 しかし、Fableによって渡された関数にはカレー引数があり、 myFunction(arg1)(arg2)ようなものを書きたくない限り、 System.Func介してカレーなしのバージョンを強制する必要がありました。

それを機能させる方法を知っているなら、 https：//github.com/fable-compiler/repl/pull/108/filesでそれを修正するためにPRが送られるのを見てうれしいです

こんにちは@MangelMaxime 、

まず第一に、プロジェクトでフェリスを試すだけでなく、そのような広範な分析を書くために時間と労力を費やしてくれてありがとう。 寓話のユーザーの多くは、それが非常に有益で有益であると感じると確信しています。

この種のフィードバックとオープン性に本当に感謝しており、このライブラリをそのエコシステムとともに可能な限り最高のものにすることが重要であると信じています：pray：

Feliz.Bulmaはエコシステムの中で特別なものだと思うので、すぐに話します。まず、ライブラリを変更せずにすでに修正できるいくつかの問題に答えます。

onChange過負荷

どのイベントタイプが必要かを明示的に指定する必要があります。

実際には、あなたはしません。 タイプは、メッセージタイプから次のように推測する必要があります。

prop.onChange (ChangeGistToken >> dispatch)

ChangeGistTokenのタイプに応じて、正しい過負荷が推測されます。 DUの場合がChangeGistToken of string場合、 string -> unitのオーバーロードが選択されます。 ただし、入力タイプがfile場合はFileSelected of Fileになることもあります。その場合、オーバーロードFile -> unitが推測されます。 Fable.Reactからev.Valueのシンタックスシュガーは必要ありません

onChangeはすでにブールケースを処理しているため、prop.onCheckedChangeは削除されます

マルチ引数コールバック

@Shmewはすでにこの問題に触れており、実際、これがこれらのタイプのプロパティを解決する方法です。 Feliz拡張機能を実装する場合、プロパティを設定する前に変換を実行できることを理解することが重要です。

type myExtension = 
    static member inline extenstionProperty value = 
        // transform value here
        let transformedValue = doWeirdStuffWith value
        Interop.mkAttr "extenstionProperty" transformedValue

このロジックに従って、 'A -> 'B -> unitを内部でFunc<'A, 'B, unit>変換できます。

[<Erase>]
type editor =
    /// <summary>Triggered when the Editor has been mounted</summary>
    static member inline editorDidMount (f : Monaco.Editor.IStandaloneCodeEditor -> Monaco.IExports -> unit) = 
        let transformedFunction = System.Func<Monaco.Editor.IStandaloneCodeEditor, Monaco.IExports, unit>(fun editor exported -> f editor exported)
        Interop.mkAttr "editorDidMount" transformedFunction

これは、 @ Shmewによって提供されるバージョンよりも明示的なバージョン正しく設定するには、常に少し遊んでおく必要があります）。 これの実用的な例はここにあり

フェリスエコシステムにおける型安全性

@Shmewが前述したように、適切なFeliz拡張機能では、正しく動作しないコードを記述できず、プロパティのタイプを制約することでそれを実装できます。 Feliz.RechartsのようにIReactPropertyを返すプロパティを構築して、 prop既存のプロパティとの下位互換性を確保するか、より特殊なタイプISpecialiedPropertyを実装してサポートすることができます。下位互換性を確保するために、一部のプロパティの名前をIReactPropertyから複製している間は、プロパティのサブセットのみを使用します。

type felizExtension = 
    static member inline specializedProp (value: string) : ISpecializedProperty = unbox (prop.text value) 

これは私がFeliz.AntDesignで行っていることです。たとえば、ここではいくつかのプロパティを複製してbuttonエントリポイントから利用できるようにしています（後で、プロパティを厳密な型でより特殊化することもできますが、最初は、下位互換性は最初に開始する場所です）。 Feliz.MaterialUIは、プロパティを特殊化するのではなく、 IReactPropertyを拡張するために同様のことを行うと思います。 これはFeliz.Bulmaの場合になります。

Feliz.Bulmaの場合

Feliz.Bulmaが実装される前は、CSSのみのフレームワーク用にFeliz拡張機能を構築する必要はyieldを使用すると、さらに簡単になります。 これをTypedCssClassesと組み合わせると、CSSのみのフレームワークを実装する必要がなくなります。 実装とメンテナンスのコストはゼロです。 ドキュメントのWebサイトを自分で作成する代わりに、入力したスタイルシートを使用して、プロジェクト自体のすでに非常に優れたドキュメントを使用するだけです。

ただし、@ DzoukrによるFeliz.Bulmaの実装を見た後は、理に。Bulmaの1つのモジュールからCSSコンポーネントに特定の「エントリポイント」を導入して、 Bulma.buttonを取得することで、コードを大幅に簡素化できます。 Bulma.cardなど。これらは本当に使いやすいです。 モディファイアに関しては、Romanのアプローチは従い、操作しやすいと思いますが、あなたが言ったように、時にはそれが興味深い結果をもたらす可能性があります。 確かに、その部門にはさらに改善すべき点があります。いずれにせよ、Romanは、Felizのビジョンに従って、習得と使用が簡単なものを構築するのに素晴らしい仕事をしたと思います。

フェリスのパッケージ管理

現在のFable.ReactとFeliz大きな違い、つまりパッケージのバージョン管理と管理について指摘したいと思います。 FelizバージョンはすべてのエコシステムライブラリがFemto互換であるため、必要なnpmパッケージを手動でインストールしたり、互換性のあるバージョンを知ったりする必要がなくなります。 これは、すべてではないにしても多くの派生Fable.Reactライブラリや、そうでない場合はFable.React自体とは異なります。

今後の計画

• Felizスタイルの拡張機能を構築する方法と何に従うべきかについての（さらに多くの）ドキュメントを書く。
• Feliz自体のために、しかしおそらくそのエコシステムのためにFelizアナライザーを構築する

実際には、あなたはしません。 タイプは、メッセージタイプから次のように推測する必要があります。

prop.onChange (ChangeGistToken >> dispatch)

確かに、私はこの使用法について考えていませんでした。

マルチ引数コールバック

@Shmewはすでにこの問題に触れており、実際、これがこれらのタイプのプロパティを解決する方法です。

申し訳ありませんが、@ Shmewによって提供されたスニペットの終わりが表示されませんでした。 私は署名宣言を見たばかりで、機能しないようでした。

あなたは両方とも正しいです、私たちは値をプロパティに渡す前に変換を行うことができます。

Feliz.Bulmaの場合

はい、TypedCssClassesは問題ありませんが、FulmaやFeliz.Bulmaと比較すると、同じレベルの機能を提供することはできません。 すべてがCSSファイルに含まれているわけではないからです。

もう1つは、開発モードでは、ファイルが常にディスク上に生成されるとは限らず、TypedCssClassesがこのシナリオをサポートしているかどうかがわかりません。

ローマンは、フェリスのビジョンに従って、学びやすく使いやすいものを構築するのに素晴らしい仕事をしたと思います。

私は同意します。同様にするために、Fulmaで行われた作業を少し追加する必要があると思います。 私が言ったように、私たちはそれらの両方の間の正しい中間点を見つける必要があります。

私が今考えている不足している機能は、出力要素を制御し、サポートされている色のセットを簡単に拡張できるようにすることです。 それほど複雑になるとは思いません。

@ Zaid-Ajajはフィードバックをありがとう、特にFelizの可能性を使用する方法について正しい方向を示してくれてありがとう。
私はFelizのドキュメントを実際に読んでいないことを認めます（それは私が知っているのは悪いことです）ので、おそらくそれらはそこに文書化されています。 そうでない場合は、追加する必要があることがいくつかわかっていると思います:)

@MangelMaximeに感謝しFantomasについて言及したことはありませんが、Fable.ReactまたはFelizのいずれかを使用してFantomasを操作する機会はありましたか？
Fantomasを使用しているFableプロジェクトの1つで、Ionideのファイル保存で自動フォーマットをオンにしました。これは、生産性を大幅に向上させるものであると言わなければなりません。手動フォーマットについて心配する必要はまったくありません。
Fantomasは今勢いを増しており、FableやReact / Felizと組み合わせて、より広く採用されることを望んでいます。

@theimowski私は

主な理由は、コードが混乱していて、読みづらくなったためです。 私の経験から、Fable.ReactとFelizでうまく遊んでいませんでした。

また、デフォルトのFantomasが気に入らないので、コードをインデントする方法がわかったら、後でもう一度確認する必要があります。 しかし、私がリポジトリを見たところ、コンテキストのサイズに応じてコードをフォーマットするFantomasが主な理由で、私のニーズに合うとは思いません。

たとえば、私がそのようなものを書いた場合：

type Test =
    {
        Prop1 : string
    }

1行に収まるからといって、そのままにしてtype Test = { Prop1 : string }ならないようにしたいと思います。

おそらくレコードは良い例ではありませんが、私が何を意味するのか理解していただければ幸いです:)

@theimowski聞いて

@MangelMaximeあなたの仕事に感謝します。 どういうわけかあなたのフルマプロジェクトは私を寓話の世界に攻撃しました。 そして、私は本当に旅を楽しんでいます。

私は単一のリストも好きですが、クラスのメンバーのオーバーライドよりもDUも好きです。 DUがオーバーライドをサポートしているかどうか疑問に思うことがあります。
私はすでにFable.Reactをたくさん使用していますが、それでも単一のリストが必要なので、演算子>を作成し、次のように使用できます。

let myView =
    div </> [
        Classes [ ""; ""; "" ]
        Children [
              ...
        ]
    ]

演算子は非常にシンプルで、DUも利用できます。ここで、私の大まかな実装を確認できます： //github.com/albertwoo/Fun.LightForm/blob/master/src/Fun.LightForm.Fable/Fable.React。 Extra.fs

@ Zaid-Ajajすばらしい仕事をありがとう、私もいくつかのプロジェクトをFelizとFeliz.Materialに変換し始めました。

ありがとう！

こんにちは@MangelMaxime 、
まずはありがとうございます！ 率直に言って、私が主にドッグフーディング自身のプロジェクトのために作成し、副作用として公開したライブラリを誰かがこれほど深く見るとは思っていませんでした。 「ねえ、@ Zaid-AjajがFelizをどのように設計したか、ブルマについても同じことをしよう」という最初の考えが膨らんだのはおかしい。

私はすでにFeliz.Bulmaリポジトリで新しい問題を作成しており、v2をさらに改善する方法について話し合うのが大好きです。 ほとんどの問題について合意しているようですので、 version2ブランチを開始しても問題はありません。 また、次のメジャーリリースのZaidの計画を確認すると、最新のメジャーバージョン間でAPIを100％互換性を保つのに便利です。

とにかく、もう一度ありがとう-素晴らしい分析！

リスクのある古い議論を再開される（！申し訳ありません）私はインデントの議論に私の2セントを追加したい-これは（多かれ少なかれ）である私たちが素敵な、一貫性のインデントを許容んどの従っスタイリングとFable.Reactのために、以下のスタイル。

ただし、これが完全に当てはまらない1つの場所は、重要なスタイリングです。 しかし、私たちの経験では、これはごく少数の要素（おそらく10〜20％）しか占めていません。

div [ ] [
    Hero.hero [ Hero.IsFullHeight ] [
        Hero.body [ ] [
            Container.container [ ] [
                img [ Src "img/fable-ionide.png"
                      Style [ Display DisplayOptions.Block
                              Width "auto"
                              Margin "auto" ]
                    ]
                br [ ]
                Heading.h3 [ Heading.Modifiers [ Modifier.TextAlignment (Screen.All, TextAlignment.Centered) ] ] [
                    str "Fable REPL"
                ]
                Heading.p [ Heading.IsSubtitle
                            Heading.Is5
                            Heading.Modifiers [ Modifier.TextAlignment (Screen.All, TextAlignment.Centered) ] ] [
                    str "is only available on desktop"
                ]
            ]
        ]
    ]
]

また、VSCodeやRainbowBracketsなどを使用している場合は、ブラケットの過負荷を回避するのに役立ちます。

他に考慮すべきこと（おそらく私は上記でこれを見逃した）は、GiraffeViewEngineがFable.Reactスタイル、つまり要素attr-list children-listを使用していることです。したがって、2つの間を移行する人々の観点から考える必要があります。

@ Zaid-AjajはFemtoについて良い点を述べています。 これをFable.Reactスタイルのコンポーネントで実装できなかった理由はありますか、それともFemtoが結合されているFelizスタイルに固有の何かがありますか？

これをFable.Reactスタイルのコンポーネントで実装できなかった理由はありますか、それともFemtoが結合されているFelizスタイルに固有の何かがありますか？

@isaacabraham

Fable.Reactから派生したライブラリは、Femtoメタデータを追加できます（また、追加する必要があります）が、Fable.React自体は、 react 、 react-dom 、およびreact-native互換性のない組み合わせがあるため、追加できません@MangelMaximeはパッケージの分割に関するいくつかの重大な変更が導入されるでしょう。

Fable.Reactから派生したライブラリにとってこれが意味することは、依存関係のnpmメタデータだけでなく、互換性のあるバージョンのreactとreact-domも含める必要があるということです。 （ reactとreact-domで始まるFelizとは異なり、Feliz拡張機能は必要なものだけを追加します）。 残念ながら、解決策がかなり前から存在しているとしても、これらのライブラリのいずれかが状況を改善するために主導権を握っているのを見たことがありません。

フォーマットについて：FantomasはまだDSLを適切な方法でフォーマットすることができず、リストのフォーマットを構成可能にするための作業が必要であるか、ReactDSLを適切なデフォルトを使用してフォーマットするための何らかの「Feliz-mode」フラグが必要です（と）

@ Zaid-Ajaj React npmの依存関係の問題も、Femtoを壊すことなく、reactの代わりにpreactを使用できるはずなので、より複雑です。

@ l3m確かに、しかしこの場合、このケースをサポートするためにFemtoに追加することができます。 それは私に何かを覚えているので、おそらくフェムトレポでそれについて問題があります（申し訳ありませんが今チェックする時間がありません^^）

@ l3m Preactは、Femto npmメタデータに関係なく、Reactの代わりに使用できます。既存のReactアプリケーションがある場合は、 Preactへの切り替えのガイドラインに従ってモジュールインポートエイリアスを構成するだけでよいためです。

純粋なPreactバインディング（100％非Reactコード）の構築はFelizの目標ではなく、おそらくPreactのみのバインディングが拡張されるスタンドアロンライブラリ（Feliz.PreactはFelizに依存しない）として実装する必要があります。 preact/compatから離れたい場合に使用します

@ Zaid-Ajaj現在、Elmishアプリでpreactを使用していますが、うまく機能します。 Femtoがpackages.jsonを変更するのを警戒していたのですが、React depsのあるnugetが表示された場合は、それを強調したいと思いました。 それが問題でなければ、なおさらです。

また、 preact/compatは、最新のpreactでは不要になり、コアになりました。

危険にさらされているのは、古い議論を再開することです（申し訳ありません！）インデントの議論に2セントを追加したかっただけです-これは（多かれ少なかれ）私たちが従うスタイリングであり、Fable.Reactの素晴らしい一貫した識別とフォローを可能にしますスタイル。

私はIsaacと非常によく似た方法でコードをインデントしており、かなり読みやすくなっています。
物事を行う単一のリストの方法と比較するのは難しいことを私は知っていますが、元の投稿のインデントは、よりよく比較するために彼のコードに似たものを反映している可能性があります。

F＃5と「静的クラスを開く」機能により、Felizは、Htmlクラスを開くかどうかに応じて、 Html.divとdiv両方の構文をサポートできるようになると思います。

それはとてもクールだろう。 Htmlクラスを静的にして開くことができるようにすることは可能でしょうか？

@ fc1943s Html 、 prop 、およびstyleはすべて静的クラスです。 ただし、F＃5で機能が利用可能になったときにそれらを開くことはお勧めしません。これは、ポイント全体に、その静的クラス内で利用可能な関数へのグループ化と検出のエントリポイントがあるためです。

静的クラスを開くと、検出がどのように妨げられますか？ それでもFeliz.Htmlと入力できます。

@MaxWilsonMS 「最終的な」コードを出力するには、追加の手順が必要でした。

そして、 Feliz.Html.divを書き込んでから、奇妙に思えるFeliz.Html.部分を消去します。

良い点は、ユーザーが好みに応じて静的クラスを開くかどうかを選択できることです。 :)

上で述べたことを繰り返しているので、これがどれほど役立つかはわかりませんが、完全な初心者としての経験：

• インデントにはFelizアプローチが好きです。 Isaacが提案したのと同様のアプローチを試しましたが、インデントがすべて2s / 4sであるとは限らないため、「私は時々それについて考えることに時間を費やします」。 フェリスと一緒に、私はそれについて考えるのに全く時間を費やしません。

• カスタム要素を作成する場合は、今のところFable.Reactの方法で作成します。 私は「フェリスの方法」で物事を構築することを検討し、すぐに逃げました（いつか再訪します！）。

• ドキュメントが「これがカスタムプロパティを作成する方法です」という側面をより定期的に優先する場合、私は本当に便利だと思います。 ほんの数人の作者だけで、これらのライブラリはCSSで可能なすべてのAPIサーフェスを提供するのに苦労することがよくあることを受け入れるのは公正だと思います（たとえば）。したがって、初心者が「fontSize」を設定できないときに行き詰まった場合「em」にあるか、「grid-template-rows」が見つからないか、「Screen.All」引数を提供することが期待されているかどうかわからない-回避方法を知っていればよいでしょう。

• いくつかの潜在的な懸念を削ぎ落とし始めるいくつかの「生活の質」の改善が行われる可能性があると思います...たとえば、フェリスのスタイル小道具の長い垂直リストを見ると、 style.paddingHorizontalがあるかどうか疑問に思い始めますstyle.paddingVertical 。 私は自分でヘルパーを作ることができることを理解していますが、ここは機能をリクエストする場所ではなく、標準ではないものを導入することを避けたいと思うかもしれません:)

• 新しいF＃でHtml静的クラスを開くというアイデアが好きです。 批判的に-私の同僚は私の肩越しにそれを理解することができるでしょう-そして私はより多くの人々を巻き込むことが重要だと思います。 悪魔の代弁者を演じるには： divは入力に時間がかからず、それを発見する必要がある場合、これは魔法を実行しているセットアップを使用するときに私が直面するであろう課題の中で最も少ないものです。 Javascript、React、CSSなどを私から隠します。 ただし、一般的に、APIの検出可能性は優れています。

• 特にスタイルのトランジション/アニメーションの場合、Felizの方法は非常に理にかなっています。

• より一般的でおそらく接線的：私が一貫して直面している課題は、エルミッシュの世界がどこで終わり、Reactの世界がどこから始まるのかを理解することです。 これはどちらのライブラリの問題でもありませんが、Reactについて最も曖昧な手がかりがないため、Fable.ReactまたはFelizから関数コンポーネントを取得できるという事実は私を混乱させます。 もちろん、これを学ぶことは私の責任ですが、言及する価値があると思いました。 私は現在、ElmishとReactのアプローチを組み合わせており、これによりすべてのコンポーネントが更新時に再レンダリングされると思いますが、このような完全に構築されたアプリの例は次のとおりであるため、これを回避するための「正しい」方法がわかりません。見つけにくい。 最初にJavascriptでプロダクショングレードのReactアプリを作成し、次にFable / Elmishに移行することを学ぶ必要があるという印象を受けることがありますが、それは参入障壁のかなり重要なように感じます。 免責事項：私はFelizのドキュメントをあまり読んでいませんが、それは本当に良いことです-ですから、これはおそらく私にあります！

これらのライブラリを共有してくれたすべての人に感謝します！

ご入力いただきありがとうございます@ drk-mtr！

カスタム要素を作成する場合は、今のところFable.Reactの方法で作成します。 私は「フェリスの方法」で物事を構築することを検討し、すぐに逃げました（いつか再訪します！）。

ええ、最初はかなり気が遠くなるように見えるかもしれませんが、慣れればかなり簡単です。 そうは言っても、ライブラリを作成するときの開発者にとってはかなりの初期費用です。 大多数のユーザーがライブラリを作成することはないので、これはかなり許容できるトレードオフだと思います。 幸いなことに、作業自体は非常に単純であり、コピーと貼り付けを行うと、多くの作業を高速化できます（または、私たちのように、コードをビルドするためのジェネレーターを作成することもできます）。

ドキュメントが「これがカスタムプロパティを作成する方法です」という側面をより定期的に優先する場合、私は本当に便利だと思います。 ほんの数人の作者だけで、これらのライブラリはCSSで可能なすべてのAPIサーフェスを提供するのに苦労することがよくあることを受け入れるのは公正だと思います（たとえば）。したがって、初心者が「fontSize」を設定できないときに行き詰まった場合「em」にあるか、「grid-template-rows」が見つからないか、「Screen.All」引数を提供することが期待されているかどうかわからない-回避方法を知っていればよいでしょう。

あなたが気付いていない場合に備えて（私はこの文脈からは完全にはわかりませんでした）：

prop styleタイプとcustomメソッドがあります。

ICssUnitを受け入れるものはすべて、次のように設定できます： style.fontSize (length.em 1)

ドキュメントの更新は簡単なはずです。

いくつかの潜在的な懸念を削ぎ落とし始めるいくつかの「生活の質」の改善が行われる可能性があると思います...たとえば、フェリスのスタイル小道具の長い垂直リストを見ると、style.paddingHorizo​​ntalとstyle.paddingVertical。 私は自分でヘルパーを作ることができることを理解していますが、ここは機能をリクエストする場所ではなく、標準ではないものを導入することを避けたいと思うかもしれません:)

私の本では、ユーザーエクスペリエンスを容易にするのに役立つものは何でも大歓迎です。 私はあなたが気づいたこれらの事柄のいずれかの問題/広報を見たいです！

より一般的でおそらく接線的：私が一貫して直面している課題は、エルミッシュの世界がどこで終わり、Reactの世界がどこから始まるのかを理解することです。 これはどちらのライブラリの問題でもありませんが、Reactについて最も曖昧な手がかりがないため、Fable.ReactまたはFelizから関数コンポーネントを取得できるという事実は私を混乱させます。 もちろん、これを学ぶことは私の責任ですが、言及する価値があると思いました。 私は現在、ElmishとReactのアプローチを組み合わせており、これによりすべてのコンポーネントが更新時に再レンダリングされると思いますが、このような完全に構築されたアプリの例は次のとおりであるため、これを回避するための「正しい」方法がわかりません。見つけにくい。 最初にJavascriptでプロダクショングレードのReactアプリを作成し、次にFable / Elmishに移行することを学ぶ必要があるという印象を受けることがありますが、それは参入障壁のかなり重要なように感じます。 免責事項：私はFelizのドキュメントをあまり読んでいませんが、それは本当に良いことです-ですから、これはおそらく私にあります！

寓話の世界（フェリス以前）での私の経験では、ほとんどの場合、すべてを通常の関数として記述していました（.fsごとに1つのコンポーネントのように）。 その結果、Reactシステムが提供する多くのメリットを失いました。 Felizから始めてから、Reactがどのように機能するかについてもっと深く掘り下げなければなりませんでした（良いことです）。 慣れてきたので、意識的に考えることすらありません。 レンダリングを行う私が作成するすべての関数は、関数コンポーネントです。

Reactを慣用的に書く方法を本当に学びたいのなら、Elmishを使用せず、デモアプリで関数コンポーネント/フックのみを使用するように制限するのと同じくらい簡単だと思います。 APIはほぼ同じであるため、JSで記述されたものを簡単にフォローできます。

Felizで書かれた高品質のオープンソースアプリケーションを持つことは間違いなく有益なことです。私はしばらく前にその問題を作成しました＃67。 現在最も近いのは、おそらくドキュメントアプリ自体、または@cmeerenのElectronDemoです。