Feliz: Feliz . के लिए "यह बस काम करता है" डॉटनेट-आधारित SSR

हां, मैं उस विचार के खिलाफ नहीं हूं, यह चीजों को समकालिक भी रखता है।

हाय @ l3m , मुझे वास्तव में यह विचार पसंद है और निश्चित रूप से "बस काम" की चीजें उपयोगकर्ताओं के लिए आदर्श होंगी। हालांकि, यह पुस्तकालय के कार्यान्वयन विवरण और शिफ्ट फोकस को बेहद जटिल बना देगा। इस पुस्तकालय के निर्माण के दिन से, मैंने जानबूझकर SSR समर्थन छोड़ दिया क्योंकि मैंने Fable.React में जो गड़बड़ विवरण देखा था, उसके कारण।

अभी सबसे अच्छा समझौता SSR भागों के लिए Fable.React और बाकी के लिए Feliz का उपयोग करना या Feliz/Feliz.ViewEngine का उपयोग करना जारी रखना है।

फ़ेलिज़ के लिए अभी शुद्ध रिएक्ट समर्थन और उसके पारिस्थितिकी तंत्र पर ध्यान केंद्रित करना है: उचित Svg समर्थन #251, उचित तेज़-ताज़ा समर्थन (#157 और #260) Fable 3 के साथ और सभी अच्छाइयों के साथ अधिक पूर्ण घटकों को लागू करना (दस्तावेज़) , उदाहरण आदि)

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

जिसका मूल रूप से अर्थ होगा: गैर-खिलौना परियोजनाओं (जहां एसएसआर वास्तव में आवश्यक है) के लिए एसएसआर के साथ फेलिज का उपयोग किया जा सकता है - बिना अतिरिक्त पुस्तकालय समर्थन के शुद्ध फेलिज का उपयोग करना बड़ी परियोजनाओं के लिए दुर्लभ मामला लगता है।

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

हाँ, यह एक बहुत ही ठोस तर्क है imo। मुझे लगता है कि पुस्तकालय पहले से ही कैसे संरचित है, इस वजह से हम अव्यवस्था को काफी हद तक कम कर सकते हैं। तत्वों के सभी (या विशाल बहुमत) उदाहरण के लिए सभी समान 2-3 कार्यों को कॉल करते हैं, अधिकांश गुणों के साथ समान और ऐसे। इसलिए मेरा मानना ​​है कि अधिकांश भाग के लिए इसे केवल उन स्रोतों में संशोधन की आवश्यकता होगी। व्यू इंजन में कुछ विशेष चीजें की गई हैं जिनसे मैं वास्तव में परिचित नहीं हूं, शायद @dbrattli उन/इस विषय पर झंकार कर सकता है।

हाँ, मैं खुद दर्द महसूस कर रहा हूँ: नियुक्त:। अधिकतर अलग-अलग नामस्थानों के कारण फाइलों में बहुत अधिक #if FABLE_COMPILER है। लेकिन यह भी कि Ionide Feliz.ViewEngine के ReactElement पर चोक हो जाता है, Fable.React के ReactElement के समान नहीं होता है। फ़ेलिज़ से सभी पुस्तकालयों को पोर्ट करना जैसे Feliz.MaterialUI से .ViewEngine और उन्हें सिंक में रखना दर्दनाक होगा। मुझे लगता है कि मैंने पहले ही Feliz.Bulma.ViewEngine को अप-टू-डेट रखना छोड़ दिया है।

फेलिज़ कोड सर्वर साइड का उपयोग कर के साथ मुख्य समस्या यह है कि जैसे का एक बहुत का उपयोग करता है unbox<string>(value) के बजाय string value । यहाँ पूर्ण लाभ क्या है? क्या हम अंतर छिपाने के लिए इनलाइन फ़ंक्शन का उपयोग कर सकते हैं? कुछ Fable.Core.JsInterop सामान भी हैं जैसे: !!e?value <> !!value then e?value जिसे अलग-अलग सर्वर साइड से संभालने की आवश्यकता है।

Feliz.ViewEngine अपने स्वयं के डेटा मॉडल का भी उपयोग करता है क्योंकि ReactElement वापस HTML में पार्स करना इतना आसान नहीं है। इस प्रकार यह अच्छा होगा यदि हम Interop.fs में ViewEngine प्रकार उत्पन्न कर सकें जब !FABLE_COMPILER । ViewEngine प्रकार अभी भी ReactElement से विरासत में मिल सकते हैं, इसलिए हस्ताक्षर समान रहते हैं।

इसलिए मुझे लगता है कि यह संभव है, लेकिन इसके लिए कुछ बदलावों की आवश्यकता होगी और कुछ #if FABLE_COMPILER खुद फेलिज को देने होंगे। लेकिन मैं इस तरह के प्रयास को तब तक शुरू नहीं करूंगा जब तक @ जैद-अजाज पुस्तकालयों के विलय के विचार को सैद्धांतिक रूप से स्वीकृत नहीं कर देते।

ध्यान दें कि इसी तरह के परिवर्तन करने की आवश्यकता है उदाहरण के लिए Feliz.Bulma उदाहरण के लिए unbox<string>(value) का भी उपयोग करता है, लेकिन अगर हम चीजों को कैसे करें इस पर एक आम सिफारिश कर सकते हैं तो निर्भर पुस्तकालय अंततः भी काम करेंगे।

यह देखने के लिए कि जब संभव हो तो हम unbox<string> उपयोग क्यों करते हैं, इस पर विचार करें:

box / unbox संकलन समय पर मिटा दिया जाता है क्योंकि यह जेएस है।

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 में एक महत्वपूर्ण पुनर्लेखन शामिल होगा, मुझे लगता है कि यह इस काम को करने का एक उपयुक्त समय है, जबकि हम ऊपर उल्लिखित अन्य मुद्दों @ जैद-अजाज को ठीक करते हैं। हम ऐसा करना चाहते हैं (मुझे लगता है कि यह कहना बहुत सुरक्षित है कि @ जैद-अजाज एसएसआर के खिलाफ नहीं हैं, जितना कि माँ की स्पेगेटी को उसके कोड बेस पर फैलाने के खिलाफ है), और मुझे विश्वास है कि यह कम से कम दर्दनाक होगा /messy अगर यह उस अवधि के दौरान गेट-गो से SSR को ध्यान में रखकर किया गया है।