Feliz: Feliz를 추상 API로 만들기

안녕하세요 @alfonsogarciacaro , 솔직히 말해서 저는 이것이 좋은 생각이라고 _기억_하지 않습니다. 이론적으로는 이해가 됩니다. Fable에서 HTML용 표준 API를 구축해 보겠습니다. 실제로는 잘 번역되지 않습니다. 다음은 몇 가지 이유입니다.

• 현재 API는 표준이 아니며 사실 매우 독단적입니다. 많은 사람들은 여전히 ​​전체 단일 목록과 prop.children 좋아하지 않습니다. 물론 완전히 괜찮습니다.
• 현재 API는 React 전용이라는 가정 때문에 "단순"하게 만들어졌습니다. 추상화하려면 Feliz 스타일 API를 작성/복제하는 대안이 더 쉬운 솔루션일 수 있는 많은 작업이 필요합니다.
• 리소스를 분산시키는 것보다 React 주변의 도구를 개선하는 데 집중하고 싶습니다. Feliz는 "완료"와는 거리가 멀고, 문서, 샘플 애플리케이션, 더 나은 테스트 스토리 등과 관련하여 여전히 해야 할 일이 많습니다.

@Zaid 답변 감사합니다! 나는 당신의 추론을 이해합니다. 우리가 경쟁하는 DSL이 너무 많다는 것이 여전히 유감이지만 당신이 말하는 것처럼 다른 솔루션이 있을 수도 있습니다. 시간이 된다면 프로토타입을 작성하여 어떻게 작동하는지 확인하려고 합니다.

BTW, 여기에서 몇 가지 작업을 시작했습니다. https://github.com/alfonsogarciacaro/Feliz.Engine/blob/main/src/HtmlEngine.fs

나는 그것을 테스트하지 않았지만 모든 unbox 및 유사한 트릭을 제거했으므로 원칙적으로 이 인터페이스 를 구현하는 모든 렌더러와 "작동해야" 합니다. 예를 들어 React 렌더러를 @dbrattli Feliz.ViewEngine과 결합하고 Feliz로 SSR을 더 간단하게 만드는지 확인하는 것이 좋습니다.

파악/고려해야 할 몇 가지 사항이 있습니다.

인텔리센스

Html 가 Feliz에서 다음과 같이 정의될 것이기 때문에 내 인텔리센스가 펑키해 보인다는 사실이 매우 기쁘지 않습니다.

let Html = HtmlEngine(renderer)

그것은 더 사소한 문제입니다.

번들 크기

우리는 이것이 현재와 같거나 더 좋기를 분명히 원할 것입니다. 아마도 컴파일러 지시문에 래핑된 Feliz.HtmlEngine 의 플러그인일까요? 이 솔루션은 웹 서버가 Fable에 의존하도록 만들 것입니다.

기타 라이브러리

현재 수행되고 있는 SSR의 가장 큰 문제 중 하나는 대부분의 경우 다른 라이브러리가 단순히 작동하지 않고 작동하는 라이브러리(예 Feliz.Bulma / Feliz.Bulma.ViewEngine )도 조정이 필요하지 않는 한 여전히 조정이 필요하다는 것입니다. 이것이 무엇인지 유사한 참조를 위해 둘 다에 대한 추상 API를 빌드하십시오.

대안

여기서 근본적인 문제는 우리가 의도한 첫 번째 페인트를 완전히 에뮬레이트하고 싶을 때 SSR을 직접 수행하는 것이 매우 실현 가능하지 않다는 것입니다. 우리에게 정말로 필요한 것은 .NET을 위한 ReactDOMServer 와 같은 것입니다. 나는 이것에 대해 너무 깊이 파고 들지 는

@Shmew 의 의견에 감사하고 늦게 답장을

• Intellisense : 흠, 추상 API를 사용하여 간단한 예제만 작성했지만 자동 완성 문제는 보지 못했습니다. 다시 확인해 보도록 하겠습니다. 사용자는 정적 유형에 액세스하는 대신 값에 액세스합니다. 나는 괜찮을 것이고 많은 경우에 코드를 변경할 필요가 없다고 생각합니다. 주요 단점은 아마도 open type 사용할 수 없다는 것입니다.
• 번들 크기 : 이것도 확인해야 합니다. 내 희망은 클래스 멤버가 트리를 흔들 수 있고 잘 축소할 수 있는 분리된 함수로 Fable에 의해 컴파일되기 때문에 많이 변경되지 않는 것입니다. 불행히도 생성된 코드는 #284 이후와 같이 멋지게 보이지 않습니다.
• 기타 라이브러리 : 예, 추상 API의 이점을 얻으려면 다른 라이브러리를 조정해야 합니다. 최소한의 변경으로 바랍니다.
• 대안 : TBH, Fable.React의 (기여된) 코드를 보면 매우 복잡해 보이지는 않지만(기본적으로 생성된 html 태그에 일부 메타데이터를 추가하는 것) SSR이 어떻게 작동하는지 잘 모르겠습니다. 그래서 확실하지 않습니다. React.NET과 같은 것을 사용하는 것이 더 쉬운지 여부. Feliz에는 .NET에서 발생하는 Fable 트릭(주로 안전하지 않은 캐스트)이 포함되어 있기 때문에 Feliz에서도 ootb를 사용할 수 없습니다.

사실, 이것을 위해 나는 SSR 뿐만 아니라 _beyond React_ :wink:에서도 생각하고 있습니다. 예를 들어 F# 서버의 html 생성기는 React와 반드시 호환될 필요는 없고 다른 렌더러를 사용하려는 경우입니다. 프론트엔드에 대해 반응합니다.

@Shmew 댓글 감사하고 늦게 답장해서 죄송합니다

천만에요. 걱정 마세요!

Intellisense: 흠, 추상 API를 사용하여 간단한 예제만 작성했지만 자동 완성에는 문제가 없었습니다. 다시 확인해 보도록 하겠습니다. 사용자는 정적 유형에 액세스하는 대신 값에 액세스합니다. 나는 괜찮을 것이고 많은 경우에 코드를 변경할 필요가 없다고 생각합니다. 주요 단점은 아마도 개방형 유형을 사용할 수 없다는 것입니다.

죄송합니다, 나는 매우 명확하지 않았습니다. Intellisense는 괜찮지만 Html 가 다른 색상이라는 사실입니다. 내가 말했듯이, 정말 마이너 😅. 우리가 open type 할 수 없다는 사실은 사실 조금 더 큰 문제입니다. 나는 일부 사람들 이 모든 것을 네임스페이스로 지정하는 것보다 그것을

번들 크기: 이것도 확인해야 합니다. 내 희망은 클래스 멤버가 트리를 흔들 수 있고 잘 축소할 수 있는 분리된 함수로 Fable에 의해 컴파일되기 때문에 많이 변경되지 않는 것입니다. 불행히도 생성된 코드는 #284 이후와 같이 멋지게 보이지 않습니다.

interop 함수가 이미 인라인되지 않았음을 깨닫지도 못하고 이미 라이브러리에 인라인했습니다. 전체 Html 모듈은 모두 인라인 래퍼이기 때문에 JS에서 기본적으로 수행되는 경우와 비교하여 번들 크기 증가가 없다는 사실에 대해 더 많이 이야기했습니다. 더 이상 그렇지 않은 구체적인 클래스로.

기타 라이브러리: 예, 추상 API의 이점을 얻으려면 다른 라이브러리를 조정해야 합니다. 최소한의 변경으로 바랍니다.

이것의 문제는 모든 내부가 JS 전용이기 때문에 네이티브 반응 코드를 사용하는 라이브러리가 제대로 작동 하지 않는다는 것입니다.

대안: TBH, Fable.React의 (기여된) 코드를 보면 그다지 복잡해 보이지는 않지만(기본적으로 생성된 html 태그에 일부 메타데이터를 추가하는 것) SSR이 어떻게 작동하는지 잘 모르겠습니다. React.NET과 같은 것을 사용하는 것이 더 쉬운지 여부. Feliz에는 .NET에서 발생하는 Fable 트릭(주로 안전하지 않은 캐스트)이 포함되어 있기 때문에 Feliz에서도 ootb를 사용할 수 없습니다.

네, 간단한 경우에는 작동하지만 Feliz.MaterialUI 일부 구성 요소와 같이 더 복잡한 것을 사용하려고 하면 작동하지 않습니다. 내가 이해한 바에 따르면 React SSR은 node.js에서 완료될 때 매우 간단합니다. 왜냐하면 ReactDOMServer 를 실행하여 실제로 페이지의 첫 번째 페인트인 전체 문자열을 뱉어낼 수 있기 때문입니다. 내 이해는 React.NET 가 정확히 그것을 수행하기 위해 node.js 프로세스를 래핑하는 것입니다.

Feliz 코드는 이미 이와 같은 것을 지원하기 때문에 이것이 실제로 매우 쉬울 것이라고 생각합니다. 프로세스는 다음과 같습니다.

Fable compiles F# React 
-> node.js process imports and returns html string 
-> web server caches output 
-> web server serves page

반응을 넘어서

이것은 훌륭한 요점이며, React 또는 기타 요소 없이 순수한 HTML을 렌더링하려는 경우 확실히 원할 것입니다.

저는 이 아이디어를 실험하고 있습니다. 여기에서 제 진행 상황을 볼 수 있습니다: https://github.com/alfonsogarciacaro/Feliz.Engine

아직 해야 할 일이 있고 몇 가지 의구심이 있지만 이미 작동하고 있으며 Feliz API의 대부분을 다루고 있습니다. 다만 약간의 수정을 가해야 해서 펠리즈를 이런걸로 대체하기 힘든게 사실입니다. 그러나 Feliz의 추상 버전은 많은 가능성을 열어주기 때문에 여전히 가치가 있습니다. 몇 가지 예:

1. Sutil과 같은 다른 프론트엔드 프레임워크와 함께 사용: https://github.com/davedawkins/Sutil/pull/15
2. SASS 대신 CSS를 생성하는 데 사용: https://github.com/alfonsogarciacaro/Feliz.Engine/blob/main/samples/Feliz.Css/Feliz.Css.fs
3. 정적 html 생성에 사용: https://github.com/alfonsogarciacaro/Feliz.Engine/blob/main/samples/Feliz.StaticHtml/Feliz.StaticHtml.fs
4. Snabbdom과 같은 다른 가상 돔 구현과 함께 사용하십시오. https://github.com/alfonsogarciacaro/Feliz.Engine/blob/main/samples/Feliz.Snabbdom/Feliz.Snabbdom.fs

이것들은 모두 초안이지만 작동 중이며 매우 적은 코드가 필요하다는 것을 알 수 있습니다. 더 중요한 것은 이들 모두가 사용자에게 문서화되고 친숙한 API를 제공하며 확장도 가능합니다. 예를 들어 이러한 모든(및 향후) 앱과 호환되는 BulmaEngine을 쉽게 만들 수 있습니다. 2. 및 3의 경우 증분 컴파일이 .NET보다 훨씬 빠르기 때문에 Fable을 사용하고 있지만 Feliz.Engine은 .NET과 호환되므로(모든 unbox ) 간단해야 합니다. F# .NET 서버와 호환되도록 하고 HTML 생성기를 React와 호환되도록 만드는 데 많은 작업이 필요하지 않기를 바랍니다.

@Zaid-Ajaj는 어떻게 생각하세요? 나는 이미 현재 Feliz React API를 대체하는 아이디어를 포기했습니다 😅 하지만 이런 것이 "Feliz family"(아마도 이 repo에 있음)에 속해야 한다고 생각하십니까? 이름이 괜찮습니까, 아니면 다른 이름을 사용하시겠습니까?

안녕하세요 @alfonsogarciacaro , 이번 주에 이 샘플을 자세히 살펴보고 확실히 돌아올 것입니다 😄

안녕하십니까,

코드를 빠르게 살펴보았는데 이 추상 버전이 번들 크기에 약간의 영향을 미칠 것 같습니다. 지금의 펠리즈의 특징 중 하나라는 점을 지적하고 싶었다.

예, 영향이 예상됩니다. 문제는 크기가 얼마나 되는지입니다. :) 중간 규모 앱의 경우 눈에 띄지 않기를 바랍니다. 하지만 물론 두 스타일 모두에서 fulma-demo 같은 것이 있으면 좋을 것이므로 우리는 비교하고 최적화 기회를 테스트하는 데 사용할 수 있습니다. Feliz 도우미가 번들 크기에 어떤 영향을 미치는지 확인하는 것도 흥미로울 것입니다. 현재 Feliz가 생성한 코드는 매우 훌륭하고 컴파일된 JSX와 매우 유사하지만 함수를 축소할 수 있으므로 .createElement("div") 와 같은 많은 호출의 중복을 줄이는 방법이 될 수 있습니다(gzip이 압축할 수 있는지 확실하지 않음 그러나 이러한 호출).

네, 다른 프로젝트에서 이 멋진 API/스타일을 사용하는 것에 반대하는 사람이 있을 거라고는 상상도 할 수 없습니다. 내 유일한 진짜 관심사는 이 라이브러리의 품질과 위에서 설명한 일부 인체 공학적 문제에 영향을 줄 수 있는지 여부였습니다.

안녕하세요 @alfonsogarciacaro , 예제 코드를 잘 보았습니다. css 엔진과 정적 html 엔진이 모두 node.js 스트림을 사용하기 때문에 nodejs 전용 애플리케이션이라는 사실에 놀랐습니다. 아이디어가 흥미롭긴 하지만 위의 방법 중 하나를 실제로 사용하는 제 자신을 보기는 어렵습니다.

• CssEngine은 CSS를 생성합니다. Feliz에 내장된 것과 같은 CSS/SASS 도구 체인 또는 CSS-in-JS를 사용하거나 FSS 또는 감정과 같은 다른 CSS-in-JS 라이브러리를 사용하는 것과는 대조적으로 이점이 무엇입니까? F#에서 CSS를 생성하는 것은 자체적으로 작동하지만 기존 도구 체인에 의존하는 것이 더 나은 선택이 될 것이기 때문에 Feliz와 함께 사용하지 않을 것입니다. 거대한 스타일시트를 컴파일하기 위해) 현재 저는 Feliz/React 구성 요소에 CSS 모듈을 사용하는 것을 더 선호
• 정적 html 엔진: Feliz는 이미 노드와 브라우저에서 ReactDOM 를 사용하여 정적 html을 생성합니다. Feliz.ViewEngine은 dotnet에서 정적 HTML을 생성하는 것과 동일한 작업을 수행합니다. API를 공유하는 것이 아이디어라는 것을 알고 있지만 @Shmew가 언급한 것처럼 다른 문제로 인해 어려워졌습니다. 두 가지를 모두 구현해야 하는 라이브러리가 생성된 코드에 영향을
• Snabbdom 엔진: 흥미로운 예이지만 React와 같은 라이브러리 생태계가 없습니다.

대체로 흥미로운 운동입니다. 솔직히 말해서 저는 새로운 API의 열렬한 팬이 아니며 개인적으로 라이브러리를 표준화하는 대신 React에서 더 많은 문서, 예제 및 바인딩을 사용하여 현재 경험을 개선하는 데 시간을 할애하고 싶습니다. 제가 그것에 대해 약간 부정적으로 생각했다면 죄송합니다. 아마 많은 일을 하셨을 것입니다. Feliz와 같은 이름은 도서관에서 영감을 받았기 때문에 상관 없습니다.

@Zaid-Ajaj 샘플을 확인해주셔서 감사합니다! 나는 당신의 정직에 감사드립니다. css 및 html 프린터는 Feliz.Engine을 잠재적 용도에 적용하는 것이 얼마나 쉬운지/어려운지를 확인하기 위한 간단한 예일 뿐입니다(인쇄를 수행하는 코드는 50줄에 불과합니다). 증분 컴파일이 훨씬 빠르기 때문에 Fable & node를 사용했지만 "원칙적으로" .net에 쉽게 적용할 수 있어야 합니다. Snabbdom 어댑터는 또 다른 빠른 예이기도 하지만 실제로는 마음에 들기 시작했습니다. 하지만 그건 또 다른 문제입니다. :)

어쨌든, 나는 마침내 변경 사항을 깨뜨리지 않고 현재 Feliz React 앱을 추상화하는 것이 불가능하다는 것을 깨달았습니다. Feliz 같은 API 👍

@alfonsogarciacaro 대단해 보이네요. #262에서 언급했듯이 Fable.React에서 Feliz로 전환한 후 내가 정말 정말 그리워하는 유일한 것은 '그냥 작동하는' SSR입니다. Feliz와 Feliz.ViewEngine은 모두 놀라운 프로젝트이지만 두 개의 서로 다른 프로젝트가 있으면 코드 재사용이 어려워집니다. ifdefs를 사용하는 코드는 ifdefs를 사용하는 다른 코드에서만 사용할 수 있기 때문입니다. 유일한 및 양쪽 세계 코드. 그 격차를 줄이는 것은 무엇이든 Feliz 및 .Net 서버로 작업할 때 삶의 질을 향상시킬 것입니다.

예. 훌륭한 사용 사례가 될 것입니다. 하지만 결국 Feliz.Engine이 Feliz와 몇 가지 차이점 이 있기 때문에 까다롭습니다. 즉, Feliz 자체와 경쟁할 Feliz.Engine React 구현을 작성해야 하므로 피하고 싶습니다 ;) 하지만 바라건대 우리는 찾을 수 있습니다. 해결책.