Feliz: Feliz를 위한 "그냥 작동" 닷넷 기반 SSR

네, 저는 그 아이디어에 반대하지 않습니다. 또한 동기화를 유지합니다.

@l3m님 , 저는 이 아이디어가 정말 마음에 들어요. 물론 "

지금 가장 좋은 절충안은 SSR 부분에 Fable.React를 사용하고 나머지 부분에 Feliz를 사용하거나 Feliz/Feliz.ViewEngine을 계속 사용하는 것입니다.

Feliz에 대한 현재 계획은 여전히 ​​순수한 React 지원 및 생태계에 초점을 맞추는 것입니다. 적절한 Svg 지원 #251, Fable 3의 적절한 빠른 새로 고침 지원(#157 및 #260) 및 모든 장점(문서)으로 더 많은 전체 구성 요소 구현 , 예 등)

@Zaid-Ajaj 흠, 이해할 수 있는 이유지만 이 접근 방식에서 내가 보는 문제는 모든 종속 라이브러리도 SSR을 구현하지 않는다는 것입니다. Feliz에 있다면 모든 종속 라이브러리에도 있을 것입니다.

이는 기본적으로 다음을 의미합니다. Feliz는 장난감이 아닌 프로젝트(SSR이 실제로 필요한 경우)에 SSR과 함께 사용할 수 있습니다. 추가 라이브러리 지원 없이 순수한 Feliz를 사용하는 것은 더 큰 프로젝트의 경우 더 드문 경우인 것처럼 보입니다.

우리를 위해 Feliz가 있는 SSR은 추가 종속성을 사용해야 할 때까지 작동했고 Feliz가 제공하지 않으면 라이브러리 작성자가 작업을 수행하도록 설득하기 어려운 것 같습니다.

네, 꽤 설득력 있는 주장입니다. 라이브러리가 이미 구조화된 방식으로 인해 혼란을 상당히 줄일 수 있다고 생각 합니다. 예를 들어 모든 요소(또는 대다수)는 대부분의 속성 등과 동일한 동일한 2-3개의 함수를 호출합니다. 따라서 대부분의 경우 해당 소스에서 수정이 필요할 것이라고 생각합니다. 내가 잘 알지 못하는 보기 엔진에서 수행된 몇 가지 특별한 작업이 있습니다. 아마도 @dbrattli 가 그/이 주제에 대해

네, 저도 고통을 느끼고 있습니다 . 대부분 다른 네임스페이스로 인해 파일 전체에 많은 #if FABLE_COMPILER 발생합니다. 그러나 Ionide가에 숨이 또한 ReactElement Feliz.ViewEngine이 같은 없다는 ReactElement Fable.React의. Feliz에서 모든 라이브러리(예: Feliz.MaterialUI 를 .ViewEngine으로 이식하고 동기화 상태로 유지하는 것은 고통스러울 것입니다. Feliz.Bulma.ViewEngine을 최신 상태로 유지하는 것을 이미 포기한 것 같습니다.

펠리 즈 코드 서버 측을 사용하여 주요 문제는 예를 많이 사용한다는 것입니다 unbox<string>(value) 대신 string value . 여기서 성능 이득이란 무엇입니까? 차이점을 숨기기 위해 인라인 함수를 사용할 수 있습니까? 서버 측에서 다르게 처리해야 하는 !!e?value <> !!value then e?value 같은 Fable.Core.JsInterop 항목도 있습니다.

Feliz.ViewEngine은 ReactElement 를 HTML로 다시 구문 분석하는 것이 쉽지 않기 때문에 자체 데이터 모델도 사용합니다. 따라서 !FABLE_COMPILER 때 Interop.fs에서 ViewEngine 유형을 생성할 수 있다면 좋을 것입니다. ViewEngine 유형은 여전히 ReactElement에서 상속 할 수 있으므로 서명이 동일하게 유지됩니다.

그래서 가능하다고 생각하지만 Feliz 자체에 약간의 변경과 약간의 #if FABLE_COMPILER 가 필요합니다. 그러나 @Zaid-Ajaj가 라이브러리 병합 아이디어에 대해 승인된 원칙을 제공할 때까지는 그러한 노력을 시작하지 않을 것입니다..

예를 들어 unbox<string>(value) 도 사용하는 Feliz.Bulma 에 대해서도 유사한 변경이 필요하지만 작업 방법에 대한 공통 권장 사항이 있다면 종속 라이브러리도 결국에는 작동할 것입니다.

가능한 경우 unbox<string> 사용하는 이유를 보려면 다음을 고려하세요.

box / unbox 는 JS이기 때문에 컴파일 시에 지워집니다.

string i 하면 다음과 같이 컴파일됩니다.

// fable-library

export function int32ToString(i: number, radix?: number) {
  i = i < 0 && radix != null && radix !== 10 ? 0xFFFFFFFF + i + 1 : i;
  return i.toString(radix);
}

// Calling site
import { int32ToString } from "fable-library/Util.js";

export const test = int32ToString(1);

unbox<string> 1 하면 다음과 같이 컴파일됩니다.

export const test = 1;

따라서 모두 입력에 대한 제한을 사용하는 10개의 속성이 있지만 실제 표현이 문자열인 경우 해당 속성은 해당 구성 요소를 다시 렌더링 할 됩니다 . 이것의 단일 인스턴스의 실행 비용은 엄청나게 작지만, 잠재적으로 수백 개의 구성 요소에 걸쳐 있는 각 구성 요소에 1-20개를 가질 수 있는 경우 이러한 호출 사이트에서 계산을 줄이는 것이 중요합니다.

이제 이에 대한 솔루션은 실제로 매우 간단합니다.

let inline unboxStr o = 
    #if FABLE_COMPILER  
    unbox<string> o
    #else
    string o
    #endif

그런 다음 unbox<string> 에서 찾기 바꾸기를 수행합니다.

Fable 3에는 상당한 재작성이 포함될 가능성이 높기 때문에 위에서 언급한 @Zaid-Ajaj의 다른 문제를 수정하는 동안 이 작업을 수행할 적절한 시기라고 생각합니다. 우리는 이것을 하기를 원할 것입니다. (나는 @Zaid-Ajaj가 SSR에 반대하지 않는다고 말하는 것이 매우 안전하다고 생각합니다. 엄마의 스파게티가 그의 코드 베이스 전체에 쏟아지는 것에 반대하는 것만큼), 그리고 저는 그것이 가장 고통스럽지 않을 것이라고 믿습니다. /그 기간 동안 처음부터 SSR을 염두에 두고 완료했다면 지저분합니다.