Material-ui: دعم React Native

اكتشفت للتو هذا الريبو: https://github.com/lightningtgc/react-native-material-ui
لا أعرف ما إذا كان ذلك مفيدًا أم لا.

شكرًا chadobado - لقد تحدثنا عنه بالتأكيد وسيكون مشروعًا ممتعًا للبدء. ومع ذلك ، لدينا أيدينا كاملة مع هذا المشروع في الوقت الحالي. سأبقي هذه المشكلة مفتوحة وأحدّثها إذا أنشأنا مكتبة أصلية.

هذه في الواقع فكرة عظيمة لقد حاولت اختبار نقل material-ui إلى React-Native. نحتاج فقط إلى أوراق الأنماط قليلاً ، وتغيير كل div إلى View ، تغيير الكل h1 ، h2 ، إلخ إلى Text و سوف تعمل بشكل رائع. المشكلة الوحيدة التي وجدتها هي أن React Native لا تدعم بشكل كامل boxShadow لذلك من الصعب تنفيذ مكون Paper في الوقت الحالي. سيكون من الرائع أيضًا أن نتمكن من إنشاء برنامج نصي رائع لنقل الكود تلقائيًا إلى React-Native لأنه لا يختلف كثيرًا.

قم بتغيير كل div إلى عرض ، وقم بتغيير كل h1 ، و h2 ، وما إلى ذلك إلى نص وسيعمل بشكل رائع

ألا يمكننا استخدام برنامج babel-plugin-transformer للقيام بذلك؟

هذه في الواقع فكرة عظيمة

هل لديك مشروع تجريبي؟

تضمين التغريدة

ألا يمكننا استخدام برنامج babel-plugin-transformer للقيام بذلك؟

لست متأكدًا من أن ورقة أنماط React Native مختلفة تمامًا عن CSS ، لذا سيكون من الصعب جدًا إنشاء المحول.

هل لديك مشروع تجريبي؟

ليس السبب بعد "أنا مشغول جدًا ولكن سأحاول أن أعرض لك عرضًا توضيحيًا صغيرًا قريبًا.
ولكن هذا ما نحتاج إلى القيام به

أوراق الأنماط

let styles = {
      root: {
        zIndex: 5,
        width: '100%',
        display: '-webkit-box; display: -webkit-flex; display: flex',
        minHeight: themeVariables.height,
        backgroundColor: themeVariables.color,
        paddingLeft: spacing.desktopGutter,
        paddingRight: spacing.desktopGutter,
      }
}

ل

let styles = StyleSheet.create({
      root: {
        // zIndex: 5, (not supported)
        //width: '100%', (number only)
        //display: '-webkit-box; display: -webkit-flex; display: flex', (React Native always use Flex)
        minHeight: themeVariables.height,
        backgroundColor: themeVariables.color,
        paddingLeft: spacing.desktopGutter,
        paddingRight: spacing.desktopGutter,
      }
})

حل zIndex

شبيبة

<div {...other} style={this.prepareStyles(styles, style)}>
  <h1 style={styles.text}>Hello world</h1>
</div>

ل

<View {...other} style={this.prepareStyles(styles, style)}>
  <Text style={styles.text}>Hello world</Text>
</View>

نحتاج أيضًا إلى تعديل styles/transition.jsx (استخدم React Native object بدلاً من string ) ، mixins/style-propable.jsx لأننا لسنا بحاجة للتعامل مع متصفحات متعددة ، إلخ.

لقد قمت فقط بنشر تفرع ويب للتفاعل الأصلي في https://github.com/lenaten/material-ui-native.
حاليًا لا يعمل سوى Card و RaiseButton ، ولكن بدون نمط (العمل قيد التقدم هل تذكر؟)

lenaten مثيرة للاهتمام!
أردت أيضًا أن أبدأ العمل على غلاف بين هذا المشروع و mrn (https://github.com/oliviertassinari/react-material).
يبدو أن مفترقك يعمل فقط مع تفاعل أصلي ، كيف تجعله يعمل مع المتصفح أيضًا؟
أعتقد أنها أصعب نقطة ويجب معالجتها الآن ، لأنك تقول إن لديك عنصرين عاملين. يمكنني المساعدة إذا كنت تريد.
كما ذكرنا سابقًا ، أردت أيضًا التحقيق في https://github.com/binggg/mrn لتطبيقنا المحلي.

عندما يتم الرد ، أعتقد أنه يمكننا دمج الشوكة هنا مرة أخرى.

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

على أي حال ، مساعدتك في الأفكار والرمز موضع ترحيب كبير.

oliviertassinari أنا أيضًا.

فكرتي في جعل material-ui يعمل مع كل من المستعرض والأصلي هو استخدام بنية اسم الملف ، على غرار الطريقة التي يتعامل بها react-active مع iOS و Android في نفس الوقت.

app-bar.native.jsx
app-bar.browser.jsx
common.jsx

أو لا يزال بإمكاننا استخدام نفس المكونات لكل من المتصفح والمحتوى الأصلي ثم كتابة غلاف للتعامل معها. على سبيل المثال ، يستخدم react-native View ، المتصفح يستخدم div ثم قم بذلك على النحو التالي:

div.browser.jsx

export class ... {
  render() {
    return </div>
  }
}

div.native.jsx

export class ... {
  render() {
    return </View>
  }
}

app-bar.jsx

import {div} from "div"

يمكننا بالفعل إنشاء مشروع منفصل لهذا الغلاف.

@ quanglam2807 أنا سعيد لسماع ذلك.

فيما يتعلق بتنظيم الكود ، أحب فكرة وجود امتدادات ملفات منفصلة.
أود أن آخذ https://github.com/benoitvallon/react-native-nw-react-calculator/tree/master/src/common/components مثالًا كطريقة للقيام بذلك.

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

للبدء بملفاتنا .native ، يمكننا الاعتماد عليها

• https://github.com/binggg/mrn
• أو https://github.com/xinthink/react-native-material-kit

عناصر.

oliviertassinari أنا أيضًا أحب فكرة نموذج "امتداد الملف". أهم شيء بالنسبة لي الآن هو تشغيل المكونات الأصلية. إذا كنت تريد المساعدة في تجريد الكود فمرحبا بك. ألتزم بإزالة اللاحقة "الأصلية" من اسم الريبو :)

lenaten هي

mvayngrib توقفت عن العمل في هذا المشروع لفترة ..

lenaten هذا عار ، شكرا على الرد

حسنًا ، لقد بدأت العمل في هذا https://github.com/callemall/material-ui/pull/2611.
سيستغرق ذلك بعض الوقت!

oliviertassinari رهيبة! متحمس جدا

فهل ما زال مسعى الميناء مفتوحًا؟ إذا كان الأمر كذلك ، ما هي العملية التي تم التوصل إليها بشأن تنفيذ المكونات؟

dorthwein لا يزال مفتوحًا.

من وجهة نظري العملية هي كالتالي:

• [] قم بالترقية إلى أحدث إصدار من رد الفعل الأصلي وإزالة خادم webpack الأصلي التفاعلي . لقد فعلت ذلك بالفعل في هذا المشروع . https://github.com/callemall/material-ui/pull/3829
• [] العب مع رد الفعل وانظر إلى أي مدى يمكننا استخدامه بشكل جيد مقابل muiTheme القادم من السياق. https://github.com/callemall/material-ui/pull/3829
• [x] انتظر إعادة تنظيم المجلد حتى يكون لدينا مكان لوضع المكونات الجديدة
• [] ابدأ العمل على تطبيق التوثيق الذي سنستخدمه لعرض مكون جديد.
• [] ابدأ العمل على النسخة الأصلية من المكونات.

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

dorthwein نحن سعداء لسماع ذلك.
أنا أستخدم رد الفعل هنا # 3829. القضية الوحيدة التي لدي هي مشكلة صغيرة. تعرض React Native بعض التحذيرات بخصوص الاستخدام الخاطئ لواجهة برمجة التطبيقات StyleSheet . لم ألق نظرة عليها بالتفصيل ولكني أعتقد أنه يمكن حلها.

oliviertassinaridorthwein أنا سعيد أن هذا الجهد (أي، ليصل material-ui إلى react-native ) لم يمت. أردت فقط أن أشير إلى أن هناك أيضًا مشروعًا جديدًا آخر من material-ui إلى react-native لم يتم ذكره في هذا الموضوع: https://github.com/react-native-material- تصميم / رد فعل أصلي-تصميم-مادّي . يبدو أن هذا المشروع يعتمد على https://github.com/binggg/mrn.

oliviertassinari رأيته في موضوع آخر إذا كان دعم iOS

oliviertassinari يبدو أن بنية الملفات component.native.js و component.android.js و component.ios.js هي

oliviertassinari حاولت الحصول على المستندات ولم يحالفني الحظ. قضايا قليلة:

• package.json: رد فعل أصلي لا يعجبه اسم الحزمة material-ui - التغيير إلى materialUI يحل المشكلة
• يواجه فرع material-ui / التفاعلي الأصلي الحالي مشكلة مع أداة التحزيم الأصلية ولا يتم إنشاء ملف mainjs.bundle. لم أتمكن من معرفة ما كان يحدث هنا.
• لا يمكنني أن أحصل على تطبيق أصلي يعمل على رد الفعل يتصدر قائمة المواد الموجودة في واجهة المستخدم. إذا كان لدى أي شخص أي حظ في هذه الجبهة ، فدعنا نحصل على فكرة مستقرة حول كيفية المساهمة / تطوير مجموعة المكونات الأصلية.

dorthwein شكرا على ردود الفعل. الفرع الأصلي المتفاعل هو تجريبي للغاية. نحن بحاجة لحل هذا.
من ناحية أخرى ، ليس لدي أي مشكلة من جانبي (https://github.com/callemall/material-ui/pull/3829).
يجب أن أحاول البدء من git clone .

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

كنت أقرأ عن بعض الأشياء ولاحظت هذه المعلومة من صفحة FB React الأصلية.

"يعتبر العرض هو المكون الأساسي لبناء واجهة المستخدم ، وهو عبارة عن حاوية تدعم التخطيط باستخدام flexbox ، والأسلوب ، وبعض التعامل باللمس ، وعناصر التحكم في إمكانية الوصول ، وقد تم تصميمه ليكون متداخلاً داخل طرق العرض الأخرى ولديه عدد 0 إلى العديد من العناصر الفرعية من أي نوع. عرض خرائط مباشرة إلى النظرة الأصلية المكافئة على أي منصة تعمل React عليها ، سواء كانت UIView ،

عثرت أيضًا على هذا المورد - جربه الآن. يبدو مستقيمًا جدًا للأمام وربما يستحق العناء

https://github.com/necolas/react-native-web

dorthwein فكرة عظيمة! لكن إذا اتبعنا هذا المسار ، أعتقد أن تطوير نسخة لـ React Native فقط سيكون أفضل.

يمكننا إعادة كتابة المشروع بأكمله ضمن React Native APIs بدلاً من الأكواد المنفصلة لـ Native و DOMs. مدهش! لم افكر في هذا ابدا

@ quanglam2807 نعم - بهذه الطريقة ميزات جديدة وما إلى ذلك ... ابق على اتصال مع بعضها البعض. أعتقد أن التحدي الأكبر هو بعد ذلك عمل الأنماط والرسوم المتحركة. ميزة كبيرة أخرى أيضًا هي أنه يمكننا إضافة دعم تدريجي لمكونات مختلفة.

الجانب السفلي هو كل شيء سوف تحتاج إلى استخدام الصناديق المرنة.

بالنظر إلى أن هذه عملية إعادة هيكلة كبيرة لقاعدة الشفرة - من يحتاج جميعًا إلى التوقيع على هذا للمضي قدمًا؟ ما زلت بحاجة للتلاعب ومعرفة مدى قوة عناصر الويب التي تتفاعل مع المحتوى الأصلي أيضًا.

@ quanglam2807oliviertassinari ميزة أخرى مع هذا النهج هو أن المواد واجهة المستخدم سوف بسهولة ميناء أكثر من https://github.com/ptmt/react-native-desktop كذلك.

oliviertassinari يستخدم موقع الويب المشرفون في هذا المشروع إذا

dorthwein أحب الفكرة وراء هذا المشروع. لكنني لا أعتقد أنه سيساعد في المستقبل القريب.
ألا نحتاج أولاً إلى كتابة نسخة أصلية من مكوناتنا قبل أن نتمكن من استخدام react-native-web ؟

oliviertassinari لا ، ما يفعله موقع الويب

ستكون العملية بعد ذلك بدلاً من كتابة إصدارات أصلية من كل مكون ، حيث يتعين علينا فقط تحويل الإصدارات الحالية لاستخدام العرض بدلاً من div والنمط النص بدلاً من استخدام أشياء مثل h1 والتسمية.

بالتأكيد ليس تعهدًا صغيرًا ولكن العملية ستعمل بعد ذلك على تحديث المكونات الحالية بدلاً من محاولة إنشاء إصدارات متعددة وصيانتها.

ستكون العملية بعد ذلك بدلاً من كتابة إصدارات أصلية من كل مكون ، حيث يتعين علينا فقط تحويل الإصدارات الحالية لاستخدام العرض بدلاً من div والنمط النص بدلاً من استخدام أشياء مثل h1 والتسمية.

هذا يبدو تمامًا مثل كتابة نسخة أصلية نأمل أن تعمل في المتصفح أيضًا. بقدر ما أعرف أن react-native-web يجلب التفاعل الأصلي إلى الويب وليس العكس.
ومع ذلك ، يمكن أن يكون ذلك مفيدًا حقًا لمشاركة نفس الرمز: +1 :.
لقد رأيت مشكلة صغيرة واحدة مع هذا lib حتى الآن. لا يدعم تطبيقهم StyleSheet.create القيم الديناميكية (المطلوبة لـ muiTheme). يمكننا استخدام البحث عن رد الفعل لحالة الاستخدام هذه.

oliviertassinari حقك - كنت

wordyallen : تبدو جيدة 👍

pgangwani لقد بدأت للتو العبث بها ... إنها ليست جاهزة بعد.

لقد كنت أستخدم https://github.com/react-native-material-design/react-native-material-design لملء الفراغ ولكنه قاسي جدًا حول الحواف أيضًا ولا يوجد تطوير نشط

سوف أتبرع مالياً لهذا المسعى ، إذا استطعت.

أهلا يا أصدقاء،

أنا أعمل على رد فعل-أصلية-مادة-واجهة مستخدم ، مستوحاة من هذه المكتبة. لا تتردد في المحاولة - أود سماع أي تعليقات ؛)

xotahal وآخرون. حسنًا ، بدلاً من إنشاء ما يجب أن نقوم به IMHO من الصفر ، يتم إنشاء هذه المكتبة ونقل المكونات الموجودة بدلاً من إعادة إنشائها. هناك حاجة ماسة إلى مدخلات نمط المواد في مساحة RN ، إذا سألتني. شكرا للجميع على جهود OSS الخاصة بك.

لا أعتقد أن هناك الكثير من التعليمات البرمجية الشائعة ، أعتقد أن الإنشاء من نقطة الصفر أمر منطقي. سيكون التصميم في RN مختلفًا بنسبة 90٪ عن هذا. وهناك بعض الآليات الخاصة بالمنصة مثل الرسوم المتحركة ...

يبدو أن اعتماد بنية المكون والدعائم (والمستندات) والحصول على مسار واضح ، حتى لو تغير الكثير ، سيكون مفيدًا على المدى الطويل لأولئك الذين ينتقلون ذهابًا وإيابًا من الويب إلى المحتوى الأصلي وهو الأكثر أهمية. يصبح الباقي تفاصيل التنفيذ.

أتفق مع jhabdas ؛ كلما كانت واجهات برمجة التطبيقات (API) أكثر تشابهًا في البحث عن كل مكون ، قلَّ تزعج المطورين لتبديل مشاريع الويب والمشاريع الأصلية. كلما كانت التجربة أقل إثارة ، زادت إنتاجيتها. أتوقع أن يتم تلخيص التفاصيل الخاصة بالمنصة خلف الكواليس للمكون.

chadobado أو

FWIW ، هذا لفت انتباهي.

دعم necolas على الويب مقابل react-native-material-kit :

من غير المحتمل أن تحتاج إلى نقل الكثير من أوراق الأنماط ، إن وجدت ، حيث يتم توفير التوافق من خلال تنفيذ الويب لـ React Native

jhabdas إذا لعبت قليلاً مع رد فعل محلي ، فسترى أن الأمر ليس بهذه البساطة. تعد StyleSheet API رائعة ولكن عليك إعادة كتابة بعض العناصر ؛)

نقطة عادلةantoinerousseau. ما زلت أفكر في اقتباس من جيمس لونج على RN:

فكر في الأمر كنموذج أولي لاتجاه مختلف للويب

إذا فهمت الغرض من عمل مكتبة necolas ، فيبدو أن النهج React Native Material Kit لديها بالفعل قفزة جيدة في حل المشكلة.

نظرًا لأن react-native-web يبدو رائعًا ، سأقوم بإنشاء ملفات material-ui.android.js و material-ios.ios.js و material-ui.web.js في مشروعي الشخصي ووصفها بأنها جيدة. إذا اتبعت material-ui API عن طريق تغليف كل شيء آخر ، فسوف ينجح الأمر في النهاية. إذا فاجأني material-ui وعملت فقط ، فسأحتاج فقط إلى إزالة .web من .web.js وحذف الملفات الأخرى. بهذه الطريقة يمكنني الانتقال بشكل انتقائي إلى material-ui لكل مكون.

oliviertassinari لذلك أضفت الفرع react-native كاعتماد NPM وقمت بتثبيت جميع ملحقات Babel الإضافية. تلقيت هذه الرسالة عند استيراد أي مكون:

EventPluginRegistry: Cannot inject event plugin ordering more than once. You are likely trying to load more than one copy of React.

هدفي هو استخدام material-ui في أقرب وقت ممكن لكل مكون. منحت ، لقد حصلت على git rebase master وكان يجب أن أفعل git rebase next إذا كان هناك أي شيء. هل جميع مكونات react-native الفردية متوقفة عن طريق إعداد عمل الفرع next الآن؟

وكتبت بعض الكود الذي يسمح لي باستهلاك react-native-vector-icons بنفس الطريقة التي أستهلك بها أيقونات material-ui :

// <strong i="19">@flow</strong>

import React from 'react'
import {
  Text,
  View
} from 'react-native'
import Mui from './app/material-ui'
import Icons from './app/material-ui/icons'

export default React.createClass({
  render: function() {
    return (<View>
      <Icons.AccountCircle />
      <Mui.IconAccountCircle />
    </View>)
  }
})

على الرغم من وجود بنية استيراد غير متوافقة في الوقت الحالي بين react-native-vector-icons و material-ui . oblador اضطررت إلى استيراد glyphMap وتكرارها وتصدير القائمة بأكملها ككائن واحد كبير.

import { glyphMap } from 'react-native-vector-icons/MaterialIcons'

سيكون من الرائع لو تم تجميع رموز المواد في react-native-vector-icons حسب فئة مثل material-ui مما يسمح بالتصدير الفردي من داخل فئة:

import ActionHome from 'material-ui/svg-icons/action/home'

هل يجب أن نعمل على طلب سحب لجعل react-native-vector-icons متوافقًا مع اصطلاحات استيراد material-ui ؟

mattferrin الفرع react-native قديم جدًا الآن. ليس المقصود أن يستهلكها المستخدمون. لقد كان دليلًا على المفهوم فيما يتعلق
بقدر ما نظرت في هذه المشكلة ، فإن أحد الأساليب الواعدة هو إعادة كتابتها لاستهداف react-native . عندئذٍ ستفعل شبكة الويب التفاعلية الجزء الصعب بالنسبة لنا.
ومع ذلك ، هناك بعض التحديات:

• ما مقدار _react-native-web_ جاهز للإنتاج؟ على سبيل المثال ، لم أشاهد اختبارات بصرية.
• كيف تتعامل مع الاستفسارات الإعلامية؟
• كيف تتعامل مع حل السمات المعقدة؟

التفاعل مع الأنماط أمر يستحق النظر إليه أيضًا.

ما مقدار تفاعل الويب الأصلي الجاهز للإنتاج؟

oliviertassinari أقوم حاليًا react-native-web ، وأشعر أنه يستحق الاحتضان. إنه يفتقد إلى مكون href عبر الأنظمة الأساسية وقد يفتقد إلى التفاصيل الأخرى ، لكن ReactDOM الأساسي جاهز للإنتاج وهذا ما نحتاجه.

كيف تتعامل مع الاستفسارات الإعلامية؟

هل يجب أن يهتم بـ material-ui ؟ هناك طرق للعثور على أبعاد مكون أو شاشة على جميع الأنظمة الأساسية. طالما أنه يمكن تمرير مكونات material-ui الدعائم التي تتحكم في التصميم ، وهو ما يفعلونه ، فنحن على ما أعتقد.

هل يقوم material-ui بإجراء استعلامات عن الوسائط؟ هل نحن بحاجة الى؟

كيف تتعامل مع حل السمات المعقدة؟

لا يمكننا فقط التحقق من النظام الأساسي لحذف أو إعادة تسمية الدعائم غير المدعومة React Native ، لأنه (إذا كانت الذاكرة تفيدني بشكل صحيح) يتم عكس الحشو والهامش بشكل أساسي في React Native. كل ما يتعين علينا القيام به هو التفاف الطريقة المكافئة createStyleSheet لتحويل / تصفية النتيجة إلى أنماط متوافقة مع نظام أساسي غير "ويب".

لم أستخدمه حتى الآن ، لكن فيلا تهدف إلى أن تكون منصة مشتركة ، وأعتقد أن هذا مهم. نظرًا لأن مؤلف كتاب Fela كتب React Look وبما أن ذلك كان اختيارًا سابقًا ، فإنه يبدو خيارًا طبيعيًا.

أنا أيضًا لم أستخدمها ولكن شيئًا مثل react-tunnel يبدو جيدًا لسياق التخصيص. يمكننا ببساطة استخدامه وكشفه ، مرة أخرى فقط لأنه يشعر بأنه أكثر قابلية للمشاركة في المجتمع. قد يكون هناك مكافئ أكثر شيوعًا.

ما مقدار تفاعل الويب الأصلي الجاهز للإنتاج؟ على سبيل المثال ، لم أشاهد اختبارات بصرية.

توجد أمثلة تفاعلية هنا: https://necolas.github.io/react-native-web/storybook/

كيف تتعامل مع الاستفسارات الإعلامية؟

في JavaScript ، استخدم matchMedia (أو استخدام Dimension ) لتحديد الأنماط والمكونات التي سيتم عرضها.

يفتقد إلى مكون href عبر النظام الأساسي

نعم ، لست متأكدًا من الحل "المناسب" ، ولكن يمكنك استخدام روابط مثل View و Text مثل الروابط في الوقت الحالي (دعم الويب فقط ، بالطبع):

<Text accessibilityRole='link' href={href}>{text}</Text>

كيف تتعامل مع حل السمات المعقدة؟

React Native لا يمانع في كيفية القيام بذلك. لا يزال بإمكانك استخدام context لتحديد كائنات النمط التي تريد تطبيقها. تعجبني تمامًا واجهة برمجة تطبيقات Fela داخل المكونات ، ولكن يبدو أن واجهة برمجة التطبيقات الخاصة بالتنفيذ والمكونات الإضافية مبالغة إذا كنت ستستخدم react-native-web .

كل ما يتعين علينا القيام به هو التفاف طريقة createStyleSheet المكافئة لتحويل / تصفية النتيجة إلى أنماط متوافقة مع نظام أساسي غير "ويب".

هل تكمن المشكلة في كشف واجهة برمجة تطبيقات نمطية غير متوافقة مع RN؟ إذا كان الأمر كذلك ، أقترح عليك كشف واجهة برمجة تطبيقات نمط متوافق مع RN والسماح لـ react-native-web بتحويلها إلى أنماط DOM.

تضمين التغريدة

هل تكمن المشكلة في كشف واجهة برمجة تطبيقات نمطية غير متوافقة مع RN؟ إذا كان الأمر كذلك ، فإنني أقترح عليك الكشف عن واجهة برمجة تطبيقات نمط متوافقة مع RN والسماح للويب التفاعلي الأصلي بتحويله إلى أنماط DOM.

نقطة جيدة. هل react-native-web له معنى :hover على سبيل المثال؟

necolas والعمل المعين الذي أقوم به يحتاج فقط إلى دعم المتصفحات دائمة الخضرة ، ولكن هل هناك احتمال أن النقل إلى react-native-web سيكلف material-ui توافق المتصفح مع أي إصدارات أقدم؟ لا أعرف شيئًا عن ذلك حقًا. أعتقد حقًا أن react-native-web هو النهج الصحيح.

لا يوفر أي شيء خاص لأنماط التمرير (ولا يوفر أيضًا RN). أتساءل عما إذا كانت تطبيقات سطح المكتب لنظامي التشغيل Windows و Ubuntu تجمع أي شيء لواجهات الماوس أو تتركه لك عبر الأحداث.

لست متأكدًا من دعم المتصفح الذي تحتاجه ولكن قد أكون قادرًا على التوافق عند ظهور المشكلات

أعتقد أنه قد يكون من الضروري إدخال قيمة منطقية في سياق التسلسل الهرمي للمكونات عبر MuiThemeProvider للاختيار بين react-native-web مقابل واجهة برمجة تطبيقات نمط المكون react-dom .

أفضل إجابة هي التبديل إلى واجهة برمجة التطبيقات ذات النمط react-native-web ، وهذا ما أؤيده ، ولكن من المحتمل أن يتسبب ذلك في الانزعاج.

oliviertassinari هل يمكننا الابتعاد عن تبديل material-ui إلى واجهة برمجة تطبيقات نمط react-native ؟ ربما تسمح لأنماط معينة من الماوس بالتسرب؟

تضمين التغريدة إنها قذرة الآن ، لكنني كنت أعمل على نقل فرع (https://github.com/mattferrin/material-ui-build/tree/mine) ليكون عبر النظام الأساسي لآخر 2-3 أيام لأنني أحتاجه حقًا بنفسي (لتقليل إجمالي عملي على المدى الطويل).

لقد قمت بنقل كل شيء إلى بناء جملة react-native-web وأعلق على الأنماط التي لا تنتقل ، لكنني أعتقد أنني سأنتهي في النهاية بالتعليق عليها مرة أخرى واستخدام Platform.OS == 'web' للاحتفاظ بالكود الأصلي بشكل أساسي دون تغيير بمجرد أن انتهيت من نقل موقع الويب الذي أعمل عليه. في هذه المرحلة فقط الأشياء التي أحتاجها شخصيًا سيتم نقلها وبصورة ناقصة.

إنها فوضى تامة (حتى أتطرق إليها لاحقًا) لأنني أقفز للتنقل بين أجهزة Mac و Windows أثناء التنقل.

بالنسبة لأولئك الذين لا يستطيعون انتظار وصول MUI إلى RN ، هناك بدائل ، وبعضها لطيف المظهر. أحتفظ بقائمة دائمة الخضرة هنا: https://habd.as/awesome-react-components/#react -native

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

mattferrin ليس تمامًا من البداية (على الرغم من أن هذا صحيح في بعض الحالات ، على سبيل المثال Table ) على الرغم من أن تغيير حل النمط يتطلب العديد من تغييرات واجهة برمجة التطبيقات ، ولكن بالإضافة إلى ذلك ، يمنحنا الفرصة لترشيد واجهة برمجة التطبيقات في مناطق أخرى للعديد من المكونات . أنا آسف إذا تم إهدار جهودك - آمل ألا يؤدي ذلك إلى إبعادك عن Material-UI!

mbrookes لا. لقد ارتكبت خطأ تفريع master بدلاً من next والتقليل من أهمية الفرق (وإجمالي العمل بشكل عام). كان خطأي وكنت أعلم أن هناك مخاطر. سأعيد ببساطة عناصر Text فارغة كعناصر نائبة حتى وقت لاحق في واجهة React Native material-ui . عندما قمت بنقل موقع الويب الخاص بي بالكامل إلى react-native-web سأعود وأحاول إعادة تعيين التغييرات الجديدة من next .

الإفراج عن هذا الرجل اليوم: https://carbon-ui.com

مستوحى من واجهة المستخدم المادية ، ويعمل على الويب ويتفاعل مع المحتوى :)

تضمين التغريدة

tuckerconnelly رائع ، الكثير من الإمكانات في هذا المشروع ... أحسنت! إليكم الأمل في أن يحتشد المجتمع الأكبر وراء هذا الجهد! 🍻

تضمين التغريدة لقد وجدت أنه من السهل جدًا جعل material-ui عبر النظام الأساسي المشروط (على الرغم من خطئي المتمثل في التفرع من master بدلاً من next وإضاعة وقتي). لدي فضول ما هي الفوائد التي تراها لمشروع مستقل؟

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

في بعض الأحيان يكون من الأسهل البدء من الصفر.

بالنسبة لي ، ليس من المنطقي أن يكون لديك مكونات React لا تعمل على React Native ... وبما أن مطوري واجهة المستخدم المادية لم يعتبروا RN أولوية ... فمن العدل / المنطقي فقط البدء في مسار جديد

tuckerconnelly لا أعتقد أنه من المهم كيفية تنفيذ المكونات. آمل فقط أن يحاول كلا المشروعين تنفيذ نفس واجهة برمجة التطبيقات (والاتفاق على نفس الأسماء) لمكوناتهما. أنا سعيد لأنك عملت على هذا وشاركتها.

إذن لعام 2017/2018 بعد الإصدار 1.0.0 ، هل سيكون RN هو الهدف التالي لواجهة المستخدم المادية؟

كما رأينا من:

• مشاركة المجتمع في الإصدار 1
• عدد الأشخاص الذين يريدون دعم RN
• حقيقة أن العديد من المشاريع قد استندت أو استلهمت من Material-ui لتقديم مكونات RN
• الخبرة المكتسبة من كل هذا وحقيقة أن الكثير من الوقت قد مضى على فتح هذا الموضوع

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

يستخدم NitroBAY 1.0 JSS بدلاً من كائنات JS للتصميم ، لذا فهو يعتمد على cssinjs / jss # 368 لدعم React Native. لكني أعتقد أنه من الأفضل تطوير نسخة موازية لـ React Native مثل هذا: https://github.com/xotahal/react-native-material-ui. ثم يمكننا تشغيل إصدار React Native على الويب باستخدام https://github.com/necolas/react-native-web

فهل هذا معتاد؟ إذا كان الأمر كذلك ، هل يمكن من فضلك وضع علامة على هذا النحو؟

jhabdas أود أن أرى مكتبة جيدة تجلب مواصفات المواد إلى React Native.
من الروابط المنشورة في الموضوع ، توجد بالفعل قائمة جيدة بالمرشحين.

إذا أبقينا هذه المشكلة مفتوحة ، فهي تتعلق بتوحيد الويب والمواقع الأصلية. توفير واجهة برمجة تطبيقات متسقة بين النظامين الأساسيين. أتمنى لو كان لدي الوقت للعمل على ذلك لكنني لا أفعل وأشك في أنه سيتغير.
يود فريق @ callemall / material-ui رؤية شخص ما يتولى زمام المبادرة في هذه المسألة.

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

• يقوم تلقائيًا بإنشاء مستندات من تعليقات المكون
• لديه موقع مستندات (carbon-ui.com)
• يدعم المحتوى الأصلي والويب بنفس المكونات

سيساعد أي شخص يريد إضافة مكونات :)

tuckerconnelly ما رأيك في https://github.com/xotahal/react-native-material-ui؟ لا يعمل على الويب بسبب خطأ في Elevation ، ولكن إذا طبقنا الكود الخاص بك https://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.js ، أعتقد ذلك سيعمل. توضحoliviertassinari نقطة جيدة أننا بحاجة لاتخاذ قرار بشأن مشروع رئيسي للعمل معًا.

quangbuule انتظر تقول إنه يجب علينا تطوير التطبيقات
لم اسمع بهذا الشيء ولكن بخير. ولكن هذا يعني أننا لن نستخدم material-ui بعد الآن ولكن أكثر من مفترق RN؟

NitroBAY نحن نقوم بشكل أساسي

آسف على جميع أسئلة noob لكنني وصلت إلى ReactLand منذ حوالي أسبوع واحد.

هل تعتقد أن الحزمة الخاصة بك ستحل محل هذه الحزمة؟
يبدو أنك نهج متعدد المنصات وجيد جدًا. تتمسك واجهة المستخدم المادية بالويب فقط لأنه ليس لديهم الوقت ولكن لديهم الوقت التالي ، لماذا؟
أنت تقول next استخدم نهجًا متشابهًا على next ولكن إذا أخذت أيًا من المكونات ، مثل الورق ، فلن يعمل إلا للويب حيث يوجد مكون div .
من هو we ، هل أنت جزء من هذا الفريق؟
بغض النظر عن الاعتبارات التقنية ، ألا تعتقد أن استخدام MD على IOS قد يزعج المستخدمين؟

تحرير: خارج الموضوع ولكن لم يجبني أحد ، ما هي المزايا التي يجلبها jss-theme-reactor عندما يتعلق الأمر بمقارنتها بـ jss-react ؟

NitroBAY :

1. أنا لست مطور هذا المشروع أو أي مشروع React Native. لكنني شاهدت هذه المشكلة لعدة أشهر ، وفي الوقت الحالي ، أتطلع إلى بدء المساهمة في react-native-material-ui .
2. paper أو الظل يعمل الآن على الويب ، iOS ، Android. لذا فهي ليست مشكلة كبيرة.
3. يستخدم الفرع material-ui master كائنات لتحديد أوراق الأنماط ولكن لتحسين الأداء (زيادة بنسبة 30٪) ، يتحول المساهمون إلى JSS (CSS في JS) في الفرع next . في الوقت الحالي ، JSS غير متوافق مع React Native.
4. تستخدم Google التصميم متعدد الأبعاد على iOS ولا أعتقد أن المستخدمين يهتمون كثيرًا. بالطبع ، يجب عليك تعديل بعض الأجزاء لتلائم النظام الأساسي مثل تغيير لون شريط الحالة ، واستخدام أيقونة مشاركة iOS ، وما إلى ذلك. لقد استخدمت material-ui لتطبيق Windows 10 و macOS ولم أر الكثير اشتكى المستخدمون من ذلك (http://moderntranslator.com/). حتى أن البعض قال إن MD كان أسهل في الاستخدام.

لكن ما زلت لا أفهم الطريقة التي قد يعمل بها الفرع next في RN إذا كانت المكونات تستخدم عناصر HTML مثل span أو div . ربما فاتني شيء ولكن للتطوير في RN تحتاج إلى استخدام مكونات RN ، أليس كذلك؟
أقتبس منك:

سيصبح الإصدار الرسمي لكل من الويب والأصلي. أعتقد أنه من الجيد اعتبار أن واجهة المستخدم المادية تستخدم نهجًا مشابهًا مع الفرع التالي.

لكن قد لا أفهمها بشكل صحيح. هل تقصد أن الفرع next سيجعلنا قادرين على استخدام المكونات في RN؟

NitroBAY : next سيجعل الفرع material-ui أقل توافقًا مع React Native. أيضًا ، على الرغم من أن مكون RN لا يدعم span أو div ، باستخدام القواعد الشرطية ، يمكنك شيئًا كالتالي:

if (platform === 'web') return <span/>;
else return <View />;

يمكنك التحقق من: https://github.com/necolas/react-native-web

حسنًا ، أعتقد أنك تقصد أنهم جعلوا RN متوافقًا.

هل TL؛ DR أن هذا المشروع لا يهتم بدعم الأنظمة الأساسية المتعددة عبر React Native API ، ويجب أن ينتقل هذا الجهد إلى https://github.com/xotahal/react-native-material-ui؟

تعد المستندات الخاصة بواجهة مستخدم الكربون أفضل ، وهي تعمل بالفعل على الويب. ما فائدة تفاعل-أصلية-مادية-واجهة المستخدم؟

هل يتفق الجميع على أنه سيتم إيقاف استخدام material-ui ليتم استخدامه والتوصية به في غضون وقت قصير؟ إذن من المؤسف أن أصحاب هذه الحزمة لا يريدون RN؟

carbon-ui سيواجه مشكلات في الأداء بسبب عدم استخدام StyleSheet وإدخال الكثير من خطوط الويب

حافظو على هدوئكم يا رفاق! لا يزال قادمًا.

TL ؛ DR: إذا قمت بإنشاء مكون لـ React Native ، فسيعمل على RN والويب. ولكن إذا قمت بإنشاء مكون للويب ، فلن يعمل على RN. و material-ui مصمم للويب ، محسّن للويب => لجعله يعمل على RN ، يجب التضحية بالأداء (على الأقل ، في الوقت الحالي). وبالتالي ، أعتقد أنه من الأفضل إبقاء المشروعين منفصلين حتى يصبح RN أكثر نضجًا.

مُحسَّن للويب => لجعله يعمل على RN ، يجب التضحية بالأداء (على الأقل ، في الوقت الحالي)

هل لديك أي بيانات تود مشاركتها حول ذلك؟

فيما يلي النتائج التي توصلت إليها بخصوص RNW حتى الآن:

• https://github.com/necolas/react-native-web/blob/89ad493ce5ef3b37998af397156903ade1ada34b/performance/README.md
• https://github.com/necolas/react-native-web/pull/343#issuecomment -279177085

necolas # 4066

حسنًا ، يمكنني النظر في استخدام StyleSheet مع اليورانيوم. سأقول ، لم ألاحظ أي مشكلات متعلقة بالأداء في CSS ، لكنني سأرى ما إذا كان بإمكاني الاندماج بشكل أفضل مع عناصر StyleSheet الخاصة بك.

تأتي أكبر نسبة أداء من الرسوم المتحركة: https://github.com/animatedjs/animated/issues/48 لكن هذا يؤثر على جميع تطبيقات RNW.

هل يؤدي حقن خطوط الويب إلى تقليل الأداء بشكل مفيد؟ يقوم بتحميلها مباشرة من خطوط google ، لذلك من المحتمل أن تكون مخزنة مؤقتًا على نظام المستخدم.

أعتقد أن أهم شيء هو أن يحتشد الجميع خلف مكتبة واحدة. ولا أعتقد أن واجهة المستخدم المادية ستدعم React Native.

necolas TL ؛ DR هو أن المسار للمضي قدمًا غير واضح .

أ = رد فعل أصلي
ب = الويب

1. المنصة الأكثر تقييدًا

تتمثل إحدى الطرق الممكنة في استهداف النظام الأساسي الأكثر تقييدًا ، وبالتالي البدء من التفاعل الأصلي . ثم لتوسيع الميزات إلى الويب. لتوسيع الميزات إلى الويب ، يمكن أن نستخدم:

• https://github.com/necolas/react-native-web
• https://github.com/taobaofed/react-web

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

جلب API الأصلي إلى الويب

يجب إعادة تطبيق واجهة برمجة التطبيقات للعمل مع المتصفح. ما هو النفقات العامة؟

التعامل مع واجهة برمجة تطبيقات الويب المفقودة باللغة الأصلية

نظرًا لأننا نبدأ من النظام الأساسي الأكثر تقييدًا ، فسنحتاج إلى إعادة تنفيذ بعض الميزات المتاحة على الويب. ماذا عن الاستفسارات الإعلامية؟ توريث CSS ، الرسوم المتحركة CSS؟
من سنقوم بتنفيذ أحداث إمكانية الوصول ولوحة المفاتيح دون تضخيم الإصدار الأصلي؟

2. المنصة الأقل تقييدًا

حل آخر هو البدء من النظام الأساسي الأقل تقييدًا ، ومن ثم الويب. ثم إعادة إنشاء الميزات الأصلية المفقودة.

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

إحضار واجهة برمجة تطبيقات الويب إلى النسخة الأصلية

سنضطر إلى تقديم تضحيات ، أتوقع أن يكون من الصعب حقًا تنفيذ بعض ميزات الويب على أصلي ، على سبيل المثال ، استعلامات وسائط CSS ، الرسوم المتحركة لـ CSS. (قواعد CSS المتقدمة)

التعامل مع واجهة برمجة التطبيقات الأصلية المفقودة في الويب

تدور بعض ميزات واجهة برمجة تطبيقات الويب المفقودة حول التعامل باللمس والتمرير وعرض القائمة اللانهائية والمكونات الأصلية مثل منتقي التاريخ أو درج.

3. تقاسم العقد

قد يكون الحل الثالث هو إنشاء بنية أساسية لمشاركة API والاختبارات ثم إعادة تنفيذ المكونات في النظامين الأساسيين. من وجهة نظري ، كيف يتعامل التفاعل مع نظامي التشغيل iOS و Android.
ثم باستخدام نهج مختلط للطريقتين السابقتين لملء العقد بالكامل. أعني ، استخدام تفريع الكود عندما يكون ذلك منطقيًا ومشاركة الكود قدر الإمكان.
على سبيل المثال:

• لماذا استخدام animated.js على المتصفح بينما يمكننا استخدام انتقالات CSS؟
• لماذا يتم تطبيق منطق الدرج على رد الفعل الأصلي بينما يمكننا استخدام المكون الأصلي؟

أعتقد أن الخيار 3. هو الخيار الواعد. إنها الطريقة التي حاولت بها حل المشكلة في طرق العرض القابلة للتمرير .

https://github.com/tuckerconnelly/uranium يدعم استعلامات الوسائط عبر الأنظمة الأساسية :)

يكمن جمال RN في أن لديك مكتبة بسيطة من واجهات برمجة التطبيقات المجردة والأوليات ، ويتم الاهتمام بالتطبيقات منخفضة المستوى. الرسوم المتحركة هي نفسها - مكتبة بسيطة للرسوم المتحركة ، والتطبيقات منخفضة المستوى (الرسوم المتحركة الأصلية على iOS / Android ، وتحولات css على الويب) يتم الاهتمام بها.

أعتقد أنه يمكن تهزهز animated.js لاستخدام انتقالات css. من المؤكد أن تحسين الأداء.

@ quanglam2807 هذا الخيط طويل جدًا ، ما الذي يجب أن

لتوسيع الميزات إلى الويب ، يمكننا استخدام: https://github.com/necolas/react-native-web ، https://github.com/taobaofed/react-web

react-web بعيد جدًا عن الأداء أو IMO الصحيح وظيفيًا.

يجب إعادة تطبيق واجهة برمجة التطبيقات للعمل مع المتصفح. ما هو النفقات العامة؟

النفقات العامة في أي أبعاد؟ يصعب تحديد حجم الحزمة. من المحتمل أن تكون قادرًا على إسقاط بعض التعليمات البرمجية الموجودة لديك ؛ ولكن إذا كنت ستعتمد على أي شيء يتجاوز صادرات RNW الأساسية ، فسوف تضيف بسرعة. في المكونات ذات النمط الثقيل لـ mobile.twitter.com ، لاحظت انخفاضًا بنسبة 20-40٪ في حجم تحويل الأنماط من وحدات css إلى RNW StyleSheet. فيما يتعلق بأداء وقت التشغيل ، فهي ليست بعيدة حاليًا

ماذا عن الاستفسارات الإعلامية؟

يمكنك استخدام matchMedia لتغيير الأنماط وبنية المكونات ، على الرغم من أن فوائد استخدام استعلامات الوسائط لتغيير المكونات ليست واضحة بالنسبة لي.

توريث CSS ، الرسوم المتحركة CSS؟

يدعم RNW الرسوم المتحركة CSS (على الرغم من أنني بحاجة إلى إضافة واجهة برمجة تطبيقات لتحديد الإطارات الرئيسية). ما هو السؤال المتعلق بميراث CSS؟

كيف يمكننا تنفيذ أحداث إمكانية الوصول ولوحة المفاتيح دون تضخيم الإصدار الأصلي؟

لست متأكدا ما يعنيه هذا. أظن أن الحد الأدنى لـ "bloat" في التطبيق المحلي أعلى بكثير من تطبيق الويب.

لذلك ربما تكون مقارنة كيفية معالجة أنماط تفاعل الويب الأصلي لتقديم عروض css لأداء وحدات css أقل صلة الآن

لماذا يكون ذلك؟

سيكون من الرائع أن يكون لديك نوع من الويب المتفاعل الأصلي الذي يستخدم شيئًا مثل أفروديت أو jss

كلتا هاتين المكتبتين أبطأ وأكبر وغير مناسبة تمامًا لتوفير أنماط حتمية

يبذلnecolas material-ui جهدًا كبيرًا للتبديل من طريقة css-in-js إلى أسلوب ورقة الأنماط (css في <style> ). لقد بذلوا جهودًا نشطة منذ شهور لتبديل المكونات. الأسباب هنا . مما قرأته باستخدام jss هو ميزة كبيرة ويبدو أنه الحل الأمثل للتعامل مع الأسلوب حتى الآن.

بالمناسبة من خلال قراءة Roadmap.md مرة أخرى ، يتوفر دعم RN على خريطة الطريق.

أنا مهتم جدًا باستخدام Material-UI مع تفاعل أصلي ، هل هناك أي كلمة قيد التقدم؟

wswoodruff يمكنك التحقق من هذا الآن - https://github.com/xotahal/react-native-material-ui

حاليًا ، لدينا ثلاث مكتبات رائعة لذلك:

• مجموعة مواد التفاعل الأصلية ★ 3110 - جلب التصميم

• تفاعل - أصلي - تصميم - مادة ★ 2447 - تفاعل مكونات تصميم المواد الأصلية

• تفاعل - أصلي - مادة - واجهة مستخدم ★ 1040 - مكونات تصميم مواد قابلة للتخصيص بدرجة عالية لـ React Native.

يتمتع!

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

لقد تم التطرق إليه عدة مرات في هذا الموضوع ، لكنني أريد تسميته مرة أخرى بسبب كيفية تأثيره على اهتمامي بهذا التغيير: الفائدة الرئيسية لدعم التفاعل الأصلي الذي أراه لا يتعلق في الواقع برد الفعل الأصلي ، ولكن بدلاً من ذلك يتم بناؤها على العناصر الأولية التي تتيح استخدام نفس المكونات على _ كلاهما _ أصلي وويب.

إذا تم استخدام هذا النوع من المواد الأولية ، فيمكن أيضًا تمكين أدوات أخرى مثل رد فعل رسم تخطيطي ورد فعل pdf .

شخصيًا ، هذه الأشياء تثير اهتمامي أكثر من كونها أصلية ، ولكن سيتم تمكينها من خلال نفس التغييرات.

jhabdas كيف هي تجربتك في استخدام Carbon UI؟ Bcz بالنسبة لي يبدو جيدًا جدًا ولكن لم يتم استخدامه بعد.

@ deadcoder0904 لم متداول آخر -IMHO يتم حلها الحيز الذي boilerplates القائمة و المكونات .

فيما يلي بعض العقبات التي يمكنني التفكير فيها والتي يجب التغلب عليها لإتاحة MUI في React Native. بافتراض v1 MUI واحتفظنا بـ JSS ، ونمط classes ، والأشياء الأخرى التي تشكل في هذه المرحلة أجزاءً رئيسية من تصميم واجهة MUI.

• يحتاج JSS إلى دعم RN ، أي صنع كائنات نمط بطريقة تعمل withStyles فقط. المزيد عن هذا في https://github.com/cssinjs/jss/issues/368#issuecomment -376708219.
• بافتراض عدم وجود غلاف متسلل أو تحويل بابل ، سنحتاج إلى زيادة نمط classes بحيث يعمل بنفس الطريقة ولكن مع مراعاة حقيقة أنه في RN يجب أن يمرّر مصفوفة إلى style ، وربما يجب تسميته styles . ربما يمكن التعامل مع هذا عن طريق إسقاط classnames وإضافة مساعدين قابلين للفرد يقوموا خلف الكواليس بالتبديل بين معالجة class / className والأنماط / الأنماط.
  يمكن:
  js const styleProps = props.composeStyles( 'root', (raised || fab) && 'raised', fab && 'fab', fab && mini && 'mini', color === 'inherit' && 'colorInherit', flat && color === 'primary' && 'flatPrimary', flat && color === 'secondary' && 'flatSecondary', !flat && color === 'primary' && 'raisedPrimary', !flat && color === 'secondary' && 'raisedSecondary', size !== 'medium' && `size${capitalize(size)}`, disabled && 'disabled', fullWidth && 'fullWidth', ); return <ButtonBase {...styleProps} ... />
  سيقبل composeStyles قائمة بأسماء الأنماط (ويتجاهل القيم الزائفة). على الويب ستبدو بـ props.classes وتخرج {classNames} . على المستوى الأصلي ، سيبدو في props.styles وينتج {style} .
  في الأصل فكرت في this.composeStyles مع مصمم ، لكن بدلاً من ذلك withStyles يمكن أن يمرر مساعد تكوين النمط كجزء من الدعائم.
• كما ذكر آخرون بعد كل هذا لجعل المكونات الأساسية المصممة تعمل ، سنحتاج إلى عمل إضافي لعمل الرسوم المتحركة ، والأدوات الملموسة ، وما إلى ذلك ... العمل.
• لكن بالنسبة للرسوم المتحركة ، لا أعتبر هذا شيئًا سيئًا. إنها خسارة صغيرة للتحولات البسيطة ، حيث تقوم تلقائيًا بتحويل opacity ، backgroundColor ، إلخ ، قد نحتاج إلى مساعدين يبقيهم بهذه البساطة. ولكن مما رأيته ، فإن تطبيقات نقل المواد الفعلية بخلاف تلك تبدو معقدة / غامضة للغاية ولن يتم توسيع نطاقها بشكل جيد. react-transition-group على بعض المثل الجيدة للتعامل مع الجزء المنخفض المستوى من الأشياء (معالجة الدخول / الخروج ، إلخ) ، ولكنه يمثل مشكلة / في الطريق في الآخرين. أيضًا بدلاً من التصميم المستند إلى انتقالات css ، أعتقد أن طريقة التفكير المستقبلي هي استخدام واجهة برمجة تطبيقات Web Animations الجديدة وتطلب polyfill لها.
  بعبارة أخرى ، أعتقد أن هناك مجالًا لإنشاء مكتبة جديدة للتعامل مع الرسوم المتحركة في React التي تستخدم رسوم الويب المتحركة في المتصفح وواجهة برمجة التطبيقات المتحركة في React Native وهي تحسين عام على كيفية معالجة MUI للرسوم المتحركة.
• تحتاج MUI إلى التخلص من توقع توفر السلوك المتتالي. ويحتاج إعداد السمة إلى التعزيز لدعم تطبيق التعديلات بسهولة على السمة داخل الشجرة الفرعية.
  في الوقت الحالي ، تعمل أشياء مثل AppBar + Icons من خلال تعيين لون النص ، باستخدام لون واضح = 'موروث' وافتراض أن اللون سيتدرج لأسفل. ومن الممكن أن يكون هذا هو نفسه في أجزاء أخرى من MUI.
  لا يوجد تعاقب مثل هذا في React Native. بدلاً من ذلك ، يجب أن تعلن عن الأنماط الخاصة بك صراحةً لكل عرض. بالنسبة لهذه الأنواع من الأشياء ، سيحتاج AppBar والمكونات الأخرى إلى القدرة على توفير نسخة معدلة من السمة بسهولة ، حيث يتم تزويدها بتعديل مثل تغيير السمة ضمن هذا السياق إلى dark حتى تحصل الرموز على رمز التباين الصحيح الألوان (ويمكن أن تستند إلى مواصفات ألوان الرموز الفعلية بدلاً من لون النص). لاحظ أن هذا قد يكون له آثار على أشياء مثل القوائم المتداخلة في أشرطة التطبيق.
• كامتداد لهذه المشكلة المتتالية. تم تصميم MUI أيضًا حول أشياء مثل <Button>Text</Button> ، حيث يُفترض أن MUI يمكنها فقط تصميم الخط / اللون ، إلخ ... من جذر الزر ، وتتيح لك إدخال أي شيء في الأطفال ، والسماح لـ React DOM بإدراج مزيج من العناصر وعقد النص وعقد النص تحصل على التصميم الصحيح.
  هذا ينهار في React Native. يجب أن يكون كل النص جزءًا من <Text> ، ويجب أن تكون جميع أنماط النص على أنماط هذا المكون ، ولا يمكن أن يحتوي عنصر النص على عناصر فرعية غير نصية (على سبيل المثال).
  هناك عدد قليل من الخيارات:
  
  
  
  • يعمل النمط <Button text='Text' /> بشكل أفضل في React Native. لسوء الحظ ، يختلف هذا اختلافًا جوهريًا عن روح MUI ، لذا فهو ليس خيارًا.
  
  
  • يمكننا تعيين الأطفال واستبدال السلاسل بعناصر نصية. ومع ذلك ، فإن هذا هش ، في اللحظة التي تلف فيها الخيط في أي شيء يتفكك (حتى رد الفعل intl سيجعله ينهار). قرف.
  
  
  • إنها ليست أجمل طريقة للقيام بذلك ، يجب أن ننتظر ، وأنا لا أفهم 100٪ تداعيات الأداء. لكن يمكننا استخدام واجهة برمجة تطبيقات السياق الجديدة لـ React 16.3 ، وكشف <MuiText>Text</MuiText> . في الأساس ، سيكون لمكونات MUI مثل Button مزودين يقدمون معلومات حول أنماط السياق الحالي (الخط ، لون النص ، إلخ ...) ويستهلك MuiText هذه البيانات فقط ويطبقها على عنصر نص.
  
  

تم إصدار v1 اليوم فما هي خطط React Native❓

للحصول على دعم المواد الأصلية المتفاعلة ، توجد مكتبة جميلة تسمى React Native Paper والتي سيتم صيانتها ودعمها بواسطة فريق CallStack.

ولكن هل هناك أي خطط لنقل هذا إلى React Native لأنني أعتقد أن Paper يعمل بشكل جيد

إذا لم يكن كذلك ، فمن المحتمل أنه يمكنك إغلاق هذه المشكلة :)

شكرا لتقاسم deadcoder0904. لقد أضفت ورقًا إلى مكونات Awesome React . لم أسمع عن CallStack. في البداية قرأته على أنه Call-Em-All. أظن أنهم ليسوا نفس الزملاء ، يا؟

jhabdas كلاهما ليسا نفس الشيء

dantman إليكم أفكاري حول أفضل طريقة لتحقيق الدعم المحلي

• إذا لم يكن التمسك بـ jss مطلبًا مطلقًا ، فأعتقد أن fela بديل قابل للتطبيق:
  
  
  
  • يدعم برنامج fela-native استعلامات الوسائط ويستخدم StyleSheet.create بشكل صحيح
  
  
  • إنه قابل للتوسيع بجنون . يمكن أن نعيد كتابة القواعد لخصائص الويب إلى بروكسيات التفاعل الأصلية الخاصة بهم ، وتجريد أشياء مثل قواعد :hover على القواعد الأصلية ، وربما استعادة البنية التي فقدها من jss.
  
  
• رد فعل - أصلي - متحرك لديه دعم keyframe ، ويمكن استخدامه على الأرجح بدلاً من مجموعة انتقالية أيضًا ، والتي قد تعمل أو لا تعمل مع أصلي .
• أنا أتفق مع تخريب وجهة النظر غير المتتالية لرد الفعل الأصلي. يمكن أن يكون الاشتراك لدى المزود والمستهلك بدعائم cascade و inherit .
  كانت كل مكتبة تفاعلية أصلية حاولت العمل معها مؤلمة أو غير قابلة للاستخدام بسبب واجهات برمجة التطبيقات شديدة الصلابة والأنماط التي لا يمكن تجاوزها ، باستثناء تلك التي تستخدم @shoutem/theme للسماح بالتجاوزات (مثل original-base) .

لا تزال تنتظر هذا الدعم. باستخدام جميل على الويب ولكني أطور على الهاتف المحمول أيضًا!

أي تحديث حول الدعم يتفاعل الأصلي؟

oliviertassinari أعتزم التفرع والبدء في استكشاف مسار التنفيذ الذي

micimize شكرا

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

في مرحلة ما ، أود أن أعود وأنقذ بعض الأعمال التي قمنا بها ، وعلى رأسها منفذ حل التصميم withStyles / classes الذي استفاد من خصائص css-Shorthand وبعض الأشياء الأخرى الأنيقة ، ومع ذلك لم يعد أولوية لي.

قامتrogerstorm بتمويل هذه المشكلة بمبلغ 200 دولار. شاهده على IssueHunt

سيكون العمل على المشكلة تكلفة فرصة بالنسبة لنا. أنا أغلق. سنعمل على مضاعفة دعم حالات استخدام المتصفح بشكل أفضل.

oliviertassinari ، هل يعني ذلك أن رد فعل الدعم المحلي خارج النطاق وفي المستقبل القريب (على سبيل المثال ، سنة واحدة) لن يكون على الرادار؟

نعم

https://github.com/lightningtgc/react-native-material-ui ليست سوى حزمة npm احتيال أخرى