Feliz: دليل الطرف الثالث

هذا يبدو IMHO رائع.

شكرا لك! سعيد لأنه أعجبك: ابتسم:

هل هذا سهل الامتداد لأشياء تابعة لجهات خارجية ، مثل Material-UI؟

بالتأكيد ، لكن النهج مختلف بعض الشيء لأننا لا نستخدم النقابات التمييزية. أحاول كتابة شيء ما عندما يسمح الوقت بذلك ولكن الفكرة هي أن لديك خياران أساسيان:

• 1) قم بتوسيع النوع الثابت prop بمزيد من الوظائف
• 2) أنشئ نوعًا ثابتًا مشابهًا لـ prop خاص بمكتبتك (ربما Mui ) الذي يحتوي على جميع الخصائص التي يتطلبها Mui. يمكنك حتى الاسم المستعار prop بـ Mui وتوسيع Mui بخصائص ووظائف خاصة بـ Mui (محملة بشكل زائد).

التمديد بسيط مثل:

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

ما إذا كان هذا هو "الشكل النهائي" للمكتبة وطريقة توسيعها ، فلا يزال قيد الدراسة لأنني أرغب أولاً في تجربته من خلال إنشاء مكتبات تابعة لجهات خارجية ومعرفة كيف تسير الأمور

شكرا! أنا بالفعل على قدم وساق في اختبار شيء ما لـ MUI ، فقط لجزء بسيط من API ، لمعرفة كيفية عمله. من المحتمل أن تشارك في وقت ما خلال الأسبوع / نهاية ، سيكون من الرائع أن تلقي نظرة عليها فقط لترى ما إذا كنت على المسار الصحيح وأتبع روح فيليز. يبدو أن النجاح حتى الآن!

ومع ذلك ، لم أقم بتمديد النوع الحالي prop . لقد قمت بتحديد نوع prop منفصل في مساحة اسم أخرى ( Feliz.MaterialUI ). يبدو أنه يعمل بشكل رائع. يمكنك بالطبع الوصول إلى جميع الأعضاء من جميع الأنواع المطابقة إذا فتحت كلاً من Feliz و Feliz.MaterialUI .

لدي نوع Mui يتوافق مع Html ويحتوي على المكونات الفعلية.

(لقد قمت حاليًا بوضع الدعائم الخاصة بالمكون في وحدات فرعية منفصلة prop ، كما هو مذكور في # 13.)

تتمثل إحدى نقاط التحسين المحتملة في Feliz في الحصول على reactElement و createElement لا يقبل string ، لكن ReactElementType (على ما أظن). حتى نتمكن من استدعاء createElement (importDefault "@material-ui/core/Button") . لقد قمت بإنشاء هذين المساعدين بنفسي حاليًا.

بالمناسبة ، هل يجب أن يكون كل الأعضاء inline ؟ ما هي إيجابيات / سلبيات؟ ألاحظ أنك لم تستخدم inline أعلى ، لكن كل شيء في Feliz هو inline .

شكرا! أنا بالفعل على قدم وساق في اختبار شيء ما لـ MUI ، فقط لجزء بسيط من API ، لمعرفة كيفية عمله. من المحتمل أن تشارك في وقت ما خلال الأسبوع / نهاية ، سيكون من الرائع أن تلقي نظرة عليها فقط لترى ما إذا كنت على المسار الصحيح وأتبع روح فيليز. يبدو أن النجاح حتى الآن!

هذا رائع! سأكون سعيدًا بالتأكيد لإلقاء نظرة إذا كنت

ومع ذلك ، لم أقم بتمديد نوع الخاصية الحالية. لقد حددت نوع خاصًا منفصلاً في مساحة اسم أخرى (Feliz.MaterialUI). يبدو أنه يعمل بشكل رائع. يمكنك بالطبع الوصول إلى جميع الأعضاء من جميع الأنواع المطابقة إذا قمت بفتح كل من Feliz و Feliz.MaterialUI.

لدي نوع Mui يتوافق مع Html ويحتوي على المكونات الفعلية.

هذا ما كنت سأفعله لموي

(لقد قمت حاليًا بوضع الدعائم الخاصة بالمكون في وحدات فرعية منفصلة من prop ، كما هو مذكور في رقم 13.)

من المنطقي بالنسبة لـ Mui بسبب عدد الخيارات التي لديك

من النقاط المحتملة للتحسين في فيليز أن يكون لديك عنصر رد فعل وإنشاء عنصر لا يقبل سلسلة ، ولكن نوع ReactElementType (على ما أعتقد). حتى نتمكن من استدعاء createElement (importDefault "@ material-ui / core / Button"). لقد قمت بإنشاء هذين المساعدين بنفسي حاليًا.

أقوم بمراجعة الأعضاء الذين أستخدمهم في الوحدة النمطية Interop ، لقد كشفت للتو كل ما كنت أستخدمه في المكتبة ، وسيعاد النظر في الإصدار الثابت

بالمناسبة ، هل يجب أن يكون كل الأعضاء مضمنين؟ ما هي إيجابيات / سلبيات؟ ألاحظ أنك لم تستخدم المضمنة أعلاه ، ولكن كل شيء في فيليز مضمّن.

كان يجب أن أؤكد العضو الموسع أعلاه!

القاعدة الأساسية هي: إذا كانت قيمة الخاصية بدائية مثل سلسلة / int / bool / enum ، فقم بتضمين الخاصية ولكن إذا كانت الخاصية الخاصة بك تحسب قيمة بناءً على الإدخال ، فمن الأفضل عدم تضمينها لأنه في كل مرة يستخدمها المستخدم يستدعي الوظيفة المضمنة ، يتم تضمين جسم الوظيفة بالكامل في مكان الاستدعاء ، لذلك إذا استخدم المستخدم نفس الوظيفة 10 مرات في جميع أنحاء التطبيق ، يتم تجميع جسم الوظيفة مضمّنًا 10 مرات بدلاً من تحديده مرة واحدة والإشارة إليه 10 مرات

القاعدة الأساسية هي: إذا كانت قيمة الخاصية بدائية مثل سلسلة / int / bool / enum ، فقم بتضمين الخاصية ولكن إذا كانت الخاصية الخاصة بك تحسب قيمة بناءً على الإدخال ، فمن الأفضل عدم تضمينها لأنه في كل مرة يستخدمها المستخدم يستدعي الوظيفة المضمّنة ، يتم تضمين جسم الوظيفة بالكامل في مكان الاستدعاء ، لذلك إذا استخدم المستخدم نفس الوظيفة 10 مرات في جميع أنحاء التطبيق ، يتم تجميع جسم الوظيفة مضمّنًا 10 مرات بدلاً من تحديده مرة واحدة والإشارة إليه 10 مرات

جميل أن تعرف! ولكن (في سياق الخرافة) لماذا مضمنة في المقام الأول ، إذن؟ ما هي الفائدة بالنسبة لهيئات الوظيفة / الطريقة "البسيطة"؟

• حجم الحزمة: إذا لم يتم استخدام هذه الوظائف (وهناك مئات منها) ، فلا يزال يتم تجميعها على أي حال ، مما يؤدي إلى تضخيم حجم الحزمة AFAIK (لا يزال التأثير بالطبع متناسبًا مع الحجم الإجمالي للتطبيق)
• وسيطات النوع العامة: غير ذات صلة بـ Feliz ولكن في سياق Fable ، لن يتم تجميع دالة عامة ذات وسيطات من النوع العام إذا لم يكن مكان الاستدعاء مضمّنًا (يجب حل جميع أنواع الوسائط العامة بشكل ثابت في وقت الترجمة) باستثناء الحالات الخاصة حيث يمكنك استخدام [<Inject>] ITypeResolver<'t> كوسيطة اختيارية لفئة ثابتة (فقط المكتبات المتخصصة للغاية تستخدم هذه الميزة ، انظر Fable.SimpleJson / Thoth.Json)

أعتقد أن برنامج Babel يقوم بهز الأشجار ويزيل الوظائف غير المستخدمة عند إنشاء حزمة الإنتاج. التضمين سوف يهزم ذلك.

@ Luiz-Monad هل تقول ذلك ، من الناحية المثالية ، لا ينبغي أن يكون هناك شيء مضمّن في فيليز؟ هل هذا التضمين لأسباب حجم الحزمة يأتي بنتائج عكسية؟

@ Luiz-Monad ما تقوله سيكون رائعًا! على الأقل إذا كان التجميع يعمل بهذه الطريقة. إليك مثال يمكنك تجربته باستخدام REPL:

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 للقيام بذلك ، لأن ما تفعله اهتزاز الشجرة ليس حكاية بحد ذاتها ، لذلك لن ينجح في REPL.

قبل

/// 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

شكرا جزيلا على سبيل المثال الريبو! سأقوم بالتأكيد بالتحقيق في هذا الأمر بشكل أكبر لمعرفة ما إذا كان التضمين يقوم فعلاً بأي شيء مفيد في سياق فيليز

سأقوم بالتأكيد بالتحقيق في هذا الأمر بشكل أكبر لمعرفة ما إذا كان التضمين يقوم فعلاً بأي شيء مفيد في سياق فيليز

رائع ، أتطلع إلى سماع ما تجده :)

هذا رائع! سأكون سعيدًا بالتأكيد لإلقاء نظرة إذا كنت

يرجى مراجعة الفرع feliz على cmeeren / fable-elmish-electron-material-ui-demo .

يتم إنشاء معظم الكود تلقائيًا بناءً على مستندات API (HTML). هناك مشروع مولد (قبيح ومبتكر ، لكنه ينجز المهمة) ومشروع للارتباطات الفعلية. في مشروع العارض ، تم تحويل App.fs فقط لاستخدام روابط نمط Feliz الجديدة.

يرجى إلقاء نظرة عليها عندما تشعر بذلك ، واسمحوا لي أن أعرف ما هو رأيك وإذا كان لديك أي أسئلة.

يبدو cmeeren لطيفًا جدًا وأفضل بكثير من IMHO API الحالي ، لكن هل لا يزال من الصعب بعض الشيء قراءته ولكن هذه هي طبيعة المكتبة نفسها ، فهي تحتوي على الكثير من الأجزاء المحددة جدًا التي يجب أن تكون على دراية بها. أعتقد أن هناك أجزاء يمكن تحسينها ، خذ هذا المثال:

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)
        ]
      ]
    ]
  ]
]

بهذه الطريقة يكون من السهل العثور على عناصر Mui لأنه يمكنك فقط "وضع نقطة من خلال" Mui وبمجرد العثور على العنصر الخاص بك ( appBar ) ، يمكنك "وضع نقطة من خلال" اسم الوحدة ( AppBar ) لتحديد الخصائص وما إلى ذلك

ربما احتفظ بـ AppBar كأحرف صغيرة أيضًا

أعتقد أنك فهمت الفكرة ولكن بشكل أكثر دقة ، فإن البنية العامة لواجهة برمجة التطبيقات هذه هي كما يلي حيث {Element} عنصر تفاعل:

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

ما رأيك بهذا؟ ألهمت واجهة برمجة التطبيقات هذه المكتبة أيضًا بأفكار عناصر رائعة بسيطة إذا كنت تريد أن ترى تنفيذًا ملموسًا

أعتقد أن هذا مثالي ، وهو نوع الشيء الذي أردت الحصول على رأيك فيه. اخترت في البداية أن يكون كل شيء أقل prop لأن هذه هي الطريقة التي تعمل بها المكتبة الرئيسية ، ولكن بالطبع ليس لديك أي دعائم خاصة بالمكونات ، في حين أن MUI لديها المزيد من الدعائم الخاصة بالمكون فقط أقل.

أعتقد أن التمسك بأسماء الوحدات الصغيرة قد يبدو أفضل (وحفظ ضغطات مفتاح إضافية) ، لكنني منفتح على الحجج المضادة.

من الجيد أنني قمت بإنشاء هذه الأشياء تلقائيًا ، مما يجعل من السهل تغييرها.

سوف أقوم بتحديث وأعلمك.

هناك شيء واحد على وجه الخصوص أود الحصول على آراء بشأنه. إنها الأشياء ClassName . يقوم الخطاف makeStyles بإرجاع كائن بنفس الخاصيات مثل العنصر الذي تم تمريره إليه ، ولكن حيث تم استبدال كل عنصر (JSS) بسلسلة ، وهو اسم الفئة المراد استخدامه (ويمكن تمريره إلى eg 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 لكل قاعدة CSS من المستوى الأعلى). سيشتكي المترجم إذا فاتتك ، لكنه لن يخبرك بما يجب عليك فعله ، ولا يزال هناك ضوضاء إضافية.

هل لديك أي مساهمة في هذا؟

كما لاحظت هذا:

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 لذلك تبدو جميعها متناظرة ولكن الأهم من ذلك أنها تعطي زيادة في التحميل الزائد للمكون الخاص بـ Mui بدلاً من $ # IClassName prop.className الذي يأخذ سلسلة لأن makeStyles هو أيضًا خاص بـ Mui بناء ومن المنطقي أنه سيتم تطبيقه فقط على مكونات موي.

أعتقد أنك تعاملت مع makeStyles بأفضل طريقة ممكنة ، على الأقل في الوقت الحالي لا يمكنني التفكير في طريقة أفضل (على الرغم من أنني لست معجبًا كبيرًا بـ asClassName ، ربما Styles.createClass بدلاً من ذلك؟ الأمر متروك لك).

أما بالنسبة إلى listItem.divider ((page = Home)) فهو أمر صعب ، يمكنك إضافة وظيفة وهمية let when (x: bool) = x لكن هذا مجرد ضوضاء. أعتقد أنه من الأفضل تقديمه باعتباره خطأ في المترجم لأنني لا أستطيع التفكير في سبب عدم تمكن مترجم F # من حل الحمل الزائد المناسب للوظيفة ، لم أجرب نفسي ولكنني سأبحث في الأمر عندما يسمح الوقت بذلك

أخيرًا ، لست مستجيبًا كالمعتاد هذا الأسبوع لأنني في إجازة الآن ، لذلك قد لا أتمكن من قراءة / التحقق من كل شيء وما إلى ذلك.

على الرغم من أنني لو كنت مكانك ، فمن المحتمل أن أكون قد قمت بتكرار بعض الوظائف العامة prop في الدعائم الخاصة بالمكون مثل appBar.className بدلاً من (أو جنبًا إلى جنب) prop.className لذلك تبدو جميعها متناظرة ولكن الأهم من ذلك أنها تعطي زيادة في التحميل الزائد للمكون الخاص بـ Mui بدلاً من $ # IClassName prop.className الذي يأخذ سلسلة لأن makeStyles هو أيضًا خاص بـ Mui بناء ومن المنطقي أنه سيتم تطبيقه فقط على مكونات موي.

تحقق من ذلك الآن :) لقد أجريت تحسينات وتوسعات جذرية في الأيام الماضية ، فقط قمت بدفعها (لم يتم الانتهاء ، فأنا الآن أقوم بمراجعة جميع مكونات MUI للتحقق من الدعائم التي تم إنشاؤها وتحسينها).

أعتقد أنك تعاملت مع makeStyles بأفضل طريقة ممكنة ، على الأقل في الوقت الحالي لا يمكنني التفكير في طريقة أفضل (على الرغم من أنني لست معجبًا كبيرًا بـ asClassName ، ربما Styles.createClass بدلاً من ذلك؟ الأمر متروك لك).

أرغب في جعله قصيرًا قدر الإمكان لأنه سيتم استخدامه كثيرًا ، لكنني منفتح على الأسماء الأخرى. على الرغم من أن لدي نصف عقل لمجرد الحصول على زيادة IStyleAttribute list . ستزيل قدرًا كبيرًا من الضوضاء ، وأشك في أنها ستكون خطيرة جدًا حتى لو كان من الممكن استخدامها بشكل غير صحيح من الناحية الفنية.

أما بالنسبة إلى listItem.divider ((page = Home)) فهو أمر صعب ، يمكنك إضافة وظيفة وهمية let when (x: bool) = x لكن هذا مجرد ضوضاء. أعتقد أنه من الأفضل تقديمه باعتباره خطأ في المترجم لأنني لا أستطيع التفكير في سبب عدم تمكن مترجم F # من حل الحمل الزائد المناسب للوظيفة ، لم أجرب نفسي ولكنني سأبحث في الأمر عندما يسمح الوقت بذلك

شكرًا ، لقد قدمت مشكلة الآن: https://github.com/dotnet/fsharp/issues/7423

أخيرًا ، لست مستجيبًا كالمعتاد هذا الأسبوع لأنني في إجازة الآن ، لذلك قد لا أتمكن من قراءة / التحقق من كل شيء وما إلى ذلك.

مسكتك ، لا مشكلة. سأستمر في نشر المشكلات إذا صادفت أشياء ، وقمت بالرد في وقتك الخاص.

تحقق من ذلك الآن :) لقد أجريت تحسينات وتوسعات جذرية في الأيام الماضية ، فقط قمت بدفعها (لم يتم الانتهاء ، فأنا الآن أقوم بمراجعة جميع مكونات MUI للتحقق من الدعائم التي تم إنشاؤها وتحسينها).

تبدو جيدة حقًا ، مع المستندات التي تم إنشاؤها أيضًا - ربما حان الوقت لوضع الريبو الخاص بها؟

أرغب في جعله قصيرًا قدر الإمكان لأنه سيتم استخدامه كثيرًا ، لكنني منفتح على الأسماء الأخرى. على الرغم من أن لدي نصف عقل لمجرد وجود حمل زائد لقائمة IStyleAttribute. ستزيل قدرًا كبيرًا من الضوضاء ، وأشك في أنها ستكون خطيرة جدًا حتى لو كان من الممكن استخدامها بشكل غير صحيح من الناحية الفنية.

هذا من شأنه أن يعمل أيضًا ، مكتبات Fable تخدع نظام الكتابة طوال الوقت ؛)

شكرًا ، لقد قدمت مشكلة الآن: dotnet / fsharp # 7423

مدهش! شكر كثيرا

تبدو جيدة حقًا ، مع المستندات التي تم إنشاؤها أيضًا - ربما حان الوقت لوضع الريبو الخاص بها؟

لقد كنت أفكر في ذلك ، ولكن لا تزال هناك بعض الأخطاء المهمة (على سبيل المثال رقم 27) أفضل اكتشاف الراحة في وجود كل شيء في نفس المكان ، لذلك أعتقد أنني سأحتفظ به هناك حتى يصبح جاهزًا للإصدار التجريبي على الكتلة المعدنية (نأمل ألا تكون طويلة جدًا).

@ Zaid-Ajaj لقد انتهيت للتو من Feliz.MaterialUI. سيتم نشرها في ريبو منفصل قريبًا. سيكون من الرائع أن تقوم بمراجعته ، أولاً وقبل كل شيء للتحقق من بعض قرارات التصميم والتأكد من الاتساق مع Feliz ، ولكن أيضًا للتحقق من بعض عناصر التنفيذ (على سبيل المثال ، هل أستخدم أشياء ستصنعها داخليًا ، أم أن هناك أشياء أنا لا أستخدم من فيليز ولكن يجب أن أستخدمه).

عندما أقوم بإنشاء الريبو الجديد ، هل من الجيد أن أنشأت مشكلات تشرح ما أريد مراجعته ، ووضعت علامة عليك؟

لقد قمت الآن بتحميل مسودة Feliz.MaterialUI إلى cmeeren / Feliz.MaterialUI . لقد أنشأت العديد من المشكلات المتعلقة بالأشياء التي أرغب في مراجعتها.

سأكون ممتنًا جدًا إذا أمكنك إيجاد الوقت لإلقاء نظرة عليهم!

ليست هناك حاجة لقضاء الكثير من الوقت في كل قضية ؛ أريد حقًا رأيًا ثانيًا للأسباب المذكورة في تعليقي السابق. أنا سعيد بالذهاب إلى الأعشاب الضارة إذا أردت ، ولكن حتى مجرد "هذا يبدو جيدًا" سيكون رائعًا.

ليس هناك اندفاع بالطبع. :)

عمل رائعcmeeren! للوهلة الأولى ، تبدو الروابط نظيفة للغاية ، وسألقي نظرة على كل مشكلة في الأيام القليلة المقبلة ، وأعدك: ابتسم:

يا! أي فرصة لمواصلة النظر في القضايا؟ مرة أخرى لا تتسرع ، مجرد تذكير ودي لأنني لم أسمع منك منذ أسبوعين 😃

لقد نظرت بالفعل في المشكلات ولكن كما قلت من قبل ، ما إذا كانت واجهة برمجة التطبيقات جيدة أم لا تأتي من حالات الاستخدام ، ولهذا السبب طلبت منك نشر إصدار ألفا حتى أتمكن من تجربته ولكن لم يكن لدي الوقت للقيام بذلك حتى الآن (لقد كان في الجزء الخلفي من ذهني هذا الأسبوع: ابتسم :)

مرحبًا cmeeren ، أعتقد أنه يمكننا اعتبار هذا الأمر قد تم حله ، أليس كذلك؟ سأغلق القضية ، يرجى إعادة فتح لمزيد من المناقشة إذا لزم الأمر