Feliz: v2 विचार पर आपकी राय?

इस तरह के समर्थन को जोड़ने से प्रकार का अनुमान बहुत अधिक अनुमेय हो जाएगा (मैं इसे बेकार भी कहूंगा) क्योंकि तब हमारे पास Attribute = Properties = ReactElement । मूल रूप से, सब कुछ एक ही प्रकार के रूप में स्वीकार किया जाएगा ...

इसके अलावा, इसे संभव बनाने के लिए, हमें "मैन्युअल रूप से" बच्चों से विशेषताओं को विभाजित करने के लिए रिएक्ट के शीर्ष पर एक अतिरिक्त परत जोड़ने की आवश्यकता होगी जो प्रदर्शन को प्रभावित करेगा क्योंकि हमारे पास हमेशा एक अतिरिक्त कदम की आवश्यकता होगी। यह सेप्रेशन बनाने के लिए आवश्यक जानकारी को संग्रहीत करने के लिए बंडल का आकार भी बढ़ाएगा।

व्यक्तिगत रूप से, मैं इस सुविधा के लिए नहीं हूं।

मुझे इस दृष्टिकोण के बारे में मिश्रित भावनाएं हैं, मुख्य रूप से रनटाइम ओवरहेड के कारण यह प्रतिपादन में जोड़ता है। इसके अलावा, मैं करने के विचार में रखना चाहती हैं एक ReactElement से अलग ReactAttribute । इसलिए व्यक्तिगत रूप से मैं वर्तमान एपीआई को बहुत अधिक पसंद करता हूं।

अपने अनुभव में, मैं उपयोगकर्ताओं से इस मुद्दे के बारे में बहुत कुछ सुनता हूं लेकिन _only_ एक वर्ग के नाम और बच्चों के साथ div के संदर्भ में। जिस पर मेरी सामान्य प्रतिक्रिया एक छोटा सहायक कार्य लिख ​​रहा है जो आपको ऐसा कुछ या इसी तरह लिखने देता है

div [ "myClass" ] [
  Html.div "nested"
]

मुझे लगता है कि आपके स्वयं के विस्तार विधियों को लिखने का कोई कारण नहीं है यदि वे कक्षाओं या अन्य अक्सर उपयोग की जाने वाली संपत्तियों को लागू करने के प्रभाव के अनुकूल हैं जैसा कि मैंने यहां सामग्री यूआई के साथ किया था। कंपाइलर को और भ्रमित किए बिना या प्रकार की सुरक्षा को कम किए बिना एफ # के साथ कंपोजिटिबिलिटी मृत आसान है।

[<AutoOpen>]
module MuiExtensions

open Feliz
open Feliz.MaterialUI

type Mui 
    with
    static member gridItem (children:seq<ReactElement>):ReactElement = 
        Mui.grid [
            grid.item true
            grid.children children
        ]

    static member gridItem (props:seq<IReactProperty>):ReactElement = 
        Mui.grid [
            grid.item true
            yield! props
        ]

सभी राय के लिए धन्यवाद, मैं सिर्फ प्रवाह पर चर्चा करना चाहता था। 👍 मेरे अपने सहायक भी हैं जैसे divClassed "myClass" [ children ] या तो, लेकिन दूसरे का दृष्टिकोण जानना चाहता था।

टाइप प्रतिबंध रखते हुए यह वास्तव में संभव होना चाहिए यदि हमने रिएक्ट तत्वों को एक सूची से अभिकलन अभिव्यक्तियों में बदल दिया है:

div {
    className "myClass"

    div { ... }
}

सीई कार्यान्वयन कोडबेस के आकार में वृद्धि करेगा, निश्चित रूप से इसे बनाए रखना कठिन बना देगा, और जब प्रोप परिभाषित किए जाते हैं तो प्राइमेटिव जैसी कुछ चीजों को संभालना थोड़ा मुश्किल होता है/विकास के दौरान संकलन पर विफल होना चाहिए जैसे कि यह अब करता है:

// Would probably need to make the base builder generic so we can use a type restriction and define this DU for
// each element so we can properly restrict what types are valid as primatives
type ReactBuilderChild =
    | Child of ReactElement
    | Children of ReactElement list
    | Float of float
    | Int of int
    | String of string
    | None

    member this.GetChildren () =
        match this with
        | ReactBuilderChild.Children children -> children
        | _ -> failwith "Cannot combine children with primitive values."

type ReactBuilderState =
    { Children: ReactElement list
      Props: IReactProperty list } 

[<AbstractClass;NoEquality;NoComparison>]
type ReactBuilder () =
    [<EditorBrowsable(EditorBrowsableState.Never)>]
    member _.Yield (x: ReactElement) = { Children = ReactBuilderChild.Child x; Props = [] }
    [<EditorBrowsable(EditorBrowsableState.Never)>]
    member _.Yield (x: ReactElement list) = { Children = ReactBuilderChild.Children x; Props = [] }
    [<EditorBrowsable(EditorBrowsableState.Never)>]
    member _.Yield (x: float) = { Children = ReactBuilderChild.Float x; Props = [] }
    ...
    [<EditorBrowsable(EditorBrowsableState.Never)>]
    member _.Yield (x: unit) = { Children = ReactBuilderChild.None; Props = [] }

    [<EditorBrowsable(EditorBrowsableState.Never)>]
    member _.Combine (state: ReactBuilderState, x: ReactBuilderState) = 
        { Children = (state.Children.GetChildren()) @ (x.Children.GetChildren()); Props = state.Props @ x.Props }

    [<EditorBrowsable(EditorBrowsableState.Never)>]
    member _.Zero () = { Children = ReactBuilderChild.None; Props = [] }

    [<EditorBrowsable(EditorBrowsableState.Never)>]
    member this.For (state: ReactBuilderState, f: unit -> ReactBuilderState) = this.Combine(state, f())

    [<CustomOperation("className")>]
    member _.className (state: ReactBuilderState, value: string) =
        { state with Props = (Interop.mkAttr "className" value)::state.Props }

    [<CustomOperation("children")>]
    member _.children (state: ReactBuilderState, value: ReactElement list) =
        { state with Children = state.Children @ value }

    abstract Run : ReactBuilderState -> ReactElement

[<NoEquality;NoComparison>]
type DivBuilder () =
    inherit ReactBuilder()

    [<EditorBrowsable(EditorBrowsableState.Never)>]
    member _.Run (state: ReactBuilderState) = 
        match state with
        | { Children = ReactBuilderChild.None; Props = props } -> Interop.createElement "div" props
        | { Children = ReactBuilderChild.Children children } -> Interop.reactElementWithChildren "div" children
        | { Children = ReactBuilderChild.Float f } -> Interop.reactElementWithChild "div" f
        | _ -> ...

let div = DivBuilder()

मैं जिस चीज के बारे में अनिश्चित हूं, वह यह है कि फैबल को किसी भी/सभी सीई प्लंबिंग को ठीक से कैसे संकलित किया जाए, साथ ही संचालन को खोजने योग्य बनाया जाए (जैसे कि यह वर्तमान में prop प्रकार के साथ है)।

चर्चा के विषय को इंगित करने के लिए शीर्षक बदलने की याचिका? मैं

@Dzoukr इस पर पिछली चर्चा हो चुकी है - मैं निश्चित रूप से आपके पक्ष में हूं।

हेल्पर फ़ंक्शंस आदर्श नहीं हैं क्योंकि वे अजीब डबल लिस्ट सिंटैक्स को वापस लाते हैं, मूल रूप से इस लिब के प्रमुख लाभों में से एक को पहले स्थान पर समाप्त कर देते हैं, और वे वास्तविक प्रोप उपयोग में मदद नहीं करते हैं जो कि सिर्फ डिव + क्लास से कहीं अधिक है।

@ ज़ैद-अजाज क्या आप इस क्षेत्र का पता लगाने के लिए वैकल्पिक नामस्थान के लिए खुले रहेंगे? फेलिज की तरह।प्रायोगिक या कुछ और? तो मुख्य फ़ेलिज़ नेमस्पेस प्रतिक्रिया पर पतली परत का लक्ष्य रखता है जबकि वैकल्पिक अधिक राय वाले दृष्टिकोण का प्रयास कर सकता है।

वैसे भी, मुझे प्रोप ग्रुपिंग बनाए रखने के लिए ऐसा कुछ पसंद है:

Html.div [
    props [
        prop.className "myClass"
    ]
    Html.div "Nested"
]

प्रोप नेस्टिंग एलिमेंट नेस्टिंग की तुलना में क्लीनर लगता है क्योंकि प्रॉप्स अनंत नेस्टिंग के अधीन नहीं हैं जिस तरह से तत्व हैं। props कंटेनर Html.* तत्वों के साथ एक इंटरफ़ेस साझा करेगा, दोनों को युक्त तत्व के मान्य बच्चों के रूप में मॉडलिंग करेगा।

प्रदर्शन पर नज़र रखने के लिए कुछ होगा लेकिन मुझे नहीं लगता कि प्रभाव को बिना कोशिश किए जाना जाता है। कौन जानता है, शायद अतिरिक्त काम केवल डरावना लगता है, लेकिन प्रस्तुत करने पर होने वाली हर चीज के सापेक्ष व्यवहार में महत्वहीन हो जाता है।

@zanaptak मुझे वह विचार काफी पसंद है क्योंकि जैसा कि आप कहते हैं, प्रॉप्स बच्चों की तरह गहराई से घोंसला नहीं बनाते हैं।

हेल्पर्स और डबल लिस्ट सिंटैक्स के विषय पर

वे वास्तविक प्रोप उपयोग में मदद नहीं करते हैं जो कि सिर्फ div+class . से कहीं अधिक है

let inline withProps elementFunction props (children: #seq<ReactElement>) =
    (prop.children (children :> ReactElement seq))
    :: props
    |> elementFunction

let myDiv = withProps Html.div

myDiv [ prop.className "myClass" ] [
    Html.div "Nested"
]

यदि आप चाहें तो आप किसी भी तत्व के साथ "डबल लिस्ट"-जैसे सिंटैक्स का उपयोग करने के लिए एक ऑपरेटर को परिभाषित कर सकते हैं:

let inline (@+) elementFunction props =
    fun children -> withProps elementFunction props children

let inline (@++) elementFunction prop =
    fun children -> withProps elementFunction [ prop ] children

Html.div @+ [ prop.className "myClass" ]
<| [ Html.div "nested" ]

Html.div @++ prop.className "myClass"
<| [ Html.div "nested" ]

यह एक मुश्किल विषय है क्योंकि जो "बेहतर दिखता है" वह व्यक्तिपरक हो सकता है। संभवतः सबसे महत्वपूर्ण बात यह है कि परिवर्तनों को तोड़ने से बचना है, लेकिन यदि आप केवल प्रयोग करना चाहते हैं तो आप इसके लिए Feliz.Engine का उपयोग कर सकते हैं, क्योंकि इसे प्रतिक्रिया के लिए अनुकूलित करना बहुत आसान है। जैसा कि अन्य मुद्दों में उल्लेख किया गया है, मैं Feliz.Engine.React को प्रकाशित नहीं करना चाहता क्योंकि यह दो समान "प्रतिस्पर्धी" पैकेजों को भ्रमित करने वाला होगा। लेकिन उदाहरण के लिए, यदि आप सब कुछ एक ही स्तर पर रखना चाहते हैं, तो आपको बस इस तरह के एक मॉड्यूल की आवश्यकता है (इसे एक अलग सूची में भी प्रॉप्स रखने के लिए अनुकूलित करना आसान होगा):

// Dependencies:
// - Fable.React
// - Feliz.Engine.Event dependencies

open Fable.Core
open Fable.Core.JsInterop
open Feliz
open Fable.React

type Node =
    | El of ReactElement
    | Style of string * string
    | Prop of string * obj
    member this.AsReactEl =
        match this with
        | El el -> el
        | _ -> failwith "not an element"

let private makeNode tag nodes =
    let props = obj()
    let style = obj()
    let children = ResizeArray()
    nodes |> Seq.iter (function
        | El el -> children.Add(el)
        | Style(k, v) -> style?(k) <- v
        | Prop(k, v) -> props?(k) <- v
    )
    if JS.Constructors.Object.keys(style).Count > 0 then
        props?style <- style
    ReactBindings.React.createElement(tag, props, children) |> El

let Html = HtmlEngine(makeNode, str >> El, fun () -> El nothing)

let Svg = SvgEngine(makeNode, str >> El, fun () -> El nothing)

let prop = AttrEngine((fun k v -> Prop(k, v)), (fun k v -> Prop(k, v)))

let style = CssEngine(fun k v -> Style(k, v))

let ev = EventEngine(fun k f -> Prop("on" + k.[0].ToString().ToUpper() + k.[1..], f))

परीक्षण:

let myEl = // Node
    Html.div [
        prop.className "myClass"
        Html.div "Nested"
    ]

let myElAsReactEl = myEl.AsReactEl // ReactElement 

हेल्पर फ़ंक्शंस आदर्श नहीं हैं क्योंकि वे अजीब डबल लिस्ट सिंटैक्स को वापस लाते हैं।

@zanaptak हेल्पर फ़ंक्शंस को इनपुट के रूप में दो सूचियाँ लेने की आवश्यकता नहीं है, div [ "class" ] [ ] एक सामान्य परिदृश्य का एक उदाहरण था जो दो सूचियों को लेने के लिए हुआ था। ये फ़ंक्शन ऐसे घटक भी हो सकते हैं जो आपके विचार को सरल बनाते हैं

Todo.List [ for item in items -> Todo.Item item ]

यद्यपि आप तकनीकी रूप से सूचियों को असीमित रूप से घोंसला बना सकते हैं, यह विचार नहीं है। आपके बड़े UI कोड में छोटे फ़ंक्शंस या घटकों का उपयोग करके वहाँ एक संतुलन है।

हालांकि, आदर्श रूप से आपको कोड को बार-बार तोड़ने की आवश्यकता नहीं होगी और एक फ़ंक्शन जितना हो सके उतना पठनीय होना चाहिए क्योंकि चीजों को व्यवस्थित करने के बारे में सोचने से कभी-कभी _flow_ दूर हो जाता है। Fable.React के DSL के साथ यही समस्या थी जहां आपको हर बार चीजों को प्रारूपित करने के तरीके के बारे में _थिंक_ करना पड़ता था। फ़ेलिज़ इसे children के नेस्टिंग के दो स्तरों की कीमत पर ठीक करता है।

सच कहूं तो मुझे नहीं पता कि चांदी की गोली क्या है। जैसे @alfonsogarciacaro ने कहा

यह एक पेचीदा विषय है क्योंकि जो "बेहतर दिखता है" वह व्यक्तिपरक हो सकता है

प्रयोगों के विषय पर:

क्या आप इस क्षेत्र को एक्सप्लोर करने के लिए किसी वैकल्पिक नाम स्थान के लिए तैयार होंगे? फेलिज की तरह।प्रायोगिक या कुछ और? तो मुख्य फ़ेलिज़ नेमस्पेस प्रतिक्रिया पर पतली परत का लक्ष्य रखता है जबकि वैकल्पिक अधिक राय वाले दृष्टिकोण का प्रयास कर सकता है।

इस समय, फ़ेलिज़ परियोजना में विभिन्न डीएसएल बनाए रखने की कोई योजना नहीं है। मैं ओएसएस समय/क्षमता पर बहुत सीमित हूं और वर्तमान दृष्टिकोण में सुधार के प्रयासों को निर्देशित करने की आशा करता हूं: दस्तावेज़ीकरण, नमूने और अधिक अच्छी तरह से परीक्षण पारिस्थितिकी तंत्र पुस्तकालय।

उस ने कहा, @alfonsogarciacaro द्वारा Feliz.Engine के साथ प्रयोग करने के लिए स्वतंत्र महसूस करें और DSL का उपयोग करें जो आपको बेहतर लगे।