Feliz: फ़ेलिज़ को एक अमूर्त एपीआई बनाएं

को निर्मित 19 दिस॰ 2020 · 15टिप्पणियाँ · स्रोत: Zaid-Ajaj/Feliz

मैं एक ब्रेकिंग बदलाव का प्रस्ताव देने वाला हूं, लेकिन उम्मीद है कि पैकेज को अपडेट करने के लिए केवल अंतिम उपयोगकर्ताओं और लाइब्रेरी लेखकों की आवश्यकता होगी और कोई वास्तविक कोड परिवर्तन नहीं होगा।

F# UI घोषित करने के लिए एक बेहतरीन भाषा है
प्रत्येक F# डेवलपर जो वेब से संबंधित कुछ करता है, UI घोषित करने के लिए अपना स्वयं का DSL लिखता है
रिएक्ट वेब यूआई घोषित करने के लिए फेलिज एक बेहतरीन एपीआई/डीएसएल है

क्या होगा अगर हम 3 से "प्रतिक्रिया" हटा दें? यह कई मुद्दों को हल कर सकता है:

फ़ेलिज़ एक मानक बन सकता है और ऊपर दी गई सूची में 2 हल कर सकता है। इसलिए फ़ेलिज़ के साथ लिखे गए अधिकांश घटकों को स्वचालित रूप से विभिन्न प्रतिपादन इंजनों के साथ उपयोग किया जा सकता है
यह #285 में चर्चा के अनुसार Fable.React निर्भरता से भी बच सकता है (Fable.React संगतता बनाए रखने के लिए IViewElement को लागू करेगा)
यह Fable.React की तरह हर जगह #if FABLE_COMPILER का उपयोग किए बिना सर्वर-साइड फ़ेलिज़ रेंडरर को लिखना भी आसान बना सकता है।
ऐसा हो सकता है कि कोई व्यक्ति सीधे Fable में फ्रंटएंड रेंडरर लिख रहा हो। यह बहुत अच्छा होगा अगर यह सिर्फ Feliz का उपयोग कर सके

लिफ्ट पिच के साथ, अगर आपको लगता है कि यह एक अच्छा कदम है तो हम कार्यान्वयन पर चर्चा कर सकते हैं। मैंने अभी तक कुछ भी करने की कोशिश नहीं की है, इसलिए यह सुनिश्चित नहीं है कि यह कैसे काम कर सकता है लेकिन मेरे मन में कुछ ऐसा है:

type IViewElement = interface end
type IViewProp = interface end

// Later renderers can inherit these interfaces
type ReactElement = inherit IViewElement

// The basic renderer interface contains few methods
type IHTML =
    abstract renderNative: tagName: string * props: IViewProp seq

// Most of the helpers would be extensions to the interface
type IHTML with
    member this.div(props: IViewProp seq) = this.renderNative("div", props)
    ...

// Then we have different implementations
module Feliz.React

type ReactHTML() =
    interface IHTML with
        member _.RenderNative(tag, props, children) = ...

let Html = Feliz.ReactHTML()

// Consumer code
open Feliz.React

Html.div [...]

सुनिश्चित नहीं है कि इंटेलिजेंस कैसे काम करेगा, शायद हमें एक इंटरफ़ेस के बजाय एक अमूर्त वर्ग का उपयोग करने की आवश्यकता है, लेकिन मुझे आशा है कि आपको यह विचार मिल जाएगा। तुम क्या सोचते हो?

स्रोत

alfonsogarciacaro

सबसे उपयोगी टिप्पणी

@alfonsogarciacaro यह अद्भुत लग रहा है। जैसा कि #262 में उल्लेख किया गया है, केवल एक चीज जिसे मैं वास्तव में याद करता हूं, वास्तव में Fable.React से Feliz पर स्विच करने के बाद से 'यह सिर्फ काम करता है' SSR है। Feliz और Feliz.ViewEngine दोनों ही अद्भुत परियोजनाएं हैं, लेकिन दो अलग-अलग प्रोजेक्ट होने से कोड का पुन: उपयोग करना मुश्किल हो जाता है, क्योंकि कोड का कोई भी टुकड़ा जो ifdefs का उपयोग करता है, केवल अन्य कोड द्वारा उपयोग किया जा सकता है जो ifdefs का उपयोग करता है - केवल जेएस के लिए साइलो बनाना, डॉटनेट- केवल और दोनों-दुनिया-कोड। कुछ भी जो उस अंतर को बंद करता है, निश्चित रूप से फेलिज और .Net सर्वर के साथ काम करते समय जीवन की गुणवत्ता में सुधार करेगा।

l3m 2 मार्च 2021

👍2

सभी 15 टिप्पणियाँ

हाय @alfonsogarciacaro , आपके साथ ईमानदार होने के लिए, मुझे ऐसा नहीं लगता कि यह एक अच्छा विचार है। सैद्धांतिक रूप से यह निश्चित रूप से समझ में आता है: आइए Fable में HTML के लिए एक मानक API बनाएं। व्यवहार में, यह बहुत अच्छी तरह से अनुवाद नहीं करता है। यहां कुछ कारण बताए गए हैं:

वर्तमान एपीआई मानक के अलावा कुछ भी है, वास्तव में यह बहुत ही राय है। बहुत से लोग अभी भी पूरी एकल सूची और prop.children चीज़ को पसंद नहीं करते हैं जो कि बिल्कुल ठीक है।
वर्तमान एपीआई को "सरल" बनाया गया है क्योंकि यह धारणा है कि यह केवल प्रतिक्रिया है: इसे अमूर्त करने के लिए बहुत सारे काम की आवश्यकता होगी जहां फेलिज-शैली एपीआई लिखने/डुप्लिकेट करने का विकल्प शायद आसान समाधान होगा।
मैं संसाधनों को पतला करने के बजाय रिएक्ट के आसपास टूलिंग में सुधार करने पर ध्यान केंद्रित करूंगा: फ़ेलिज़ "किया" से बहुत दूर है, दस्तावेज़ीकरण, नमूना अनुप्रयोगों, बेहतर परीक्षण कहानी आदि के बारे में अभी भी बहुत कुछ करना बाकी है।

Zaid-Ajaj 19 दिस॰ 2020

उत्तर @Zaid के लिए बहुत बहुत धन्यवाद! मैं आपके तर्क को समझता हूं, यह अभी भी अफ़सोस की बात है कि हमारे पास इतने सारे प्रतिस्पर्धी डीएसएल हैं लेकिन हो सकता है कि अन्य समाधान भी हों जैसा आप कहते हैं। अगर मुझे समय मिलता है तो मैं किसी भी तरह से एक प्रोटोटाइप लिखने की कोशिश करूंगा कि यह कैसे काम करेगा।

alfonsogarciacaro 19 दिस॰ 2020

👍1

BTW, मैंने यहाँ कुछ काम शुरू किया है: https://github.com/alfonsogarciacaro/Feliz.Engine/blob/main/src/HtmlEngine.fs

मैंने इसका परीक्षण नहीं किया है, लेकिन मैंने सभी unbox और इसी तरह की चाल को हटा दिया है, इसलिए सिद्धांत रूप में इसे किसी भी रेंडरर के साथ काम करना चाहिए जो इस इंटरफ़ेस को लागू @dbrattli Feliz.ViewEngine के साथ संयोजित करने का प्रयास करना और यह देखना कि क्या यह SSR को Feliz के साथ सरल बनाता है।

alfonsogarciacaro 20 जन॰ 2021

कुछ चीजें हैं जिन्हें समझने/विचार करने की आवश्यकता होगी:

IntelliSense

मैं बहुत खुश नहीं हूं कि मेरी इंटेलिजेंस फंकी दिखेगी क्योंकि Html को फेलिज में परिभाषित किया जाएगा:

let Html = HtmlEngine(renderer)

हालांकि यह मामूली मसला ज्यादा है।

बंडल का आकार

हम स्पष्ट रूप से चाहते हैं कि यह वैसा ही हो जैसा वर्तमान में है (या बेहतर)। शायद Feliz.HtmlEngine में एक प्लगइन जो कंपाइलर निर्देशों में लपेटा गया है? हालांकि यह समाधान वेब सर्वरों को Fable पर निर्भरता बना देगा।

अन्य पुस्तकालय

SSR के साथ सबसे बड़े मुद्दों में से एक जैसा कि वर्तमान में किया गया है, ज्यादातर मामलों में अन्य पुस्तकालय बस काम नहीं करेंगे, और जो करते हैं (जैसे Feliz.Bulma / Feliz.Bulma.ViewEngine ) को तब तक समायोजन की आवश्यकता होती है जब तक कि उन्हें भी समायोजन की आवश्यकता न हो दोनों के संदर्भ के लिए एक सार एपीआई बनाएं जो यह है।

वैकल्पिक

मुझे लगता है कि यहां मूल समस्या यह है कि जब हम इच्छित पहले पेंट का पूरी तरह से अनुकरण करना चाहते हैं तो एसएसआर स्वयं करने की कोशिश करना संभव नहीं है। हमें वास्तव में .NET के लिए ReactDOMServer जैसा कुछ चाहिए। मैंने वास्तव में इसमें बहुत गहराई तक नहीं खोला है, लेकिन क्या React.NET (शायद एक एफ # रैपर के साथ) आगे बढ़ने का एक बेहतर तरीका होगा?

Shmew 21 जन॰ 2021

टिप्पणियों के लिए बहुत बहुत धन्यवाद @Shmew और देर से उत्तर देने के लिए खेद है:

इंटेलिजेंस : हम्म, मैंने केवल सार एपीआई के साथ एक साधारण उदाहरण लिखा था लेकिन स्वत: पूर्णता के साथ कोई समस्या नहीं देखी। मैं फिर से जाँच करने की कोशिश करूँगा। एक स्थिर प्रकार तक पहुँचने के बजाय उपयोगकर्ता एक मूल्य तक पहुँचते हैं। मुझे लगता है कि यह ठीक होना चाहिए और कई मामलों में कोड को बदलने की आवश्यकता नहीं होगी। मुख्य दोष शायद यह होगा कि open type उपयोग नहीं किया जा सकता है।
बंडल का आकार : मुझे इसे भी जांचना होगा। मेरी आशा है कि यह बहुत अधिक नहीं बदलता है क्योंकि कक्षा के सदस्यों को फैबल द्वारा अलग किए गए कार्यों के रूप में संकलित किया जाता है जिन्हें पेड़ हिलाया जा सकता है और अच्छी तरह से छोटा भी किया जा सकता है। हालांकि दुर्भाग्य से जनरेट किया गया कोड उतना अच्छा नहीं लगेगा, जितना अब #284 . के बाद है
अन्य पुस्तकालय : हां, अमूर्त एपीआई से लाभ प्राप्त करने के लिए अन्य पुस्तकालयों को अनुकूलित करना होगा। उम्मीद है कि न्यूनतम बदलाव के साथ।
विकल्प : टीबीएच, मैं वास्तव में नहीं जानता कि रिएक्ट के साथ एसएसआर कैसे काम करता है, हालांकि फैबल में (योगदान) कोड को देखते हुए। यह बहुत जटिल नहीं दिखता है (मूल रूप से जेनरेट किए गए एचटीएमएल टैग में कुछ मेटाडेटा जोड़ना) इसलिए सुनिश्चित नहीं है अगर React.NET जैसी किसी चीज़ का उपयोग करना आसान है या नहीं। मुझे लगता है कि यह फेलिज के साथ प्रयोग करने योग्य नहीं होगा, क्योंकि फेलिज में फैबल ट्रिक्स (मुख्य रूप से असुरक्षित कास्ट) शामिल हैं जो .NET में फेंक देंगे।

वास्तव में, इसके लिए मैं न केवल SSR में बल्कि _beyond React_:wink: में भी सोच रहा हूँ, उदाहरण के लिए F# सर्वर में html जनरेटर के लिए जिन्हें रिएक्ट के साथ संगत होने की आवश्यकता नहीं है और मामले में हम अन्य रेंडरर्स का उपयोग करना चाहते हैं अग्रभाग के लिए प्रतिक्रिया करें।

alfonsogarciacaro 27 जन॰ 2021

टिप्पणियों के लिए बहुत बहुत धन्यवाद @Shmew और देर से उत्तर देने के लिए खेद है

आपका स्वागत है, और कोई चिंता नहीं!

इंटेलिजेंस: हम्म, मैंने केवल सार एपीआई के साथ एक साधारण उदाहरण लिखा है लेकिन स्वत: पूर्णता के साथ कोई समस्या नहीं देखी। मैं फिर से जाँच करने की कोशिश करूँगा। एक स्थिर प्रकार तक पहुँचने के बजाय उपयोगकर्ता एक मूल्य तक पहुँचते हैं। मुझे लगता है कि यह ठीक होना चाहिए और कई मामलों में कोड को बदलने की आवश्यकता नहीं होगी। मुख्य दोष शायद यह होगा कि खुले प्रकार का उपयोग नहीं किया जा सकता है।

क्षमा करें, मैं सुपर स्पष्ट नहीं था। Intellisense ठीक है, बल्कि तथ्य यह है कि Html एक अलग रंग होगा। जैसा मैंने कहा, वास्तव में मामूली । तथ्य यह है कि हम open type में सक्षम होने के कारण खो देते हैं वास्तव में एक बड़ा सौदा है। मुझे पता है कि कुछ वास्तव में पसंद करते हैं कि सब कुछ नेमस्पेस करने के लिए।

बंडल का आकार: मुझे यह भी जांचना होगा। मेरी आशा है कि यह बहुत अधिक नहीं बदलता है क्योंकि कक्षा के सदस्यों को फैबल द्वारा अलग किए गए कार्यों के रूप में संकलित किया जाता है जिन्हें पेड़ हिलाया जा सकता है और अच्छी तरह से छोटा भी किया जा सकता है। हालांकि दुर्भाग्य से जनरेट किया गया कोड उतना अच्छा नहीं लगेगा, जितना अब #284 . के बाद है

मुझे यह भी नहीं पता था कि इंटरऑप फ़ंक्शन पहले से ही इनलाइन नहीं थे, मैं उन्हें पहले से ही अपने पुस्तकालयों में इनलाइन कर चुका हूं। मैं इस तथ्य के बारे में अधिक बात कर रहा था कि पूरे Html मॉड्यूल में कोई बंडल आकार वृद्धि नहीं है, अगर यह जेएस में मूल रूप से किया गया था क्योंकि यह सिर्फ एक इनलाइन रैपर है। एक ठोस वर्ग के साथ जो अब मामला नहीं बनता।

अन्य पुस्तकालय: हां, अमूर्त एपीआई से लाभ प्राप्त करने के लिए अन्य पुस्तकालयों को अनुकूलित करना होगा। उम्मीद है कि न्यूनतम बदलाव के साथ।

इसके साथ मुद्दा यह है कि मूल प्रतिक्रिया कोड का उपयोग करने वाले पुस्तकालय ठीक से काम नहीं कर सकते क्योंकि सभी आंतरिक केवल जेएस हैं।

विकल्प: टीबीएच, मैं वास्तव में नहीं जानता कि रिएक्ट के साथ एसएसआर कैसे काम करता है, हालांकि फैबल में (योगदान) कोड को देखते हुए। यह बहुत जटिल नहीं दिखता है (मूल रूप से जेनरेट किए गए एचटीएमएल टैग में कुछ मेटाडेटा जोड़ना) इसलिए सुनिश्चित नहीं है अगर React.NET जैसी किसी चीज़ का उपयोग करना आसान है या नहीं। मुझे लगता है कि यह फेलिज के साथ प्रयोग करने योग्य नहीं होगा, क्योंकि फेलिज में फैबल ट्रिक्स (मुख्य रूप से असुरक्षित कास्ट) शामिल हैं जो .NET में फेंक देंगे।

हाँ, यह साधारण मामलों के लिए काम करता है, लेकिन यदि आप Feliz.MaterialUI में कुछ घटकों की तरह अधिक जटिल चीजों का उपयोग करने का प्रयास करते हैं तो यह काम नहीं करेगा। जो मैं समझता हूं, नोड.जेएस पर किए जाने पर रिएक्ट एसएसआर बहुत सरल है क्योंकि वे वास्तव में एक पूर्ण स्ट्रिंग को थूकने के लिए ReactDOMServer चला सकते हैं जो पृष्ठ का पहला पेंट है। मेरी समझ यह है कि React.NET ठीक ऐसा करने के लिए सिर्फ एक नोड.जेएस प्रक्रिया को लपेट रहा है।

मुझे संदेह है कि यह वास्तव में फ़ेलिज़ कोड के साथ बहुत आसान होगा क्योंकि यह पहले से ही इस तरह की चीजों का समर्थन करता है। प्रक्रिया कुछ इस प्रकार होगी:

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

प्रतिक्रिया से परे

यह एक महान बिंदु है, और निश्चित रूप से कुछ ऐसा है जो मैं चाहता हूं अगर मैं शुद्ध HTML को बिना प्रतिक्रिया या कुछ भी प्रस्तुत करना चाहता हूं।

Shmew 27 जन॰ 2021

👍1

मैंने इस विचार के साथ प्रयोग किया है, आप मेरी प्रगति यहाँ देख सकते हैं: https://github.com/alfonsogarciacaro/Feliz.Engine

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

इसे अन्य फ्रंटएंड फ्रेमवर्क के साथ प्रयोग करें, जैसे सुतिल: https://github.com/davedawkins/Sutil/pull/15
SASS के बजाय CSS उत्पन्न करने के लिए इसका उपयोग करें: https://github.com/alfonsogarciacaro/Feliz.Engine/blob/main/samples/Feliz.Css/Feliz.Css.fs
स्थिर एचटीएमएल उत्पन्न करने के लिए इसका इस्तेमाल करें: https://github.com/alfonsogarciacaro/Feliz.Engine/blob/main/samples/Feliz.StaticHtml/Feliz.StaticHtml.fs
Snabbdom जैसे अन्य वर्चुअल-डोम कार्यान्वयन के साथ इसका उपयोग करें: https://github.com/alfonsogarciacaro/Feliz.Engine/blob/main/samples/Feliz.Snabbdom/Feliz.Snabbdom.fs

ये सभी मसौदे हैं लेकिन वे काम कर रहे हैं और आप देख सकते हैं कि उन्हें बहुत कम कोड की आवश्यकता है। इससे भी महत्वपूर्ण बात यह है कि वे सभी उपयोगकर्ताओं को एक प्रलेखित और परिचित एपीआई प्रदान करते हैं, जो एक्स्टेंसिबल भी है: उदाहरण के लिए आप आसानी से एक बुल्माइंजिन बना सकते हैं जो इन सभी (और भविष्य) ऐप्स के साथ संगत है। 2 और 3 के मामले में मैं Fable का उपयोग कर रहा हूं क्योंकि वृद्धिशील संकलन .NET की तुलना में बहुत तेज है लेकिन Feliz.Engine .NET के साथ संगत है (मैंने सभी unbox हटा दिए हैं) इसलिए यह छोटा होना चाहिए उन्हें F# .NET सर्वर के साथ संगत बनाने के लिए, और उम्मीद है कि HTML जनरेटर को प्रतिक्रिया-संगत बनाने के लिए भी अधिक काम की आवश्यकता नहीं होनी चाहिए।

आपको क्या लगता है @ जैद-अजाज? मैंने पहले से ही वर्तमान फेलिज रिएक्ट एपीआई को बदलने के विचार को छोड़ दिया है लेकिन क्या आपको लगता है कि ऐसा कुछ "फेलिज परिवार" (शायद इस रेपो में) से संबंधित होना चाहिए? क्या आप नाम के साथ ठीक हैं, या आप कुछ और इस्तेमाल करेंगे?

alfonsogarciacaro 23 फ़र॰ 2021

❤1

हाय @alfonsogarciacaro , मैं इस सप्ताह कभी-कभी इन नमूनों में एक गहरा गोता

Zaid-Ajaj 23 फ़र॰ 2021

👍1

नमस्ते,

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

MangelMaxime 23 फ़र॰ 2021

हां, एक प्रभाव की उम्मीद है, सवाल यह है कि यह कितना बड़ा है :) मैं उम्मीद कर रहा हूं कि मध्यम-बड़े ऐप्स के लिए बहुत ध्यान देने योग्य नहीं है, लेकिन निश्चित रूप से दोनों शैलियों में फुलमा-डेमो जैसा कुछ होना अच्छा होगा, इसलिए हम तुलना कर सकते हैं और अनुकूलन अवसरों का परीक्षण करने के लिए उपयोग कर सकते हैं। यह जांचना भी दिलचस्प होगा कि फ़ेलिज़ हेल्पर्स बंडल आकार को कैसे प्रभावित करते हैं या नहीं। अभी, फ़ेलिज़ द्वारा उत्पन्न कोड काफी अच्छा है और संकलित JSX जैसा दिखता है, लेकिन कार्यों को छोटा किया जा सकता है, इसलिए यह .createElement("div") जैसी कई कॉलों के दोहराव को कम करने का एक तरीका हो सकता है (सुनिश्चित नहीं है कि gzip संपीड़ित कर सकता है या नहीं हालांकि ये कॉल)।

alfonsogarciacaro 24 फ़र॰ 2021

हाँ, मैं कल्पना नहीं कर सकता कि कोई भी अन्य परियोजनाओं में इस अद्भुत एपीआई/शैली का उपयोग करने में सक्षम होने का विरोध करेगा। मेरी एकमात्र वास्तविक चिंता यह थी कि क्या यह इस पुस्तकालय की गुणवत्ता को प्रभावित करेगा, और कुछ एर्गोनोमिक मुद्दे जिन्हें मैंने ऊपर उल्लिखित किया है।

Shmew 24 फ़र॰ 2021

👍1

हाय @alfonsogarciacaro , मैंने उदाहरण कोड पर एक अच्छी नज़र

CssEngine CSS उत्पन्न करता है, इसका क्या लाभ है, केवल CSS/SASS टूलचेन या CSS-in-JS जैसे फ़ेलिज़ में निर्मित या FSS या इमोशन जैसे अन्य CSS-in-JS libs का उपयोग करने के विपरीत। एफ # से सीएसएस उत्पन्न करना अपने आप काम करेगा लेकिन ऐसा कुछ नहीं है जिसे मैं फेलिज के साथ उपयोग करूंगा क्योंकि मौजूदा टूलचेन पर भरोसा करना बेहतर विकल्प होगा (यदि आप नहीं चाहते हैं कि Fable/F # कंपाइलर धीमा हो जाए तो भी तेज़ संकलन समय होगा विशाल स्टाइलशीट संकलित करने के लिए) वर्तमान में मैं Feliz/React घटकों के लिए CSS मॉड्यूल का उपयोग करने के पक्ष में हूं
स्थिर html इंजन: फ़ेलिज़ पहले से ही नोड और ब्राउज़र में ReactDOM का उपयोग करके स्थिर html उत्पन्न करता है। Feliz.ViewEngine डॉटनेट में स्थिर HTML उत्पन्न करने के लिए समान करता है। मुझे पता है कि एपीआई को साझा करने का विचार है, लेकिन यह अन्य चुनौतियों से मुश्किल हो गया है जैसा कि @ शमू ने उल्लेख किया है: तीसरे-आंशिक रूप से पुस्तकालयों को दोनों को लागू करने के लिए, उत्पन्न कोड को प्रभावित करता है जो अब वास्तव में साफ है। यह विशेषताओं, शैलियों और बच्चों को एक सूची में मिलाता है जो फ़ेलिज़ के वर्तमान एपीआई को तोड़ता है।
Snabbdom इंजन: दिलचस्प उदाहरण है लेकिन इसमें रिएक्ट की तरह पुस्तकालयों का पारिस्थितिकी तंत्र नहीं है।

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

Zaid-Ajaj 25 फ़र॰ 2021

नमूनों की जांच करने के लिए बहुत बहुत धन्यवाद @ जैद-अजाज! मैं आपकी ईमानदारी की सराहना करता हूं। Feliz.Engine को संभावित उपयोगों के लिए अनुकूलित करना कितना आसान/कठिन था (मुद्रण करने के लिए कोड केवल 50 लाइनें है) यह जांचने के लिए सीएसएस और एचटीएमएल प्रिंटर केवल त्वरित उदाहरण थे। मैंने Fable & नोड का उपयोग किया क्योंकि वृद्धिशील संकलन बहुत तेज़ है, लेकिन "सिद्धांत रूप में" इसे .net पर अनुकूलित करना आसान होना चाहिए। Snabbdom एडेप्टर का मतलब एक और त्वरित उदाहरण भी था, लेकिन मैं वास्तव में पसंद करना शुरू कर रहा हूं, हालांकि यह एक और मामला है :)

वैसे भी, मैंने अंततः महसूस किया है कि परिवर्तनों को तोड़े बिना वर्तमान फ़ेलिज़ रिएक्ट ऐप्स को अमूर्त करना संभव नहीं है (जैसा कि आप शुरुआत से कह रहे थे ) तो चलिए इसे उन उपयोगकर्ताओं के लिए एक समानांतर परियोजना के रूप में रखते हैं जो अन्य रेंडरर्स के साथ प्रयास करना चाहते हैं एक फेलिज जैसा एपीआई

alfonsogarciacaro 27 फ़र॰ 2021

❤1

l3m 2 मार्च 2021

👍2

हां। यह एक अच्छा उपयोग मामला होगा। हालांकि यह मुश्किल है क्योंकि अंत में Feliz.Engine में Feliz के साथ कुछ मतभेद हैं , जिसका अर्थ है कि हमें Feliz.Engine React कार्यान्वयन लिखना होगा जो Feliz के साथ प्रतिस्पर्धा करेगा, कुछ ऐसा जिसे मैं टालना चाहता हूं;) लेकिन उम्मीद है कि हम एक पा सकते हैं समाधान।

alfonsogarciacaro 3 मार्च 2021

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स