Feliz: तृतीय पक्ष गाइड

यह शानदार आईएमएचओ दिखता है।

शुक्रिया! खुशी है कि आप इसे पसंद करते हैं: मुस्कान:

क्या यह सामग्री-यूआई जैसी तृतीय पक्ष सामग्री के लिए विस्तार करना आसान है?

निश्चित बात है, लेकिन दृष्टिकोण थोड़ा अलग है क्योंकि हम भेदभाव वाली यूनियनों का उपयोग नहीं कर रहे हैं। समय मिलने पर मैं कुछ लिखने की कोशिश करता हूं लेकिन विचार यह है कि आपके पास अनिवार्य रूप से दो विकल्प हैं:

• 1) अधिक कार्यों के साथ prop स्थिर प्रकार का विस्तार करें
• 2) एक समान prop स्थिर प्रकार बनाएं, जो आपकी लाइब्रेरी के लिए विशिष्ट हो (शायद Mui ) जिसमें मुई के लिए आवश्यक सभी गुण हों। आप prop को Mui $ के साथ उपनाम भी दे सकते हैं और मुई-विशिष्ट (ओवरलोडेड) गुणों और कार्यों के साथ Mui का विस्तार कर सकते हैं।

विस्तार करना उतना ही सरल है:

type prop with
  static member hello (value: string) = Interop.mkAttr "hello" value 

क्या यह पुस्तकालय का "अंतिम रूप" है और इसे विस्तारित करने का तरीका अभी भी विचाराधीन है क्योंकि मैं पहले तृतीय पक्ष पुस्तकालयों का निर्माण करके इसे आज़माना चाहता हूं और देखना चाहता हूं कि यह कैसा चल रहा है

धन्यवाद! मैं पहले से ही एपीआई के एक अंश के लिए एमयूआई के लिए कुछ परीक्षण के साथ अच्छी तरह से चल रहा हूं, यह देखने के लिए कि यह कैसे काम करता है। शायद सप्ताह/-अंत के दौरान किसी समय साझा करेंगे, यह बहुत अच्छा होगा यदि आप इसे केवल यह देखने के लिए देख सकते हैं कि क्या मैं ट्रैक पर हूं और फेलिज भावना का पालन कर रहा हूं। ऐसा लगता है कि अब तक सफलता मिली है!

हालांकि, मैंने मौजूदा prop प्रकार का विस्तार नहीं किया है। मैंने दूसरे नेमस्पेस ( Feliz.MaterialUI ) में एक अलग prop प्रकार परिभाषित किया है। बहुत अच्छा लगता है काम करता है; यदि आप Feliz और Feliz.MaterialUI दोनों को खोलते हैं तो आप निश्चित रूप से सभी मिलान प्रकारों से सभी सदस्यों तक पहुंच प्राप्त कर सकते हैं।

मेरे पास एक प्रकार Mui है जो Html से मेल खाता है और इसमें वास्तविक घटक शामिल हैं।

(वर्तमान में मैंने घटक-विशिष्ट प्रॉप्स को prop के अलग-अलग सबमॉड्यूल में रखा है, जैसा कि #13 में बताया गया है।)

फ़ेलिज़ में सुधार का एक संभावित बिंदु reactElement और createElement है जो string को स्वीकार नहीं करता है, लेकिन ReactElementType (मुझे लगता है)। ताकि हम createElement (importDefault "@material-ui/core/Button") पर कॉल कर सकें। इन दोनों हेल्पर्स को मैंने फिलहाल खुद बनाया है।

वैसे, क्या सभी सदस्य inline होने चाहिए? पक्ष/विपक्ष क्या हैं? मैंने देखा है कि आपने ऊपर inline का उपयोग नहीं किया, लेकिन फ़ेलिज़ में सब कुछ inline है।

धन्यवाद! मैं पहले से ही एपीआई के एक अंश के लिए एमयूआई के लिए कुछ परीक्षण के साथ अच्छी तरह से चल रहा हूं, यह देखने के लिए कि यह कैसे काम करता है। शायद सप्ताह/-अंत के दौरान किसी समय साझा करेंगे, यह बहुत अच्छा होगा यदि आप इसे केवल यह देखने के लिए देख सकते हैं कि क्या मैं ट्रैक पर हूं और फेलिज भावना का पालन कर रहा हूं। ऐसा लगता है कि अब तक सफलता मिली है!

वह तो कमाल है! मुझे निश्चित रूप से एक नज़र डालने में खुशी होगी यदि आप

हालाँकि, मैंने मौजूदा प्रोप प्रकार का विस्तार नहीं किया है। मैंने एक अलग प्रोप प्रकार को दूसरे नामस्थान (Feliz.MaterialUI) में परिभाषित किया है। बहुत अच्छा लगता है काम करता है; यदि आप Feliz और Feliz.MaterialUI दोनों को खोलते हैं, तो आप निश्चित रूप से सभी मिलान प्रकारों से सभी सदस्यों तक पहुँच प्राप्त कर सकते हैं।

मेरे पास एक प्रकार का मुई है जो एचटीएमएल से मेल खाता है और इसमें वास्तविक घटक होते हैं।

यही मैं Mui . के लिए करूँगा

(वर्तमान में मैंने घटक-विशिष्ट प्रॉप्स को प्रोप के अलग-अलग सबमॉड्यूल में रखा है, जैसा कि #13 में बताया गया है।)

आपके पास कितने विकल्प हैं, यह मुई के लिए समझ में आता है

फ़ेलिज़ में सुधार का एक संभावित बिंदु एक प्रतिक्रिया और createElement है जो स्ट्रिंग को स्वीकार नहीं करता है, लेकिन ReactElementType (मुझे लगता है)। ताकि हम createElement (importDefault "@ material-ui/core/Button") को कॉल कर सकें। इन दोनों हेल्पर्स को मैंने फिलहाल खुद बनाया है।

मैं उन सदस्यों की समीक्षा कर रहा हूं जिनका उपयोग मैं Interop मॉड्यूल में कर रहा हूं, मैंने लाइब्रेरी में जो कुछ भी उपयोग किया था, उसे अभी उजागर किया, स्थिर रिलीज के लिए पुनर्विचार किया जाएगा

वैसे, क्या सभी सदस्य इनलाइन होने चाहिए? पक्ष/विपक्ष क्या हैं? मैंने देखा है कि आपने ऊपर इनलाइन का उपयोग नहीं किया है, लेकिन फ़ेलिज़ में सब कुछ इनलाइन है।

मुझे ऊपर दिए गए विस्तारित सदस्य को इनलाइन करना चाहिए था!

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

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

जानकर खुशी हुई! लेकिन (कथा के संदर्भ में) पहले स्थान पर इनलाइन क्यों? "सरल" फ़ंक्शन/विधि निकायों के लिए क्या लाभ है?

• बंडल आकार: यदि इन कार्यों का उपयोग नहीं किया जाता है (और उनमें से 100 हैं), तो वे अभी भी संकलित हैं, बंडल आकार AFAIK को बढ़ाते हैं (प्रभाव अभी भी आवेदन के कुल आकार के सापेक्ष है)
• सामान्य प्रकार के तर्क: फ़ेलिज़ के लिए अप्रासंगिक लेकिन फैबल के संदर्भ में, सामान्य प्रकार के तर्कों वाला एक सामान्य कार्य संकलित नहीं होगा यदि आमंत्रण की जगह रेखांकित नहीं है (विशेष मामलों को छोड़कर सभी सामान्य प्रकार के तर्कों को संकलित समय पर स्थिर रूप से हल किया जाना है) जहां आप [<Inject>] ITypeResolver<'t> को एक स्थिर वर्ग के वैकल्पिक तर्क के रूप में उपयोग कर सकते हैं (केवल अत्यधिक विशिष्ट पुस्तकालय इस सुविधा का उपयोग करते हैं, Fable.SimpleJson/Thoth.Json देखें)

मुझे लगता है कि जब आप प्रोडक्शन बंडल बनाते हैं तो बेबेल ट्री-शेकिंग करता है और अप्रयुक्त कार्यों को हटा देता है। इनलाइनिंग उसे हरा देगी।

@ लुइज़-मोनाड क्या आप कह रहे हैं कि, आदर्श रूप से, फ़ेलिज़ में कुछ भी रेखांकित नहीं किया जाना चाहिए? बंडल-आकार के कारणों के लिए इनलाइनिंग काउंटर-उत्पादक है?

@ लुइज़-मोनाड आप जो कह रहे हैं वह कमाल होगा! कम से कम अगर संकलन उस तरह से काम करता है। यहां एक उदाहरण दिया गया है जिसे आप आरईपीएल के साथ आजमा सकते हैं:

module App

type prop = 
  // does useless stuff
  static member f() = 
    [ 1 .. 100 ]
    |> List.map (fun x -> x * 20)
    |> List.collect (fun n -> [n; n])
    |> List.fold (+) 0

  // does useless stuff
  static member inline k() = 
    [ 1 .. 100 ]
    |> List.map (fun x -> x * 20)
    |> List.collect (fun n -> [n; n])
    |> List.fold (+) 0

  static member g() = 1

let value = prop.g()

printfn "%d" value

जहां prop में शामिल हैं:

• f() में एक फ़ंक्शन बॉडी है -> इनलाइन नहीं है और इसका उपयोग भी नहीं किया गया है
• k() में एक फ़ंक्शन बॉडी शामिल है -> इनलाइन लेकिन उपयोग नहीं किया गया
• g() में एक फ़ंक्शन होता है -> इनलाइन नहीं और उपयोग किया जाता है

आपको लगता होगा कि f() और g() दोनों को संकलित नहीं किया जाएगा, लेकिन ऐसा नहीं है, f() (इनलाइन नहीं किया गया और उपयोग नहीं किया गया) वैसे भी संकलित किया गया है, लेकिन k() (इनलाइन, उपयोग नहीं किया गया) इसे संकलित बंडल में नहीं बनाता है

import { fold, collect, map, ofSeq, ofArray } from "fable-library/List.js";
import { type } from "fable-library/Reflection.js";
import { rangeNumber } from "fable-library/Seq.js";
import { toConsole, printf } from "fable-library/String.js";
import { declare } from "fable-library/Types.js";
export const prop = declare(function App_prop() {});
export function prop$reflection() {
  return type("App.prop");
}
export function prop$$$f() {
  return fold(function folder(x$$1, y) {
    return x$$1 + y;
  }, 0, collect(function mapping$$1(n) {
    return ofArray([n, n]);
  }, map(function mapping(x) {
    return x * 20;
  }, ofSeq(rangeNumber(1, 1, 100)))));
}
export function prop$$$g() {
  return 1;
}
export const value = prop$$$g();
toConsole(printf("%d"))(value);

यह वास्तव में काम करता है, लेकिन आपको ऐसा करने के लिए webpack को कॉन्फ़िगर करने की आवश्यकता है, क्योंकि ट्री-हिलिंग स्वयं कल्पित नहीं है, इसलिए यह आरईपीएल में काम नहीं करेगा।

पहले

/// Library.fs
module Library

type prop = 
    // does useless stuff
    static member f() = 
      [ 1 .. 100 ]
      |> List.map (fun x -> x * 20)
      |> List.collect (fun n -> [n; n])
      |> List.fold (+) 0

    // does useless stuff
    static member inline k() = 
      [ 1 .. 100 ]
      |> List.map (fun x -> x * 20)
      |> List.collect (fun n -> [n; n])
      |> List.fold (+) 0


type AppMain =
    static member g() = 1

//// App.fs
module App

let value = Library.AppMain.g ()

printfn "%d" value

बाद में

  declare(function Library_prop() { 
     // see its empty, this weren't removed too because of `keep_classnames: true, keep_fnames: true ` in the terser plugin
  });
  declare(function Library_AppMain() {
  });
  !function toConsole(arg) {
    return arg.cont(function (x) {
      console.log(x)
    })
  }(printf('%d')) (1),
  __webpack_require__.d(__webpack_exports__, 'value', function () {
    return 1
  })

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

इस परीक्षण के लिए मैंने जो भंडार बनाया है उसे देखें https://github.com/Luiz-Monad/test-tree-shaking

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

मैं निश्चित रूप से यह देखने के लिए आगे जांच करूंगा कि क्या इनलाइनिंग वास्तव में फेलिज़ के संदर्भ में उपयोगी कुछ भी कर रही है या नहीं

बढ़िया, आपको जो मिल रहा है उसे सुनने के लिए उत्सुक :)

वह तो कमाल है! मुझे निश्चित रूप से एक नज़र डालने में खुशी होगी यदि आप

कृपया cmeren/fable-elmish-electron-material-ui-demo पर feliz शाखा देखें ।

अधिकांश कोड (एचटीएमएल) एपीआई डॉक्स के आधार पर स्वतः उत्पन्न होता है। एक जेनरेटर प्रोजेक्ट है (बदसूरत और हैकी, लेकिन काम पूरा हो जाता है) और वास्तविक बाइंडिंग के लिए एक प्रोजेक्ट है। रेंडरर प्रोजेक्ट में, केवल App.fs को नई फ़ेलिज़-शैली बाइंडिंग का उपयोग करने के लिए परिवर्तित किया गया है।

कृपया इसे देखें जब आपको यह अच्छा लगे, और मुझे बताएं कि आप क्या सोचते हैं और यदि आपके कोई प्रश्न हैं।

@cmeeren वर्तमान एपीआई IMHO की तुलना में बहुत अच्छा और बहुत बेहतर दिखता है, लेकिन क्या इसे पढ़ना अभी भी थोड़ा कठिन है, लेकिन यह पुस्तकालय की प्रकृति से अधिक है, इसमें बहुत से विशिष्ट भाग हैं जिनसे आपको परिचित होना है। मुझे लगता है कि ऐसे हिस्से हैं जिन्हें बेहतर बनाया जा सकता है, इस उदाहरण को लें:

Mui.appBar [
  prop.className c.appBar
  prop.appBar.position.fixed'
  prop.children [
    Mui.toolbar [
      prop.children [
        Mui.typography [
          prop.typography.variant.h6
          prop.typography.color.inherit'
          prop.text (pageTitle model.Page)
        ]
      ]
    ]
  ]
]

इस स्निपेट का मेरा व्यक्तिगत संपूर्ण संस्करण इसे निम्नलिखित में बदलना होगा:

Mui.appBar [
  AppBar.className c.appBar
  AppBar.position.fixed'
  AppBar.children [
    Mui.toolbar [
      Toolbar.children [
        Mui.typography [
          Typography.variant.h6
          Typography.color.inherit'
          Typygraphy.text (pageTitle model.Page)
        ]
      ]
    ]
  ]
]

इस तरह से मुई तत्वों को खोजना आसान है क्योंकि आप मुई के माध्यम से केवल "डॉट थ्रू" कर सकते हैं और एक बार जब आपको अपना तत्व ( appBar ) मिल जाता है, तो आप मॉड्यूल नाम ( AppBar ) को "डॉट थ्रू" कर सकते हैं। गुणों को परिभाषित करने के लिए और ऐसे

शायद AppBar को लोअरकेस के रूप में भी रखें

मुझे लगता है कि आपको यह विचार मिल गया है, लेकिन अधिक सटीक होने के लिए, इस एपीआई का सामान्य सिंटैक्स इस प्रकार है जहां {Element} एक प्रतिक्रिया तत्व है:

Mui.{element} [
  {Element}.{propName}.{propValue}
  {Element}.children [
    Mui.{otherElem} [
      {OtherElem}.{propName}.{propValue}
      // etc.
    ]
  ]
]

आप इस बारे में क्या सोचते हैं? यदि आप एक ठोस कार्यान्वयन देखना चाहते हैं तो इस एपीआई ने पुस्तकालय को शानदार-सरल-तत्वों के विचारों को भी प्रेरित किया

मुझे लगता है कि यह एकदम सही है, और ठीक उसी तरह की चीज़ जिस पर मैं आपकी राय लेना चाहता था। मैंने शुरू में prop के तहत सब कुछ चुना था क्योंकि मुख्य पुस्तकालय कैसे काम करता था, लेकिन निश्चित रूप से आपके पास वास्तव में कोई घटक-विशिष्ट प्रोप नहीं है, जबकि एमयूआई में केवल घटक-विशिष्ट प्रोप कम हैं।

मुझे लगता है कि मॉड्यूल नामों को कम करने के लिए चिपके रहना सबसे अच्छा लग सकता है (और एक अतिरिक्त कीस्ट्रोक बचा सकता है), लेकिन मैं प्रतिवाद के लिए खुला हूं।

अच्छा है कि मैंने इस सामान को स्वतः उत्पन्न कर दिया है, जिससे इसे बदलना आसान हो जाता है।

मैं अपडेट करूंगा और आपको बता दूंगा।

हालाँकि, एक बात विशेष रूप से है, जिस पर मैं राय लेना चाहता हूँ। यह ClassName सामान है। makeStyles हुक एक ऑब्जेक्ट को उसी प्रोप के साथ देता है जिसमें वह पास किया गया है, लेकिन जहां प्रत्येक (जेएसएस) तत्व को एक स्ट्रिंग द्वारा प्रतिस्थापित किया गया है, जो उपयोग करने के लिए वर्ग का नाम है (और उदाहरण के लिए पारित किया जा सकता है prop.className )।

अब, इसे F# में टाइप करने का कोई तरीका नहीं है, इसलिए मेरे पास जो है उसके साथ मुझे काम करना है। आम तौर पर स्टाइल ऑब्जेक्ट के सभी प्रॉप्स होते हैं IStyleAttribute list । इसका मतलब है कि मैं prop.className के लिए एक अधिभार जोड़ सकता हूं जो IStyleAttribute list स्वीकार करता है, जो निश्चित रूप से एक झूठ है क्योंकि रनटाइम पर यह एक स्ट्रिंग है। यदि आप वास्तव में इसे IStyleAttribute list पास कर देते हैं तो यह विफल हो जाएगा। prop.className के अलावा, यह सभी classes.<element>.<classesName> ( <element>.classes [ ... ] में प्रयुक्त) के लिए भी जाता है। वे एक वर्ग का नाम (स्ट्रिंग) भी स्वीकार करते हैं।

मैंने जो किया है, जैसा कि आप देख सकते हैं, स्टाइल ऑब्जेक्ट के सभी IStyleAttribute list गुणों को "आवश्यकता" देना है asClassName , जो मूल रूप से केवल अनबॉक्स करता है IClassName (यदि आप चाहें तो string के लिए एक प्रॉक्सी)। और फिर मैंने prop.className में IClassName $ को स्वीकार करते हुए एक अधिभार जोड़ा है, और सभी classes प्रॉप्स को IClassName स्वीकार कर लिया है। मुझे यह पसंद है कि यह अधिक दृढ़ता से टाइप किया गया है, लेकिन मुझे यह पसंद नहीं है कि इसके लिए अतिरिक्त टाइपिंग की आवश्यकता है ( asClassName प्रत्येक शीर्ष-स्तरीय सीएसएस नियम के लिए)। यदि आप इसे याद करते हैं तो संकलक शिकायत करेगा, लेकिन यह आपको नहीं बताएगा कि क्या करना है, और यह अभी भी अतिरिक्त शोर है।

क्या आपके पास इस पर कोई इनपुट है?

इसके अलावा, मैंने यह देखा:

f# listItem.divider ((page = Home))

यहां, डबल पैरेनेथेसिस की आवश्यकता है, क्योंकि अन्यथा F# इसे listItem.divider (गैर-मौजूद) page पैरामीटर के साथ Home ( value के बजाय) पर कॉल करने की कोशिश के रूप में व्याख्या करता है। page = Home पर सेट है)। क्या आप इससे बचने का कोई उपाय देखते हैं?

हैलो @cmeeren , सबसे पहले, मैं इस वाक्य रचना से प्यार करता हूँ:

Mui.appBar [
  prop.className c.appBar
  appBar.position.fixed'
  appBar.children [
    Mui.toolbar [
      toolbar.children [
        Mui.typography [
          typography.variant.h6
          typography.color.inherit'
          prop.text (pageTitle model.Page)
        ]
      ]
    ]
  ]
]

यह इतना साफ और इतना आसान दिखता है! हालांकि अगर मैं आप होते, तो शायद मैं कुछ सामान्य prop फ़ंक्शंस को घटक-विशिष्ट प्रॉप्स जैसे appBar.className के बजाय (या साथ में) prop.className में डुप्लिकेट कर देता, ताकि वे सभी सममित दिखते हैं लेकिन अधिक महत्वपूर्ण बात यह है कि सामान्य prop.className के बजाय मुई-विशिष्ट घटक को IClassName अधिभार देना जो एक स्ट्रिंग लेता है क्योंकि makeStyles भी एक मुई-विशिष्ट है निर्माण और यह समझ में आता है कि यह केवल मुई घटकों पर लागू होगा।

मुझे लगता है कि आपने makeStyles को सबसे अच्छे तरीके से निपटाया, कम से कम अभी मैं बेहतर तरीके से नहीं सोच सकता (हालांकि मैं asClassName का बड़ा प्रशंसक नहीं हूं, शायद Styles.createClass इसके बजाय? यह आप पर निर्भर है)।

listItem.divider ((page = Home)) के लिए यह मुश्किल है, आप एक डमी फ़ंक्शन let when (x: bool) = x जोड़ सकते हैं लेकिन यह सिर्फ शोर है। मुझे लगता है कि इसे एक कंपाइलर बग के रूप में फाइल करना सबसे अच्छा है क्योंकि मैं इस कारण के बारे में नहीं सोच सकता कि एफ # कंपाइलर फ़ंक्शन के उचित अधिभार को हल नहीं कर सकता है, मैंने खुद को कोशिश नहीं की है लेकिन समय मिलने पर मैं इसे देख लूंगा

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

हालांकि अगर मैं तुम होते, तो शायद मैं कुछ सामान्य prop फ़ंक्शंस को घटक-विशिष्ट प्रॉप्स जैसे appBar.className के बजाय (या साथ में) prop.className में डुप्लिकेट कर देता, ताकि वे सभी सममित दिखते हैं लेकिन अधिक महत्वपूर्ण बात यह है कि सामान्य prop.className के बजाय मुई-विशिष्ट घटक को IClassName अधिभार देना जो एक स्ट्रिंग लेता है क्योंकि makeStyles भी एक मुई-विशिष्ट है निर्माण और यह समझ में आता है कि यह केवल मुई घटकों पर लागू होगा।

इसे अभी देखें :) मैंने पिछले दिनों में भारी सुधार और विस्तार किए हैं, बस उन्हें धक्का दिया है (नहीं किया, मैं वर्तमान में जेनरेट किए गए प्रोप को सत्यापित और सुधारने के लिए सभी एमयूआई घटकों के माध्यम से जा रहा हूं)।

मुझे लगता है कि आपने makeStyles को सबसे अच्छे तरीके से निपटाया, कम से कम अभी मैं बेहतर तरीके से नहीं सोच सकता (हालांकि मैं asClassName का बड़ा प्रशंसक नहीं हूं, शायद Styles.createClass इसके बजाय? यह आप पर निर्भर है)।

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

listItem.divider ((page = Home)) के लिए यह मुश्किल है, आप एक डमी फ़ंक्शन let when (x: bool) = x जोड़ सकते हैं लेकिन यह सिर्फ शोर है। मुझे लगता है कि इसे एक कंपाइलर बग के रूप में फाइल करना सबसे अच्छा है क्योंकि मैं इस कारण के बारे में नहीं सोच सकता कि एफ # कंपाइलर फ़ंक्शन के उचित अधिभार को हल नहीं कर सकता है, मैंने खुद को कोशिश नहीं की है लेकिन समय मिलने पर मैं इसे देख लूंगा

धन्यवाद, मैंने अभी एक समस्या दर्ज की है: https://github.com/dotnet/fsharp/issues/7423

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

गोचा, कोई बात नहीं। अगर मुझे कुछ चीजें मिलती हैं, तो मैं मुद्दों को पोस्ट करता रहूंगा, और आप बस अपने समय पर जवाब दें।

इसे अभी देखें :) मैंने पिछले दिनों में भारी सुधार और विस्तार किए हैं, बस उन्हें धक्का दिया है (नहीं किया, मैं वर्तमान में जेनरेट किए गए प्रोप को सत्यापित और सुधारने के लिए सभी एमयूआई घटकों के माध्यम से जा रहा हूं)।

वास्तव में अच्छा लग रहा है, जेनरेट किए गए दस्तावेज़ों के साथ भी शायद अपने स्वयं के रेपो में डालने का समय?

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

यह भी काम करेगा, कल्पित पुस्तकालय हर समय टाइप-सिस्टम को धोखा देते हैं;)

धन्यवाद, मैंने अभी एक समस्या दर्ज की है: dotnet/fsharp#7423

बहुत बढ़िया! बहुत - बहुत धन्यवाद

वास्तव में अच्छा लग रहा है, जेनरेट किए गए दस्तावेज़ों के साथ भी शायद अपने स्वयं के रेपो में डालने का समय?

मैं इसके बारे में सोच रहा था, लेकिन अभी भी कुछ महत्वपूर्ण बग हैं (उदाहरण #27) मैं सब कुछ एक ही स्थान पर रखने की सुविधा के साथ समझूंगा, इसलिए मुझे लगता है कि मैं इसे तब तक वहां रखूंगा जब तक कि यह तैयार न हो जाए nuget पर एक पूर्व-रिलीज़ के लिए (उम्मीद है कि यह बहुत लंबा नहीं होगा)।

@ Zaid-Ajaj मैं अभी Feliz.MaterialUI के साथ काम कर रहा हूँ। जल्द ही एक अलग रेपो में प्रकाशित करेंगे। कुछ डिज़ाइन निर्णयों की जाँच करने और फ़ेलिज़ के साथ निरंतरता सुनिश्चित करने के लिए सबसे पहले और सबसे महत्वपूर्ण बात यह है कि आप इसकी समीक्षा करें, लेकिन कुछ कार्यान्वयन सामग्री की जाँच करें (जैसे, क्या मैं उन चीज़ों का उपयोग कर रहा हूँ जिन्हें आप आंतरिक बना रहे हैं, या ऐसी चीजें हैं जो मैं मैं फेलिज से उपयोग नहीं कर रहा हूं लेकिन उपयोग करना चाहिए)।

जब मैं नया रेपो बनाता हूं, तो क्या यह ठीक है अगर मैं यह समझाता हूं कि मैं क्या समीक्षा करना चाहता हूं, और आपको टैग करता हूं?

मैंने अब Feliz.MaterialUI का एक मसौदा cmeeren/Feliz.MaterialUI पर अपलोड कर दिया है। मैंने उन चीजों के साथ कई मुद्दे बनाए हैं जिनकी मैं समीक्षा करना चाहता हूं।

मैं बहुत आभारी रहूंगा यदि आपको उन्हें देखने का समय मिले!

प्रत्येक मुद्दे पर बहुत अधिक समय खर्च करने की आवश्यकता नहीं है; मैं वास्तव में अपनी पिछली टिप्पणी में उल्लिखित कारणों के लिए दूसरी राय चाहता हूं। यदि आप चाहें तो मुझे मातम में जाने में खुशी हो रही है, लेकिन यहां तक ​​​​कि "यह ठीक लग रहा है" भी बहुत अच्छा होगा।

बेशक कोई जल्दी नहीं है। :)

बहुत बढ़िया काम @cmeeren! पहली नज़र में, बाइंडिंग बहुत साफ दिखती है, मैं अगले कुछ दिनों में प्रत्येक मुद्दे पर एक नज़र डालूंगा, मैं वादा करता हूं: मुस्कान:

अरे! मुद्दों को देखना जारी रखने का कोई मौका? फिर से जल्दी मत करो, बस एक दोस्ताना अनुस्मारक क्योंकि मैंने आपसे कुछ हफ़्ते से नहीं सुना है

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

हैलो @cmeeren , मुझे लगता है कि हम इसे हल करने पर विचार कर सकते हैं, है ना? मैं इस मुद्दे को बंद कर दूंगा, यदि आवश्यक हो तो कृपया आगे की चर्चा के लिए फिर से खोलें