Feliz: v2 아이디어에 대한 귀하의 의견은 무엇입니까?

이런 종류의 지원을 추가하면 유형 추론이 훨씬 더 관대해집니다(나는 쓸모없다고 말할 수도 있습니다). 그러면 Attribute = Properties = ReactElement 가 있기 때문입니다. 기본적으로 모든 것이 같은 유형으로 받아들여질 것입니다...

또한 이를 가능하게 하려면 항상 추가 단계가 필요하기 때문에 성능에 영향을 미칠 "수동으로" 자식의 속성을 분할하기 위해 React 위에 추가 레이어를 추가해야 합니다. 이것은 또한 분리를 만드는 데 필요한 정보를 저장하기 위해 번들 크기를 증가시킵니다.

개인적으로 나는 이 기능을 좋아하지 않습니다.

나는 주로 렌더링에 추가되는 런타임 오버헤드 때문에 이 접근 방식에 대해 엇갈린 감정을 가지고 있습니다. 또한 나는 생각을 유지하는 것을 선호 것 ReactElement 에서 별도의 ReactAttribute . 그래서 개인적으로 현재 API를 훨씬 더 선호합니다.

내 경험에 따르면 사용자로부터 이 문제에 대해 많이 들었지만 클래스 이름과 자식이 있는 div 컨텍스트에서만 _만_입니다. 내 일반적인 응답은 이와 유사한 것을 작성할 수 있는 작은 도우미 기능을 작성하는 것입니다.

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

여기에서 Material UI에서 했던 것처럼 클래스 또는 기타 자주 사용하는 속성을 적용하는 효과에 더 적합하다면 고유한 확장 메서드를 작성하지 않을 이유가 없는 것 같습니다. 컴파일러를 더 혼란스럽게 하거나 형식 안전성을 감소시키지 않으면서 F#을 사용하면 구성 가능성이 완전히 사라집니다.

[<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 ] 정도의 저만의 도우미가 있지만 다른 사람의 관점을 알고 싶었습니다.

이것은 React 요소를 목록에서 계산 표현식으로 변경한 경우 유형 제한을 유지하면서 실제로 가능해야 합니다.

div {
    className "myClass"

    div { ... }
}

CE 구현은 코드베이스의 크기를 늘리고 유지 관리를 더 어렵게 만들며 props가 정의될 ​​때 기본 요소와 같은 일부를 처리하는 것은 약간 까다롭습니다/지금처럼 개발 중이 아니라 컴파일 시 실패해야 합니다.

// 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()

내가 확신할 수 없는 것은 Fable이 CE 배관의 일부/전체를 올바르게 컴파일하고 작업을 검색 가능하게 만드는 방법입니다(현재 prop 유형인 것처럼).

토론 주제를 나타내기 위해 제목을 변경해 달라는 청원서? 😆

@Dzoukr 이에 대한 이전 토론이 있었습니다. 저는 확실히 당신 편입니다.

도우미 함수는 어색한 이중 목록 구문을 다시 가져와 기본적으로 이 lib의 주요 이점 중 하나를 제거하고 div+class 이상의 실제 prop 사용에 도움이 되지 않기 때문에 이상적이지 않습니다.

@Zaid-Ajaj 이 영역을 탐색하기 위해 대체 네임스페이스를 열어 주시겠습니까? Feliz.Experimental 같은거요? 따라서 기본 Feliz 네임스페이스는 React보다 얇은 레이어의 목표를 유지하는 반면 대체는 더 독단적인 접근을 시도할 수 있습니다.

어쨌든, 나는 소품 그룹화를 유지하기 위해 다음과 같은 것을 좋아합니다.

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

props 중첩은 요소가 있는 방식으로 무한 중첩이 적용되지 않기 때문에 prop 중첩이 요소 중첩보다 더 깔끔해 보입니다. 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 을 사용하면 됩니다.

// 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의 문제였습니다. 여기서 매번 형식을 지정하는 방법에 대해 _생각_해야 했습니다. Feliz는 children 의 두 수준 중첩을 희생하여 이 문제를 수정합니다.

솔직히 은총알이 뭔지 잘 모르겠습니다. @alfonsogarciacaro가 말했듯이

"더 좋아 보이는" 것이 주관적일 수 있기 때문에 이것은 까다로운 주제입니다.

실험 주제:

이 영역을 탐색하기 위해 대체 네임스페이스를 열어 주시겠습니까? Feliz.Experimental 같은거요? 따라서 기본 Feliz 네임스페이스는 React보다 얇은 레이어의 목표를 유지하는 반면 대체는 더 독단적인 접근을 시도할 수 있습니다.

현재로서는 Feliz 프로젝트에서 다른 DSL을 유지할 계획이 없습니다. 저는 OSS 시간/용량이 매우 제한되어 있으며 문서, 샘플 및 더 잘 테스트된 생태계 라이브러리와 같은 현재 접근 방식을 개선하기 위한 노력을 기울이고 싶습니다.

즉, @alfonsogarciacaro의 Feliz.Engine을 자유롭게 실험하고 자신에게 더 적합한 DSL을 사용하십시오.