Feliz: Feliz와 나의 여행 | Fable.React와 Feliz의 비교

훌륭한 분석입니다.

개인적으로 이중 목록 형식이 때때로 고통스럽긴 하지만 Fable.React 코드를 보면 기본 html의 구조를 더 잘 볼 수 있다고 느낍니다. 그것은 div [.. , Html.div [.... (etc)가 아닙니다. 별거 아닌거 같지만 내 뇌는 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 에서는 주어진 구성에 따라 사용자 입력을 수정/수집/변경하여 실제 코드가 어떻게 생겼는지 적절하게 변환하는 많은 작업을 수행합니다. 항상 존재하는 것들을 제거하는 것은 어떤 면에서는 정말 좋습니다.

결론

"Feliz" 방식으로 자신의 라이브러리를 작성하는 방법에 대한 더 나은 문서로 당신이 겪었던 많은 고통을 해결할 수 있다고 생각합니다. 아마도 @Zaid-Ajaj와 나는 미래에 그 일을 할 수 있을 것입니다.

@l3m 감사합니다

개인적으로 이중 목록 형식이 때때로 고통스럽긴 하지만 Fable.React 코드를 보면 기본 html의 구조를 더 잘 볼 수 있다고 느낍니다. 그것은 div [.. , Html.div [.... (etc)가 아닙니다. 별거 아닌거 같지만 내 뇌는 Fable.React를 더 쉽게 파싱하는 것 같다.

실제로 코드를 읽는 방법을 전환하는 것은 쉬운 일이 아닙니다. 그래서 제 경우에는 코드를 HTML로 보지 않아야 한다고 언급한 것이 전환하는 데 도움이 되었습니다.

F# 5와 "정적 클래스 열기" 기능을 사용하면 Feliz가 Html 클래스를 여는지 여부에 따라 Html.div 및 div 구문을 모두 지원할 수 있다고 가정합니다.

의견을 주신 @Shmew 에게 감사드립니다. 실제로 Feliz에 여러 유형의 "라이브러리"가 있다는 사실을 잊어버렸습니다.

"잘못된 코드 작성"에 대해 예, 하지만 일부 라이브러리에서는 Props 와 같은 특수 도우미를 통해 표준 속성을 전달해야 하는 Fulma 상황을 피하기 위해 IReactProperty 유형을 "확장"하려고 합니다. Props . 그 이유는 Bulma "구성 요소"가 DOM 요소에 대한 전문화에 불과하기 때문입니다.

HTML 요소에 기본적으로 클래스를 삽입하는 코드일 뿐입니다.

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

"실제" 구성 요소에서 작동하는 라이브러리의 경우(죄송하지만 이름을 다르게 지정하는 방법을 모릅니다) 귀하의 솔루션은 실제로 올바른 것입니다. 예를 들어 Fable.ReactLeaflet 에서 각 구성 요소의 특정 속성을 정의하는 방식입니다. 따라서 구성 요소는 모든 표준 HTML 속성을 지원할 필요가 없습니다.

"콜백"에 대한 귀하의 솔루션에 대해서는 저에게 효과가 없었습니다. 그러나 Fable이 전달한 함수에는 카레 인수가 있었고 myFunction(arg1)(arg2) 와 같은 것을 작성하고 싶지 않다면 System.Func 를 통해 uncurried 버전을 강제 실행해야 했습니다.

작동하게 만드는 방법을 안다면 https://github.com/fable-compiler/repl/pull/108/files 에서 수정하기 위해 PR을 보내드리겠습니다.

안녕하세요 @MangelMaxime 입니다 .

우선, 프로젝트에서 Feliz를 시도하는 것뿐만 아니라 광범위한 분석을 작성하기 위해 시간과 노력을 들인 것에 대해 감사드립니다. 많은 Fable 사용자가 매우 유용하고 유익하다는 것을 알게 될 것이라고 확신합니다.

저는 이러한 종류의 피드백과 개방성에 정말 감사하며 이 라이브러리를 생태계와 함께 할 수 있는 최상의 상태로 만드는 것이 중요하다고 믿습니다.

생태계에서 일종의 특별하다고 생각하기 때문에 Feliz.Bulma에 대해 잠시 이야기하겠습니다. 먼저 라이브러리를 변경하지 않고도 이미 고칠 수 있는 몇 가지 문제에 대해 답변하겠습니다.

onChange 과부하

명시적으로 원하는 이벤트 유형을 말해야 합니다.

사실, 당신은하지 않습니다. 유형은 다음과 같이 메시지 유형에서 유추되어야 합니다.

prop.onChange (ChangeGistToken >> dispatch)

ChangeGistToken 의 유형에 따라 올바른 오버로드가 유추됩니다. DU 케이스가 ChangeGistToken of string 이면 string -> unit 의 과부하가 선택됩니다. 그러나 입력 유형이 file 인 경우 FileSelected of File 수도 있습니다. 이 경우 과부하 File -> unit 가 유추되는 식입니다. ev.Value 에서 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에서 제공하는 것보다 더 명시적인 버전입니다(바인딩에 대해 알고 있듯이, 바인딩을 여기에 있습니다

Feliz 생태계의 유형 안전

위에서 언급한 @Shmew : 적절한 Feliz 확장은 잘못 동작하는 코드를 작성하는 것을 허용하지 않으며 속성 유형을 제한하면 이를 구현할 수 있습니다. Feliz.Recharts처럼 prop 에 있는 기존 속성과의 역호환성을 허용하는 IReactProperty 를 반환하는 속성을 빌드하거나 지원하기 위해 보다 전문화된 유형 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 전용 프레임워크를 구현할 필요가 없습니다. 구현 및 유지 관리 비용이 없습니다. 직접 문서 웹사이트를 구축할 필요 없이 타이핑된 스타일시트를 사용하고 프로젝트 자체에 대한 이미 정말 좋은 문서를 사용하십시오.

그러나 @Dzoukr이 Feliz.Bulma를 구현한 것을 본 후에는 이해가 되었습니다. Bulma의 한 모듈에서 CSS 구성 요소에 특정 "진입점"을 도입하여 코드를 많이 단순화하여 Bulma.button 를 얻을 수 있었습니다 Bulma.card 등. 사용하기 정말 좋습니다. 수정자에 관해서는 Roman의 접근 방식이 따르기 쉽고 작업하기 쉽다고 생각하지만 말씀하신 것처럼 때로는 흥미로운 결과를 줄 수도 있습니다. 확실히 그 부서에서 더 개선해야 할 점이 있으며 어쨌든 Roman은 Feliz의 비전을 따라 배우고 사용하기 쉬운 것을 구축하는 데 큰 역할을 했다고 생각합니다.

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 파일에 모든 것이 포함되어 있지 않기 때문입니다.

또 다른 점은 개발 모드에서 디스크에 파일이 항상 생성되는 것은 아니며 TypedCssClasses가 이 시나리오를 지원하는지 확실하지 않다는 것입니다.

나는 Roman이 Feliz의 비전을 따라 배우기 쉽고 사용하기 쉬운 것을 만드는 데 큰 역할을 했다고 생각합니다.

동의합니다. Fulma에서 수행한 작업을 약간 추가하여 유사하게 만들 필요가 있다고 생각합니다. 내가 말했듯이 우리는 둘 사이의 올바른 중간 지점을 찾아야 합니다.

내가 지금 염두에 두고 있는 누락된 기능은 출력 요소를 제어하고 지원되는 색상 세트를 더 쉽게 확장할 수 있도록 하는 것입니다. 나는 그것이 그것에 많은 복잡성을 더할 것이라고 생각하지 않습니다.

@Zaid-Ajaj는 피드백과 특히 Feliz 잠재력을 사용하는 방법에 대한 올바른 방향을 알려주셔서 감사합니다.
나는 Feliz 문서를 실제로 읽지 않았음을 인정합니다. 그렇지 않은 경우 추가해야 할 몇 가지 사항을 더 알고 있는 것 같습니다. :)

감사합니다 @MangelMaxime - 훌륭한 비교입니다. 당신은 언급하지 않은 Fantomas에게 당신도 Fable.React 또는 펠리 즈와 Fantomas 작업 할 기회가 있었나요 - 아무 곳이나 코드의 서식을 자동 하시나요?
Fantomas를 사용하는 Fable 프로젝트 중 하나에서 Ionide에서 파일 저장 시 자동 포맷을 켰고 이것이 생산성 향상에 도움이 된다고 말해야 합니다. 수동 포맷에 대해 전혀 걱정할 필요가 없습니다!
Fantomas가 이제 추진력을 얻고 있다고 생각하며 Fable 및 React/Feliz와 함께 더 널리 채택되기를 원합니다.

@theimowski 나는

대부분 내 코드를 엉망으로 만들고 읽기가 정말 어렵기 때문입니다. 내 경험에 따르면 Fable.React 및 Feliz와 잘 작동하지 않았습니다.

또한 Fantomas의 기본값이 마음에 들지 않습니다. 나중에 내 코드를 들여쓰기하는 방법을 알게 되면 다시 확인해야 합니다. 그러나 repo를 살펴본 결과 Fantomas가 컨텍스트 크기에 따라 코드를 형식화하기 때문에 대부분 내 요구에 맞지 않을 것이라고 생각합니다.

예를 들어 다음과 같이 작성하면

type Test =
    {
        Prop1 : string
    }

한 줄에 들어갈 수 있다는 이유만으로 type Test = { Prop1 : string } 가 되지 않고 그대로 유지되기를 바랍니다.

기록이 좋은 예가 아닐 수도 있지만, 제 말의 의미를 이해해주셨으면 합니다. :)

@theimowski 반갑 습니다. 저는 Fable이 아닌 프로젝트에서 팬토마를 사용합니다. 한 번 더 해보고 어떻게 처리하는지 봐야겠네요.

@MangelMaxime 작업에 감사드립니다. 어쩐지 당신의 Fulma 프로젝트가 우화의 세계로 나를 공격했습니다. 그리고 나는 여행을 정말 즐긴다.

나는 또한 단일 목록을 좋아하지만 클래스 멤버 재정의보다 DU도 좋아합니다. 때로는 DU가 재정의를 지원하는지 궁금합니다. 그러면 정말 좋을 것입니다.
이미 Fable.React를 많이 사용하지만 여전히 단일 목록을 원하기 때문에 > 연산자를 만들고 다음과 같이 사용할 수 있습니다.

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

연산자는 매우 간단하고 DU도 활용 합니다. 여기에서 대략적인 구현을 확인할 수 있습니다.

@Zaid-Ajaj 훌륭한 작업에 감사드립니다. 또한 일부 프로젝트를 Feliz 및 Feliz.Material로 변환하기 시작했습니다.

감사 해요!

안녕하세요 @MangelMaxime 입니다 .
우선 감사합니다! 솔직히 나는 내가 주로 dogfooding 자신의 프로젝트를 위해 만들고 부작용으로 게시한 라이브러리를 누군가가 그렇게 깊이 들여다볼 것이라고 기대하지 않았습니다. "이봐, @Zaid-Ajaj가 Feliz를 디자인한 방법이 훌륭합니다. Bulma도 똑같이 합시다"라는 생각이 부풀어 오른 것이 웃기네요.

저는 이미 Feliz.Bulma repo에 새로운 Issue를 만들었으며 v2를 더 좋게 만드는 방법에 대해 토론하는 것을 좋아합니다. 대부분의 문제에 대해 합의가 된 것 같으니 version2 분기를 시작하는 데 문제가 없을 것입니다. 또한 다음 주요 릴리스에 대한 Zaid의 계획을 살펴보는 것은 최신 주요 버전 간에 API를 100% 호환되도록 유지하는 데 유용할 수 있습니다.

어쨌든, 다시 한 번 감사드립니다-훌륭한 분석!

위험에서 이전 논의를 재개한다 (!) 미안 난 그냥 들여 쓰기 논쟁에 내 두 센트를 추가하고 싶었 -이 (다소)는 우리가 좋은 일관된 identation을 허용 않는 따라 스타일링과 Fable.React에 대해 다음 스타일.

그러나 이것이 적용되지 않는 한 곳은 사소한 스타일링입니다. 그러나 우리의 경험에 따르면 이것은 소수의 요소(아마도 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"
                ]
            ]
        ]
    ]
]

또한 VS Code 및 Rainbow Brackets 같은 것을 사용하면 브래킷 과부하를 피하는 데 실제로 도움이 될 수 있습니다.

고려해야 할 다른 사항(위에서 놓쳤을 수 있음)은 GiraffeViewEngine이 Fable.React 스타일, 즉 요소 attr-list children-list를 사용하므로 둘 사이를 전환하는 사람들의 관점에서 생각할 수 있는 것입니다.

@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 에서 파생된 라이브러리에 대해 이것이 의미하는 바는 Fable.React가 지원하지 않기 때문에 종속성의 npm 메타데이터뿐만 아니라 react 및 react-dom 호환 버전도 포함해야 한다는 것입니다. ( react 및 react-dom 시작하는 Feliz와 달리 Feliz 확장 프로그램은 필요한 것만 추가합니다.) 불행히도, 나는 그 솔루션이 꽤 오랫동안 주변에 있었음에도 불구하고 상황을 개선하기 위해 주도권을 잡은 라이브러리를 아직 보지 못했습니다.

형식 지정과 관련하여: Fantomas는 아직 DSL을 합리적인 방식으로 형식화할 수 없으며 목록 형식 지정을 구성 가능 하게 만드는 작업이 필요하거나 멋진 기본값을 사용하여 React DSL을 형식화하기 위해 일종의 "Feliz-mode" 플래그가 있어야 합니다. 최대)

@Zaid-Ajaj React npm 종속성과 관련된 문제는 Femto를 중단하지 않고 react 대신 preact를 사용할 수 있어야 하므로 더 복잡합니다.

@l3m 사실, 하지만 이 경우에는 Femto를 추가하여 이 경우를 지원할 수 있습니다. 뭔가를 기억하고 있어서 Femto repo에 문제가 있는 것 같습니다(지금 확인할 시간이 없어 죄송합니다 ^^)

@l3m Preact는 Femto npm 메타데이터와 상관없이 React 대신 사용할 수 있습니다. 기존 React 애플리케이션이 있는 경우 Switching to Preact 의 지침에 따라 모듈 가져오기 별칭만 구성하면 되기 때문입니다.

순수한 Preact 바인딩(100% non-React 코드)을 구축하는 것은 Feliz의 목표가 아니며 아마도 Preact 전용 바인딩이 확장되고 확장될 독립형 라이브러리(Feliz.Preact에 의존하지 않는 Feliz.Preact)로 구현되어야 합니다. preact/compat 에서 벗어나고 싶을 때 사용

@Zaid-Ajaj 저는 지금 Elmish 앱에서 preact를 사용하고 있으며 잘 작동합니다. Femto가 React deps와 함께 nuget을 보는 경우 packages.json을 수정하는 것에 대해 조심스러웠고 이를 강조하고 싶었습니다. 그것이 문제가 아니라면, 더 좋습니다.

또한 preact/compat 는 최신 preact에서 더 이상 필요하지 않으며 이제 핵심입니다.

위험을 무릅쓰고 오래된 토론을 다시 열 수 있습니다(죄송합니다!). 저는 들여쓰기 토론에 2센트를 추가하고 싶었습니다. 이것은 Fable.React에 대해 훌륭하고 일관된 식별 및 팔로우를 허용하는 _does_ 따르는 스타일입니다. 스타일.

나는 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이 제안한 것과 유사한 접근 방식을 시도했지만 들여쓰기가 모두 2/4가 아니기 때문에 "때로는 그것에 대해 생각하는 데 시간을 보냅니다". Feliz와 함께라면 그것에 대해 생각할 시간이 전혀 없습니다.

• 내가 사용자 정의 요소를 만들고 있다면 지금은 Fable.React 방식으로 했을 것입니다. 나는 "Feliz 방식"으로 건물을 짓는 것을 보고 즉시 도망쳤습니다(언젠가 다시 방문할 예정입니다!).

• 문서가 "이것이 사용자 정의 속성을 만드는 방법" 측면에 보다 정기적으로 우선 순위를 부여한다면 정말 유용할 것입니다. 소수의 작성자와 함께 이러한 라이브러리가 CSS에서 가능한 모든 것에 대한 API 표면을 제공하는 데 종종 어려움을 겪을 수 있다는 점을 받아들이는 것이 공정하다고 생각합니다(예: 예를 들어). 따라서 초보자가 "fontSize"를 설정할 수 없을 때 막히게 된다면 "em"에 있거나 "grid-template-rows"를 찾을 수 없거나 "Screen.All" 인수를 제공해야 하는지 전혀 모릅니다. 문제를 해결하는 방법을 알고 있으면 좋을 것입니다.

• 몇 가지 잠재적인 우려를 없애기 시작하는 일부 "삶의 질" 개선이 이루어질 수 있다고 생각합니다... 예를 들어 Feliz에서 스타일 소품의 긴 수직 목록을 볼 때 style.paddingHorizontal 가 있을 수 있는지 궁금하기 시작합니다. style.paddingVertical . 나는 내 자신의 도우미를 만들 수 있다는 것을 깨달았습니다. 그리고 이것은 기능을 요청하는 곳이 아니며 표준이 아닌 것을 도입하는 것을 피하고 싶은 욕구가 있을 수 있습니다. :)

• 나는 새로운 F#에서 Html 정적 클래스를 여는 아이디어를 좋아합니다. 비판적으로 - 동료들이 내 어깨 너머로 바라볼 때 그것을 이해할 수 있을 것입니다 - 그리고 더 많은 사람들을 참여시키는 것이 중요하다고 생각합니다. 악마의 옹호자 역할을 하려면 div 를 입력하는 데 오래 걸리지 않으며 이를 발견해야 하는 경우 마법을 수행하는 설정을 사용할 때 부딪힐 가장 작은 문제입니다. 나에게 자바스크립트, React, CSS 등을 숨기는 것. 그러나 일반적으로 API의 검색 가능성은 뛰어납니다.

• 특히 스타일에 대한 전환/애니메이션의 경우 Feliz 방식은 매우 의미가 있습니다. 작업하기에 정말 좋습니다.

• 더 일반적으로 그리고 아마도 접할 수 있습니다. 내가 지속적으로 부딪치는 문제는 Elmish 세계가 끝나고 React 세계가 시작되는 위치를 이해하는 것입니다. 이것은 실제로 두 라이브러리의 관심사가 아닙니다. 그러나 React에 대한 가장 흐릿한 단서가 없기 때문에 Fable.React 또는 Feliz에서 Function Component를 얻을 수 있다는 사실이 저를 혼란스럽게 합니다. 물론 이것을 배우는 것은 나의 책임이지만 언급할 가치가 있다고 생각했습니다. 저는 현재 Elmish와 React 접근 방식을 함께 사용하고 있으며 이로 인해 업데이트 시 모든 구성 요소가 다시 렌더링된다고 생각합니다. 그러나 이와 같이 완전히 빌드된 앱의 예는 찾기 힘들다. 때로는 Javascript로 프로덕션 등급의 React 앱을 먼저 만들고 Fable/Elmish로 졸업해야 한다는 인상을 받기도 합니다. 면책 조항: 저는 Feliz 문서를 광범위하게 읽지 않았으며 정말 좋습니다. 그래서 이것은 아마도 제 책임입니다!

이 라이브러리를 공유해 주신 모든 분들께 감사드립니다!

@drk-mtr 입력해주셔서 감사합니다!

내가 사용자 정의 요소를 만들고 있다면 지금은 Fable.React 방식으로 했을 것입니다. 나는 "Feliz 방식"으로 건물을 짓는 것을 보고 즉시 도망쳤습니다(언젠가 다시 방문할 예정입니다!).

예, 처음에는 꽤 어려워 보일 수 있지만 익숙해지면 매우 간단합니다. 라이브러리를 작성할 때 개발자에게 상당한 초기 비용이 든다고 합니다. 대다수의 사용자가 라이브러리를 작성하지 않을 것이기 때문에 이것이 꽤 수용 가능한 절충안이라고 생각합니다. 운 좋게도 작업 자체는 매우 간단하며 일부 복사 + 붙여넣기는 많은 작업의 속도를 높일 수 있습니다(또는 우리 중 일부처럼 코드를 빌드하기 위해 생성기를 작성하는 경우).

문서가 "이것이 사용자 정의 속성을 만드는 방법" 측면에 보다 정기적으로 우선 순위를 부여한다면 정말 유용할 것입니다. 소수의 작성자와 함께 이러한 라이브러리가 CSS에서 가능한 모든 것에 대한 API 표면을 제공하는 데 종종 어려움을 겪을 수 있다는 점을 받아들이는 것이 공정하다고 생각합니다(예: 예를 들어). 따라서 초보자가 "fontSize"를 설정할 수 없을 때 막히게 된다면 "em"에 있거나 "grid-template-rows"를 찾을 수 없거나 "Screen.All" 인수를 제공해야 하는지 전혀 모릅니다. 문제를 해결하는 방법을 알고 있으면 좋을 것입니다.

당신이 알지 못하는 경우를 대비하여 (이 컨텍스트에서는 말할 수 없습니다):

prop 및 style 유형 모두에 custom 메소드가 있습니다.

ICssUnit 를 허용하는 모든 것은 다음과 같이 설정할 수 있습니다. style.fontSize (length.em 1)

문서 업데이트는 충분히 쉬워야 합니다.

몇 가지 잠재적인 우려를 없애기 시작하는 일부 "삶의 질" 개선이 이루어질 수 있다고 생각합니다... 예를 들어 Feliz에서 스타일 소품의 긴 세로 목록을 볼 때 style.paddingHorizontal이 있을 수 있는지 궁금하기 시작합니다. style.padding수직. 나는 내 자신의 도우미를 만들 수 있다는 것을 깨달았습니다. 그리고 이것은 기능을 요청하는 곳이 아니며 표준이 아닌 것을 도입하는 것을 피하고 싶은 욕구가 있을 수 있습니다. :)

사용자 경험을 더 쉽게 만드는 데 도움이 되는 것은 무엇이든 내 책에서 환영합니다. 나는 당신이 발견한 이러한 것들에 대한 이슈/홍보를 보고 싶습니다!

더 일반적으로 그리고 아마도 접할 수 있습니다. 내가 지속적으로 부딪치는 문제는 Elmish 세계가 끝나고 React 세계가 시작되는 위치를 이해하는 것입니다. 이것은 실제로 두 라이브러리의 관심사가 아닙니다. 그러나 React에 대한 가장 흐릿한 단서가 없기 때문에 Fable.React 또는 Feliz에서 Function Component를 얻을 수 있다는 사실이 저를 혼란스럽게 합니다. 물론 이것을 배우는 것은 나의 책임이지만 언급할 가치가 있다고 생각했습니다. 저는 현재 Elmish와 React 접근 방식을 함께 사용하고 있으며 이로 인해 업데이트 시 모든 구성 요소가 다시 렌더링된다고 생각합니다. 그러나 이와 같이 완전히 빌드된 앱의 예는 찾기 힘들다. 때로는 Javascript로 프로덕션 등급의 React 앱을 먼저 만들고 Fable/Elmish로 졸업해야 한다는 인상을 받기도 합니다. 면책 조항: 저는 Feliz 문서를 광범위하게 읽지 않았으며 정말 좋습니다. 그래서 이것은 아마도 제 책임입니다!

Fable 세계(Feliz 이전)에서의 내 경험은 대부분의 경우 모든 것을 일반 함수로 작성했다는 것입니다(예: 각 .fs에 대한 하나의 구성요소). 그 결과 React 시스템이 제공하는 많은 이점을 잃었습니다. Feliz를 시작한 이후로 나는 React가 어떻게 작동하는지에 대해 더 깊이 파고들어야 했습니다. 익숙해지니까 더 이상 의식적으로 생각하지도 않는다. 렌더링을 수행하는 내가 작성한 모든 단일 함수는 함수 구성 요소입니다.

관용적으로 React를 작성하는 방법을 정말로 배우고 싶다면 Elmish를 사용하지 않고 데모 앱에서 기능 구성 요소/후크만 사용하도록 제한하는 것만 큼 간단하다고 생각합니다. API가 거의 동일하기 때문에 JS로 작성된 모든 것을 매우 쉽게 따라갈 수 있습니다.

Feliz로 작성된 양질의 오픈 소스 응용 프로그램을 갖는 것은 확실히 도움이 될 것입니다. 나는 잠시 동안 #67에 대한 문제를 만들었습니다. 지금 가장 가까운 것은 아마도 문서 앱 자체 또는 @cmeeren 의 Electron Demo 일 것 입니다.