Feliz: फेलिज के साथ मेरी यात्रा | Fable.React और Feliz के बीच तुलना

बढ़िया विश्लेषण।

मेरे लिए व्यक्तिगत रूप से, भले ही दोहरी सूची स्वरूपण कभी-कभी एक दर्द होता है, मुझे लगता है कि Fable.React कोड को देखकर मुझे अंतर्निहित html की संरचना बेहतर दिखाई देती है। यह div है [.., Html.div नहीं [... (आदि)। यह कोई बड़ी बात नहीं है, लेकिन ऐसा लगता है कि मेरे दिमाग में Fable को पार्स करना आसान है।प्रतिक्रिया।

बढ़िया लेखन @MangelMaxime , आपने बहुत अच्छे अंक बनाए हैं।

मैंने जो कुछ भी इकट्ठा किया है, उसमें से ज्यादातर मुद्दे हैं कि पुस्तकालय कैसे बढ़ाया जाता है, और समस्याएं जो बेहतर तरीके से नहीं होने पर होती हैं।

मैं निश्चित रूप से सहमत हो सकता हूं कि Feliz लिए पुस्तकालय लिखना डेवलपर पर बहुत अधिक काम करता है, लेकिन मेरी राय में यह प्रयास के लायक है जब परिणामी एपीआई का उपयोग करना बहुत अच्छा होता है।

मैंने Feliz लिए उचित संख्या में एक्सटेंशन लिखे हैं, इसलिए मुझे लगता है कि मैं इन मुद्दों को कम करने के बारे में कुछ जानकारी प्रदान कर सकता हूं:

भार के

मैं विजुअल स्टूडियो का उपयोग करता हूं और मुझे यह पता लगाने में शून्य समस्याएं हैं कि मेरे लिए कौन से अधिभार उपलब्ध हैं, शायद यह कुछ ऐसा है जिसे आयनाइड के अंत में सुधारा जा सकता है?

हम केवल 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 मैं बहुत सी चीजें करता हूं जहां दिए गए कॉन्फ़िगरेशन के आधार पर मैं वास्तविक कोड की तरह दिखने के लिए इसे ठीक से अनुवाद करने के लिए उपयोगकर्ता इनपुट को संशोधित/एकत्र/बदल दूंगा। हमेशा मौजूद चीजों को हटाने के लिए कुछ मायनों में यह वास्तव में अच्छा है।

निष्कर्ष

मुझे लगता है कि "फेलिज़" तरीके से अपने स्वयं के पुस्तकालयों को लिखने के तरीके पर नेविगेट करने के तरीके पर बेहतर दस्तावेज़ीकरण के साथ आपके द्वारा किए गए अधिकांश दर्द को हल किया जा सकता है। हो सकता है कि @ जैद-अजाज और मैं भविष्य में उस पर काम कर सकें।

धन्यवाद @ l3m

मेरे लिए व्यक्तिगत रूप से, भले ही दोहरी सूची स्वरूपण कभी-कभी एक दर्द होता है, मुझे लगता है कि Fable.React कोड को देखकर मुझे अंतर्निहित html की संरचना बेहतर दिखाई देती है। यह div है [.., Html.div नहीं [... (आदि)। यह कोई बड़ी बात नहीं है, लेकिन ऐसा लगता है कि मेरे दिमाग में Fable को पार्स करना आसान है।प्रतिक्रिया।

वास्तव में, कोड को पढ़ने का तरीका बदलना आसान नहीं है और इसलिए मैंने उल्लेख किया है कि हमें इसे HTML के रूप में नहीं देखना चाहिए मेरे मामले में इसने मुझे स्विच करने में मदद की है।

मुझे लगता है कि एफ # 5 और "स्थिर वर्ग खोलने" की क्षमता के साथ फेलिज Html.div और div सिंटैक्स दोनों का समर्थन करने में सक्षम होंगे, इस पर निर्भर करता है कि आप एचटीएमएल क्लास खोलते हैं या नहीं।

टिप्पणी के लिए @Shmew धन्यवाद और वास्तव में मैं भूल गया कि फ़ेलिज़ के लिए कई प्रकार के "पुस्तकालय" हैं।

"अमान्य कोड लिखने" के बारे में हाँ, लेकिन कुछ पुस्तकालयों में, हम फुल्मा स्थिति से बचने के लिए IReactProperty प्रकार को "विस्तारित" करना चाहते हैं जहाँ आपको Props जैसे विशेष सहायक के माध्यम से मानक गुणों को पारित करने की आवश्यकता होती है।

वे केवल कोड हैं जो HTML तत्व में डिफ़ॉल्ट रूप से कक्षा को इंजेक्ट करते हैं।

Bulma.button <div class="button"> उत्पन्न करता है

एक पुस्तकालय के मामले में जो "वास्तविक" घटकों पर काम करता है (क्षमा करें, यह नहीं पता कि इसे अलग तरीके से कैसे नाम दिया जाए) आपका समाधान वास्तव में सही है। उदाहरण के लिए, यह Fable.ReactLeaflet द्वारा लिया गया दृष्टिकोण है जहां मैं प्रत्येक घटक के लिए विशिष्ट गुणों को परिभाषित कर रहा हूं। और इस प्रकार घटकों को सभी मानक HTML गुणों का समर्थन करने की आवश्यकता नहीं है।

"कॉलबैक" के लिए आपके समाधान के बारे में यह मेरे लिए काम नहीं करता है। लेकिन फैबल द्वारा पारित समारोह में तर्क-वितर्क थे और जब तक मैं myFunction(arg1)(arg2) जैसा कुछ नहीं लिखना चाहता था, तब मुझे System.Func माध्यम से अनिश्चित संस्करण को मजबूर करना पड़ा।

यदि आप जानते हैं कि इसे कैसे काम करना है, तो मुझे इसे ठीक करने के लिए https://github.com/fable-compiler/repl/pull/108/files पर भेजे गए पीआर को देखकर खुशी होगी।

हाय @MangelMaxime ,

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

मैं वास्तव में इस तरह की प्रतिक्रिया और खुलेपन की सराहना करता हूं और मानता हूं कि इस पुस्तकालय को अपने पारिस्थितिकी तंत्र के साथ सबसे अच्छा बनाने के लिए यह महत्वपूर्ण है: प्रार्थना करें:

मैं एक पल में फेलिज.बुल्मा के बारे में बात करूंगा क्योंकि मुझे लगता है कि यह पारिस्थितिकी तंत्र में विशेष है, पहले मैं आपके कुछ मुद्दों का उत्तर दूंगा जो पुस्तकालय में बदलाव के बिना पहले से ही तय किए जा सकते हैं।

onChange ओवरलोड

आपको यह कहना होगा कि आप किस प्रकार का ईवेंट स्पष्ट रूप से चाहते हैं।

दरअसल, आप नहीं। इस प्रकार को आपके संदेश प्रकार से निम्नानुसार अनुमानित किया जाना चाहिए:

prop.onChange (ChangeGistToken >> dispatch)

ChangeGistToken के प्रकार के आधार पर, सही अधिभार का अनुमान लगाया जाएगा। जब डीयू का मामला ChangeGistToken of string तो string -> unit का अधिभार चुना जाएगा। लेकिन यह FileSelected of File भी हो सकता है जब इनपुट प्रकार file हो तो उस स्थिति में ओवरलोड File -> unit का अनुमान लगाया जाएगा और इसी तरह आगे भी। आपको ev.Value से Fable.React ev.Value की सिंटैक्स चीनी की आवश्यकता नहीं है

prop.oncheckedChange हटा दिया जाएगा क्योंकि onChange पहले से ही बूलियन केस को हैंडल करता है

बहु-तर्क कॉलबैक

@Shmew पहले ही इस मुद्दे को छू चुका है और वास्तव में इस प्रकार की संपत्तियों को हल करने का यही तरीका है। यह समझना महत्वपूर्ण है कि फ़ेलिज़ एक्सटेंशन को लागू करते समय, आप संपत्ति सेट करने से पहले परिवर्तन कर सकते हैं:

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 द्वारा प्रदान किए गए संस्करण की तुलना में अधिक स्पष्ट संस्करण है (जैसा कि आप बाइंडिंग के साथ जानते हैं, आपको उन्हें सही करने के लिए हमेशा उनके साथ थोड़ा खेलना होगा)। इसका एक कामकाजी उदाहरण यहां है

फेलिज इकोसिस्टम में टाइप-सेफ्टी

जैसा कि @Shmew ने ऊपर उल्लेख किया है: एक उचित फ़ेलिज़ एक्सटेंशन आपको कोड लिखने की अनुमति नहीं देता है जो गलत तरीके से व्यवहार करता है और गुणों के प्रकारों को बाधित करने से आप इसे लागू कर सकते हैं। आप या तो ऐसी संपत्तियों का निर्माण कर सकते हैं जो फेलिज की तरह IReactProperty लौटाती हैं। रीचार्ट्स करता है जो prop में मौजूदा गुणों के साथ पिछड़ा-संगतता की अनुमति देता है या आप समर्थन के लिए एक अधिक विशिष्ट प्रकार 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 लागू होने से पहले, मेरे दिमाग में यह विचार था कि CSS-only फ्रेमवर्क के लिए Feliz एक्सटेंशन बनाने की कोई आवश्यकता नहीं है । फ़ेलिज़ कई वर्ग नामों को लिखना और सशर्त रूप से उनके साथ काम करना पहले से ही बहुत आसान बनाता है। अब F# में निहित yield साथ यह और भी आसान है। इसे TypedCssClasses के साथ संयोजित करें और आप किसी भी CSS-only फ्रेमवर्क को लागू करने की आवश्यकता को हटा दें। शून्य कार्यान्वयन और रखरखाव लागत। बस टाइप की गई स्टाइलशीट का उपयोग करें और स्वयं एक दस्तावेज़ीकरण वेबसाइट बनाने के बजाय प्रोजेक्ट के पहले से ही वास्तव में अच्छे दस्तावेज़ीकरण का उपयोग करें।

हालाँकि, जब मैंने @Dzoukr द्वारा Feliz.Bulma के कार्यान्वयन को देखा तो यह समझ में आया: आप Bulma के एक मॉड्यूल से CSS घटकों के लिए विशिष्ट "प्रवेश बिंदु" पेश करके कोड को बहुत सरल बना सकते हैं ताकि आपको Bulma.button , Bulma.card आदि। ये वास्तव में उपयोग करने के लिए अच्छे हैं। जहां तक ​​संशोधक का सवाल है, मुझे लगता है कि रोमन के दृष्टिकोण का पालन करना और उसके साथ काम करना आसान है, लेकिन जैसा आपने कहा, कभी-कभी यह दिलचस्प परिणाम दे सकता है। निश्चित रूप से, उस विभाग में सुधार करने के लिए और भी बहुत कुछ है और किसी भी मामले में मुझे लगता है कि रोमन ने फेलिज के दृष्टिकोण का अनुसरण करते हुए कुछ सीखने और उपयोग करने में आसान बनाने में बहुत अच्छा काम किया।

Feliz . का पैकेज प्रबंधन

मैं केवल वर्तमान Fable.React और Feliz में एक बड़ा अंतर बताना चाहता हूं: पैकेज संस्करण और प्रबंधन। फ़ेलिज़ संस्करण इसके सभी पारिस्थितिक तंत्र पुस्तकालय हैं, फेमटो- संगत हैं जो उपयोगकर्ताओं के बोझ को आवश्यक एनपीएम पैकेजों को मैन्युअल रूप से स्थापित करने या यह जानने के लिए कि वे किस संस्करण के साथ संगत हैं, के बोझ को हटाते हैं। यह कई के विपरीत है यदि सभी व्युत्पन्न Fable.React पुस्तकालय नहीं हैं और यहां तक ​​कि Fable.React भी जहां ऐसा नहीं है।

भविष्य की योजनाएं

• फ़ेलिज़-शैली के एक्सटेंशन कैसे बनाएं और किसका पालन करना चाहिए, इस पर प्रलेखन (और भी अधिक)।
• फ़ेलिज़ के लिए एक फ़ेलिज़ विश्लेषक का निर्माण करना, लेकिन संभवतः इसके पारिस्थितिकी तंत्र के लिए

दरअसल, आप नहीं। इस प्रकार को आपके संदेश प्रकार से निम्नानुसार अनुमानित किया जाना चाहिए:

prop.onChange (ChangeGistToken >> dispatch)

दरअसल, मैंने इस उपयोग के बारे में नहीं सोचा था।

बहु-तर्क कॉलबैक

@Shmew पहले ही इस मुद्दे को छू चुका है और वास्तव में इस प्रकार की संपत्तियों को हल करने का यही तरीका है।

ओह क्षमा करें, मैंने @Shmew द्वारा प्रदान किए गए स्निपेट का अंत नहीं देखा। मैंने सिर्फ हस्ताक्षर घोषणा देखी और ऐसा था जैसे कोई काम नहीं करता है।

आप दोनों सही हैं, हम संपत्ति के मूल्य को पारित करने से पहले परिवर्तन कर सकते हैं।

फेलिज.बुल्मा का मामला

हाँ, TypedCssClasses ठीक है लेकिन Fulma या Feliz.Bulma की तुलना में यह समान स्तर की सुविधाएँ प्रदान नहीं कर सकता है। क्योंकि सीएसएस फ़ाइल में सब कुछ समाहित नहीं है।

एक और बात यह है कि देव मोड में, हमारे पास हमेशा डिस्क पर फ़ाइल उत्पन्न नहीं होती है और मुझे यकीन नहीं है कि TypedCssClasses इस परिदृश्य का समर्थन करते हैं।

मुझे लगता है कि रोमन ने कुछ आसान सीखने और उपयोग करने के लिए फेलिज के दृष्टिकोण का पालन करने में बहुत अच्छा काम किया।

मैं सहमत हूं, मुझे लगता है कि हमें इसे समान बनाने के लिए फुलमा में किए गए काम को थोड़ा जोड़ने की जरूरत है। जैसा कि मैंने कहा कि हमें उन दोनों के बीच सही बीच का रास्ता खोजने की जरूरत है।

मेरे पास अभी जो अनुपलब्ध विशेषताएं हैं, वे आउटपुट तत्व को नियंत्रित करने और समर्थित रंग के सेट को विस्तारित करने में आसान बनाने की अनुमति दे रही हैं। मुझे नहीं लगता कि इससे इसमें बहुत जटिलता आएगी।

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

धन्यवाद @MangelMaxime - यह एक अच्छी तुलना है। आपने कोड को स्वतः स्वरूपित करने के लिए कहीं भी Fantomas का उल्लेख नहीं किया है - क्या आपके पास Fable.React या Feliz के साथ Fantomas के साथ काम करने का मौका है?
मेरे एक फैबल प्रोजेक्ट में जहां मैं फैंटोमास का उपयोग करता हूं, मैंने आयोनाइड में फाइल सेव पर ऑटो-फॉर्मेटिंग चालू कर दी है और कहना होगा कि यह वास्तव में एक उत्पादकता बूस्टर है - मैन्युअल स्वरूपण के बारे में चिंता करने की कोई आवश्यकता नहीं है!
मुझे सच में लगता है कि फैंटोमास अब अपनी गति प्राप्त कर रहा है और इसे व्यापक रूप से अपनाना पसंद करेगा, वह भी फैबल और रिएक्ट / फेलिज के संयोजन के साथ।

@theimowski मैंने कुछ समय से Fantomas का उपयोग नहीं किया।

ज्यादातर इसलिए कि यह मेरे कोड के साथ खिलवाड़ कर रहा था और इसे पढ़ना वास्तव में कठिन बना रहा था। मेरे अनुभव से लेकर Fable.React और Feliz के साथ अच्छा नहीं खेल रहा था।

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

उदाहरण के लिए, अगर मैं ऐसा कुछ लिखता हूं:

type Test =
    {
        Prop1 : string
    }

मैं चाहता हूं कि यह वैसा ही बना रहे और type Test = { Prop1 : string } न बन जाए क्योंकि यह एक ही लाइन पर फिट हो सकता है।

शायद एक रिकॉर्ड एक अच्छा उदाहरण नहीं है, लेकिन मुझे आशा है कि आप समझ गए होंगे कि मेरा क्या मतलब है :)

@theimowski यह सुनकर बहुत अच्छा लगा, मैं अपनी गैर-कल्पित परियोजनाओं पर कल्पनाओं का उपयोग करता हूं। मुझे इसे एक और शॉट देना होगा और देखना होगा कि यह इसे कैसे संभालता है।

@MangelMaxime आपके काम के लिए धन्यवाद। किसी तरह आपके फुलमा प्रोजेक्ट ने मुझ पर कल्पित दुनिया पर हमला किया। और मैं वास्तव में यात्रा का आनंद लेता हूं।

मुझे एकल सूची भी पसंद है लेकिन मुझे कक्षा सदस्य ओवरराइड की तुलना में डीयू भी पसंद है। कभी-कभी मुझे आश्चर्य होता है कि अगर डीयू ओवरराइड का समर्थन करता है तो यह बहुत अच्छा होगा।
क्योंकि मैं पहले से ही Fable.React का उपयोग करता हूं, लेकिन फिर भी एकल सूची चाहता हूं, इसलिए मैंने एक ऑपरेटर बनाया> और मैं इसका उपयोग इस तरह कर सकता हूं:

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

ऑपरेटर बहुत सरल है और डीयू का लाभ भी उठा सकता है, आप यहां मेरे किसी न किसी कार्यान्वयन की जांच कर सकते हैं: https://github.com/albertwoo/Fun.LightForm/blob/master/src/Fun.LightForm.Fable/Fable.React। अतिरिक्त.fs

@ ज़ैद-अजाज आपके महान काम के लिए भी धन्यवाद, मैंने अपनी कुछ परियोजनाओं को फ़ेलिज़ और फ़ेलिज़ में परिवर्तित करना भी शुरू कर दिया है। सामग्री।

धन्यवाद!

हाय @MangelMaxime ,
सबसे पहले धन्यवाद! सच कहूं तो मुझे उम्मीद नहीं थी कि किसी के पास पुस्तकालय पर इतनी गहरी नजर होगी कि मैंने मुख्य रूप से खुद की परियोजनाओं को कुत्ते के भोजन के लिए बनाया और साइड इफेक्ट के रूप में प्रकाशित किया। अजीब बात है कि "अरे, कैसे @ जैद-अजाज ने फेलिज को डिजाइन किया था, यह बहुत अच्छा है - चलो बुल्मा के लिए भी ऐसा ही करें" सूज गया।

मैंने पहले ही Feliz.Bulma रेपो में नया अंक बनाया है और इस बात पर चर्चा करना पसंद करता हूं कि v2 को और बेहतर कैसे बनाया जाए। ऐसा लगता है कि अधिकांश मुद्दों पर हमारी सहमति है, इसलिए version2 शाखा शुरू करने में कोई समस्या नहीं होनी चाहिए। यह भी देखते हुए कि अगली बड़ी रिलीज के लिए ज़ैद की योजना क्या है, एपीआई को नवीनतम प्रमुख संस्करणों के बीच 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"
                ]
            ]
        ]
    ]
]

इसके अलावा, यदि आप वीएस कोड और इंद्रधनुष ब्रैकेट जैसे कुछ का उपयोग करते हैं, तो यह वास्तव में ब्रैकेट ओवरलोड से बचने में मदद कर सकता है।

विचार करने के लिए कुछ और (शायद मैंने इसे ऊपर याद किया) यह है कि जिराफ व्यूइंजिन Fable.React शैली का उपयोग करता है यानी तत्व एटीआर-सूची बच्चों की सूची, इसलिए दोनों के बीच संक्रमण करने वाले लोगों के संदर्भ में सोचने के लिए बस कुछ।

@ जैद-अजाज फेमटो के बारे में अच्छी बात करते हैं; क्या कोई कारण है कि इसे Fable.React-style घटकों द्वारा कार्यान्वित नहीं किया जा

क्या कोई कारण है कि इसे Fable.React-style घटकों द्वारा कार्यान्वित नहीं किया जा सका, या क्या फ़ेलिज़ शैली के बारे में कुछ अंतर्निहित है जिसे फेम्टो के साथ जोड़ा गया है?

@ इसाकाब्राहम

Fable.React से प्राप्त पुस्तकालय फेमटो मेटाडेटा जोड़ सकते हैं (और चाहिए) लेकिन Fable.React स्वयं नहीं कर सका क्योंकि इसमें react , react-dom और react-native असंगत मिश्रण है। . @MangelMaxime ने पैकेजों को विभाजित करने पर कुछ

Fable.React से प्राप्त पुस्तकालयों के लिए इसका अर्थ यह है कि उन्हें न केवल अपनी निर्भरता के npm मेटाडेटा को शामिल करना होगा, बल्कि react और react-dom संगत संस्करणों को भी शामिल करना होगा क्योंकि Fable.React करता है उनके लिए ऐसा न करें (फेलिज़ के विपरीत जो react और react-dom ताकि फ़ेलिज़ एक्सटेंशन केवल वही जोड़ सकें जो उन्हें चाहिए)। दुर्भाग्य से, मैंने अभी तक उन पुस्तकालयों में से किसी को भी स्थिति को बेहतर बनाने के लिए पहल करते हुए नहीं देखा है, भले ही समाधान काफी समय से आसपास हो।

फ़ॉर्मेटिंग के बारे में: फ़ैंटोमास अभी तक डीएसएल को एक समझदार तरीके से प्रारूपित करने में सक्षम नहीं है और सूची स्वरूपण को कॉन्फ़िगर करने है या अच्छे डिफॉल्ट का उपयोग करके रिएक्ट डीएसएल को प्रारूपित करने के लिए किसी प्रकार का "फेलिज़-मोड" ध्वज है (जो हमें आना है के साथ)

@ जैद-अजाज रिएक्ट एनपीएम निर्भरता के साथ मुद्दा भी अधिक जटिल है क्योंकि फेमटो को तोड़े बिना प्रतिक्रिया के बजाय प्रीएक्ट का उपयोग करना संभव होना चाहिए।

@ l3m वास्तव में, लेकिन इस मामले में हम इस मामले का समर्थन करने के लिए फेमटो को जोड़ सकते हैं। यह मुझे कुछ याद रखता है इसलिए शायद हमें इसके बारे में फेमटो रेपो में कोई समस्या है (क्षमा करें, अभी जांच करने का समय नहीं है ^^)

@ l3m Preact का उपयोग Femto npm मेटाडेटा की परवाह किए बिना रिएक्ट के स्थान पर किया जा सकता है क्योंकि आपको केवल मौजूदा रिएक्ट एप्लिकेशन होने पर प्रीएक्ट में

एक शुद्ध प्रीएक्ट बाइंडिंग (100% नॉन-रिएक्ट कोड) बनाना फ़ेलिज़ का लक्ष्य नहीं है और संभवतः इसे एक स्टैंडअलोन लाइब्रेरी के रूप में लागू किया जाना चाहिए (Feliz.Preact जो Feliz पर निर्भर नहीं करता है) जिससे Preact-only बाइंडिंग को बढ़ाया जाएगा और यदि आप preact/compat से दूर रहना चाहते हैं तो इसका उपयोग किया जाता है

@ ज़ैद-अजाज मैं अभी अपने एल्मिश ऐप में प्रीएक्ट का उपयोग कर रहा हूं और यह अच्छी तरह से काम करता है। मैं सिर्फ Femto को संशोधित करने के बारे में सावधान था। यदि यह रिएक्ट डिप्स के साथ एक नगेट देखता है और मैं इसे उजागर करना चाहता हूं। अगर यह कोई समस्या नहीं है, तो बेहतर है।

साथ ही, नवीनतम प्रचार के साथ preact/compat की अब आवश्यकता नहीं है, यह अब मूल में है।

जोखिम में पुरानी चर्चाओं को फिर से खोलना है (क्षमा करें!) मैं सिर्फ इंडेंटेशन बहस पर अपने दो सेंट जोड़ना चाहता था - यह (अधिक या कम) वह स्टाइल है जिसका हम अनुसरण करते हैं जो _does_ अच्छी, सुसंगत पहचान और कल्पित के लिए निम्नलिखित की अनुमति देता है। प्रतिक्रिया अंदाज।

मैं इसहाक से बहुत ही समान तरीके से कोड इंडेंट कर रहा हूं, और यह काफी पठनीय है।
मुझे पता है कि चीजों को करने के एक सूची तरीके से तुलना करना मुश्किल है, लेकिन मूल पोस्ट का इंडेंटिंग बेहतर तुलना करने के लिए उसके कोड के समान कुछ प्रतिबिंबित कर सकता है।

मुझे लगता है कि एफ # 5 और "स्थिर वर्ग खोलने" की क्षमता के साथ फेलिज Html.div और div सिंटैक्स दोनों का समर्थन करने में सक्षम होंगे, इस पर निर्भर करता है कि आप एचटीएमएल क्लास खोलते हैं या नहीं।

यह सुपर कूल होगा। क्या एचटीएमएल वर्ग को स्थिर बनाना संभव होगा ताकि इसे खोला जा सके?

@ fc1943s Html , prop और style सभी स्थिर वर्ग हैं। हालाँकि, जब F # 5 में सुविधा उपलब्ध हो जाती है, तो मैं उन्हें खोलने की अनुशंसा नहीं करता क्योंकि पूरे बिंदु में एक समूह होता है और उस स्थिर वर्ग के भीतर उपलब्ध कार्यों की खोज का प्रवेश बिंदु होता है।

स्थैतिक वर्ग को खोलने से खोज कैसे बाधित होगी? आप अभी भी Feliz.Html टाइप कर सकते हैं।

@MaxWilsonMS जिसे "अंतिम" कोड को आउटपुट करने के लिए अतिरिक्त चरणों की आवश्यकता थी।

और आप Feliz.Html.div लिखेंगे और फिर Feliz.Html. भाग को मिटा देंगे जो अजीब लगता है।

अच्छी बात यह है कि लोग अपनी पसंद के आधार पर स्टैटिक क्लास खोलना चुन सकते हैं या नहीं। :)

सुनिश्चित नहीं है कि यह कितना उपयोगी होगा क्योंकि मैं ऊपर कही गई बातों को प्रतिध्वनित कर रहा हूं, लेकिन एक पूर्ण शुरुआत के रूप में अनुभव करता हूं:

• मैं इंडेंटेशन के लिए फेलिज दृष्टिकोण पसंद करता हूं। मैंने इसहाक के सुझाव के समान दृष्टिकोण की कोशिश की है, लेकिन क्योंकि इंडेंट सभी 2s/4s नहीं हैं "मैं कभी-कभी इसके बारे में सोचने में समय बिताता हूं"। फेलिज के साथ, मैं इसके बारे में सोचने में बिल्कुल भी समय नहीं लगाता।

• अगर मैं एक कस्टम तत्व बना रहा था, तो मैं इसे Fable.React अभी के लिए कर रहा होता। मैंने चीजों को "फेलिज वे" बनाने पर एक नज़र डाली और तुरंत भाग गया (मैं किसी बिंदु पर फिर से आऊंगा!)।

• मुझे यह वास्तव में उपयोगी लगेगा यदि दस्तावेज़ीकरण नियमित रूप से "कस्टम संपत्ति बनाने का तरीका" पहलू को प्राथमिकता देगा। मुझे लगता है कि यह स्वीकार करना उचित है कि केवल कुछ लेखकों के साथ, ये पुस्तकालय अक्सर सीएसएस (उदाहरण के लिए) में हर संभव चीज के लिए एपीआई सतह की पेशकश करने के लिए संघर्ष करने जा रहे हैं, इसलिए यदि कोई नौसिखिया फंस जाता है तो वे "fontSize" सेट नहीं कर सकते हैं। "em" में, या "ग्रिड-टेम्पलेट-पंक्तियों" को नहीं ढूंढ पा रहे हैं, या उन्हें इस बात का कोई अंदाजा नहीं है कि उनसे कुछ "Screen.All" तर्क की आपूर्ति करने की उम्मीद है - यह अच्छा होगा यदि वे जानते कि इसके आसपास कैसे काम करना है।

• मुझे लगता है कि कुछ "जीवन की गुणवत्ता" में सुधार किया जा सकता है जो कुछ संभावित चिंताओं को दूर करना शुरू कर देता है ... उदाहरण के लिए जब मैं फ़ेलिज़ में स्टाइल प्रॉप्स की लंबी ऊर्ध्वाधर सूचियों को देखता हूं तो मुझे आश्चर्य होता है कि क्या style.paddingHorizontal हो सकता है style.paddingVertical । मुझे एहसास है कि मैं अपने स्वयं के सहायक बना सकता हूं, और यह सुविधा अनुरोध करने का स्थान नहीं है, और यह कि उन चीजों को पेश करने से बचने की इच्छा हो सकती है जो मानक नहीं हैं :)

• मुझे नए F# में Html स्थिर वर्ग खोलने का विचार पसंद है। गंभीर रूप से - मेरे सहयोगी मेरे कंधे को देखकर इसका अर्थ समझ पाएंगे - और मुझे लगता है कि अधिक लोगों को शामिल करना महत्वपूर्ण है। डेविल्स एडवोकेट की भूमिका निभाने के लिए: div को टाइप करने में अधिक समय नहीं लगता है और अगर मुझे इसकी खोज करने की आवश्यकता है तो यह उन चुनौतियों में से सबसे कम है जो मैं एक सेटअप का उपयोग करते समय हिट करने जा रहा हूं जो जादू कर रहा है जबकि मुझसे जावास्क्रिप्ट, रिएक्ट, सीएसएस आदि आदि छुपाना। आम तौर पर हालांकि, एपीआई की खोज क्षमता बहुत अच्छी है।

• विशेष रूप से शैलियों पर संक्रमण/एनिमेशन के लिए, फ़ेलिज़ तरीका बस इतना समझ में आता है - साथ काम करना वाकई अच्छा है।

• अधिक आम तौर पर और शायद स्पर्शरेखा: जिस चुनौती को मैं लगातार हिट करता हूं वह यह समझने के आसपास है कि एल्मिश दुनिया कहां समाप्त होती है और प्रतिक्रिया दुनिया शुरू होती है। यह वास्तव में किसी भी पुस्तकालय की चिंता नहीं है - लेकिन चूंकि मेरे पास प्रतिक्रिया के बारे में कुछ भी अस्पष्ट सुराग नहीं है, तथ्य यह है कि मुझे Fable.React या Feliz से एक फ़ंक्शन घटक मिल सकता है, मुझे भ्रमित करता है। बेशक, इसे सीखना मेरी ज़िम्मेदारी है - लेकिन मुझे लगा कि यह ध्यान देने योग्य है। मैं वर्तमान में एल्मिश और रिएक्ट दृष्टिकोणों को एक साथ मिला रहा हूं और मेरा मानना ​​​​है कि यह सभी घटकों को अपडेट पर फिर से प्रस्तुत करने में परिणाम देता है - लेकिन मुझे इससे बचने के लिए चीजों को करने का "सही" तरीका नहीं पता है क्योंकि इस तरह से पूरी तरह से निर्मित ऐप के उदाहरण हैं खोजने में मुश्किल। कभी-कभी मुझे यह आभास होता है कि मुझे पहले जावास्क्रिप्ट में प्रोडक्शन-ग्रेड रिएक्ट ऐप बनाना सीखना चाहिए, फिर फैबल/एल्मिश में स्नातक होना चाहिए - लेकिन यह प्रवेश के लिए काफी महत्वपूर्ण बाधा की तरह लगता है। अस्वीकरण: मैंने फ़ेलिज़ दस्तावेज़ीकरण को व्यापक रूप से नहीं पढ़ा है, और यह वास्तव में अच्छा है - इसलिए यह शायद मुझ पर है!

इन पुस्तकालयों को साझा करने के लिए सभी को धन्यवाद!

आपके इनपुट @ drk-mtr के लिए धन्यवाद!

अगर मैं एक कस्टम तत्व बना रहा था, तो मैं इसे Fable.React अभी के लिए कर रहा होता। मैंने चीजों को "फेलिज वे" बनाने पर एक नज़र डाली और तुरंत भाग गया (मैं किसी बिंदु पर फिर से आऊंगा!)।

हाँ, यह पहली बार में बहुत कठिन लग सकता है, लेकिन एक बार जब आप इसकी आदत डाल लेते हैं तो यह बहुत आसान हो जाता है। ऐसा कहा जा रहा है कि पुस्तकालय लिखते समय डेवलपर के लिए यह प्रारंभिक लागत का एक उचित सा हिस्सा है। मुझे यह एक बहुत ही स्वीकार्य व्यापार-बंद लगता है क्योंकि अधिकांश उपयोगकर्ता पुस्तकालय लिखने वाले नहीं हैं। सौभाग्य से काम अपने आप में बहुत सरल है, और कुछ कॉपी + पेस्ट बहुत सारे काम को गति दे सकते हैं (या हम में से कुछ की तरह, हमारे लिए कोड बनाने के लिए जनरेटर लिखना)।

मुझे यह वास्तव में उपयोगी लगेगा यदि दस्तावेज़ीकरण नियमित रूप से "कस्टम संपत्ति बनाने का तरीका" पहलू को प्राथमिकता देगा। मुझे लगता है कि यह स्वीकार करना उचित है कि केवल कुछ लेखकों के साथ, ये पुस्तकालय अक्सर सीएसएस (उदाहरण के लिए) में हर संभव चीज के लिए एपीआई सतह की पेशकश करने के लिए संघर्ष करने जा रहे हैं, इसलिए यदि कोई नौसिखिया फंस जाता है तो वे "fontSize" सेट नहीं कर सकते हैं। "em" में, या "ग्रिड-टेम्पलेट-पंक्तियों" को नहीं ढूंढ पा रहे हैं, या उन्हें इस बात का कोई अंदाजा नहीं है कि उनसे कुछ "Screen.All" तर्क की आपूर्ति करने की उम्मीद है - यह अच्छा होगा यदि वे जानते कि इसके आसपास कैसे काम करना है।

बस अगर आप जागरूक नहीं हैं (मैं इस संदर्भ से काफी कुछ नहीं बता सका):

prop और style प्रकारों पर एक custom विधि है।

ICssUnit स्वीकार करने वाली हर चीज़ को इस तरह सेट किया जा सकता है: style.fontSize (length.em 1)

डॉक्स को अपडेट करना काफी आसान होना चाहिए।

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

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

अधिक आम तौर पर और शायद स्पर्शरेखा: जिस चुनौती को मैं लगातार हिट करता हूं वह यह समझने के आसपास है कि एल्मिश दुनिया कहां समाप्त होती है और प्रतिक्रिया दुनिया शुरू होती है। यह वास्तव में किसी भी पुस्तकालय की चिंता नहीं है - लेकिन चूंकि मेरे पास प्रतिक्रिया के बारे में कुछ भी अस्पष्ट सुराग नहीं है, तथ्य यह है कि मुझे Fable.React या Feliz से एक फ़ंक्शन घटक मिल सकता है, मुझे भ्रमित करता है। बेशक, इसे सीखना मेरी ज़िम्मेदारी है - लेकिन मुझे लगा कि यह ध्यान देने योग्य है। मैं वर्तमान में एल्मिश और रिएक्ट दृष्टिकोणों को एक साथ मिला रहा हूं और मेरा मानना ​​​​है कि यह सभी घटकों को अपडेट पर फिर से प्रस्तुत करने में परिणाम देता है - लेकिन मुझे इससे बचने के लिए चीजों को करने का "सही" तरीका नहीं पता है क्योंकि इस तरह से पूरी तरह से निर्मित ऐप के उदाहरण हैं खोजने में मुश्किल। कभी-कभी मुझे यह आभास होता है कि मुझे पहले जावास्क्रिप्ट में प्रोडक्शन-ग्रेड रिएक्ट ऐप बनाना सीखना चाहिए, फिर फैबल/एल्मिश में स्नातक होना चाहिए - लेकिन यह प्रवेश के लिए काफी महत्वपूर्ण बाधा की तरह लगता है। अस्वीकरण: मैंने फ़ेलिज़ दस्तावेज़ीकरण को व्यापक रूप से नहीं पढ़ा है, और यह वास्तव में अच्छा है - इसलिए यह शायद मुझ पर है!

Fable World (प्री-फेलिज) में मेरा अनुभव यह था कि मैंने अधिकांश भाग के लिए सामान्य कार्यों के रूप में सब कुछ लिखा था, (जैसे प्रत्येक .fs के लिए एक घटक)। इसका परिणाम यह हुआ कि मैंने रिएक्ट सिस्टम द्वारा प्रदान किए जाने वाले बहुत सारे लाभों को खो दिया। फ़ेलिज़ के साथ शुरू करने के बाद से मुझे वास्तव में इस बात पर अधिक गोता लगाना पड़ा कि रिएक्ट कैसे काम करता है (एक अच्छी बात आईएमओ)। चूंकि मुझे इसकी आदत हो गई है, मैं वास्तव में इसे अब और अधिक सचेत विचार भी नहीं देता। मेरे द्वारा लिखा गया प्रत्येक कार्य जो प्रतिपादन करता है वह एक फ़ंक्शन घटक है।

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

फ़ेलिज़ में लिखा गया एक गुणवत्ता ओपन-सोर्स एप्लिकेशन निश्चित रूप से कुछ ऐसा है जो फायदेमंद होगा, मैंने इसके लिए कुछ समय पहले # 67 बनाया था। अभी सबसे नज़दीकी चीज़ शायद डॉक्स ऐप ही है, या @cmeren का इलेक्ट्रॉन डेमो है ।