Material-ui: समर्थन प्रतिक्रिया मूल निवासी

बस इस रेपो की खोज की: https://github.com/lightningtgc/react-native-material-ui
हालांकि, यह नहीं पता कि यह अच्छा है या नहीं।

धन्यवाद @chadobado - हमने इसके बारे में निश्चित रूप से बात की है और यह शुरू करने के लिए एक मजेदार परियोजना होगी। हालाँकि, हमने इस समय इस परियोजना के साथ अपना हाथ भर लिया है। यदि हम कभी भी एक देशी पुस्तकालय बनाते हैं तो मैं इस मुद्दे को खुला और अद्यतन रखूंगा।

यह वास्तव में एक महान विचार है। मैंने रिएक्ट-नेटिव में material-ui पोर्टिंग का परीक्षण करने की कोशिश की है। हमें केवल थोड़ा स्टाइलशीट की जरूरत है, सभी div को View में बदलें, सभी h1 , h2 , आदि को Text बदलें और यह बहुत अच्छा काम करेगा। मुझे मिली एकमात्र समस्या यह है कि रिएक्ट नेटिव पूरी तरह से boxShadow समर्थन नहीं करता है, इसलिए इस समय Paper घटक को लागू करना कठिन है। साथ ही, यह बहुत अच्छा होगा यदि हम कोड को रिएक्ट-नेटिव में ऑटो-पोर्ट करने के लिए एक स्क्रिप्ट को महान बना सकते हैं क्योंकि यह बहुत अलग नहीं है।

सभी div को देखने के लिए बदलें, सभी h1, h2, आदि को टेक्स्ट में बदलें और यह बहुत अच्छा काम करेगा

क्या हम इसे करने के लिए बेबेल-प्लगइन-ट्रांसफार्मर का उपयोग नहीं कर सकते थे?

यह वास्तव में एक अच्छा विचार है

क्या आपके पास एक डेमो प्रोजेक्ट है?

@oliviertassinari

क्या हम इसे करने के लिए बेबेल-प्लगइन-ट्रांसफार्मर का उपयोग नहीं कर सकते थे?

मुझे यकीन नहीं है क्योंकि रिएक्ट नेटिव की स्टाइलशीट सीएसएस से काफी अलग है इसलिए ट्रांसफॉर्मर बनाना काफी जटिल होगा।

क्या आपके पास एक डेमो प्रोजेक्ट है?

अभी तक कारण नहीं है' मैं काफी व्यस्त हूं लेकिन मैं जल्द ही आपको एक छोटा डेमो दिखाने की कोशिश करूंगा।
लेकिन यहाँ हमें क्या करना है

स्टाइलशीट

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,
      }
})

जेडइंडेक्स समाधान

जेएसएक्स

<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 (रिएक्टिव नेटिव उपयोग object बजाय string ), mixins/style-propable.jsx को भी संशोधित करने की आवश्यकता है क्योंकि हमें कई ब्राउज़रों से निपटने की आवश्यकता नहीं है, आदि

मैं सिर्फ https://github.com/lenaten/material-ui-native में प्रतिक्रिया-मूल के लिए एक WIP फोर्किंग प्रकाशित करता हूं
वर्तमान में केवल कार्ड और राइज़बटन ही काम कर रहे हैं, लेकिन बिना स्टाइल के (WIP याद है?)

@lenaten दिलचस्प!
मैं इस परियोजना और एमआरएन (https://github.com/oliviertassinari/react-material) के बीच एक आवरण पर काम करना भी शुरू करना चाहता था।
ऐसा लगता है कि आपका कांटा केवल प्रतिक्रिया-मूल के साथ काम कर रहा है, आप इसे ब्राउज़र के साथ भी कैसे काम करेंगे?
मुझे लगता है कि यह सबसे कठिन बिंदु है और अब इसे संबोधित किया जाना चाहिए, क्योंकि आप कहते हैं कि आपके पास दो काम करने वाले घटक हैं। आप चाहें तो मैं मदद कर सकता हूं।
जैसा कि पहले कहा गया था, मैं अपने मूल कार्यान्वयन के लिए https://github.com/binggg/mrn की भी जांच करना चाहता था।

जब इसका उत्तर दिया जाता है, तो मुझे लगता है कि हम आपके कांटे को यहां वापस मर्ज कर सकते हैं।

मटेरियल-यूआई एमआरएन प्रोजेक्ट के खिलाफ परिपक्व परियोजना है जिसमें बहुत सारे भौतिक घटक छूट जाते हैं। यदि मेरा पीओसी अपवाद के रूप में काम करेगा, तो इसे क्रॉस प्लेटफॉर्म फ़ाइल संरचना में मर्ज करना आसान होना चाहिए। मेरे पास पहिया को फिर से शुरू करने और स्क्रैच प्रोजेक्ट से शुरू करने का समय नहीं है।

वैसे भी, विचारों और कोड में आपकी मदद का बहुत स्वागत है।

@oliviertassinari मुझे भी।

material-ui ब्राउज़र और मूल दोनों के साथ काम करने का मेरा विचार फ़ाइल नाम संरचना का उपयोग करना है, जिस तरह से react-active एक ही समय में आईओएस और एंड्रॉइड को संभालता है।

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

या हम अभी भी ब्राउज़र और देशी दोनों के लिए समान घटकों का उपयोग कर सकते हैं और फिर उन्हें संभालने के लिए एक रैपर लिख सकते हैं। उदाहरण के लिए, react-native View react-native का उपयोग करता है, ब्राउज़र div उपयोग करता है, फिर इसे इस तरह करें:

div.browser.jsx

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

div.native.jsx

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

ऐप-बार.जेएसएक्स

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 सामग्री-यूआई-मूल tcomb-form-native के साथ संगत है, या यदि नहीं, तो यह कितना बड़ा प्रोजेक्ट होगा?

@mvayngrib मैंने इस परियोजना पर कुछ समय के लिए काम करना बंद कर दिया ..

@lenaten यह शर्म की बात है, प्रतिक्रिया देने के लिए धन्यवाद

ठीक है, मैंने इस https://github.com/callemall/material-ui/pull/2611 में काम करना शुरू कर दिया है
इसमें कुछ समय लगने वाला है!

@oliviertassinari कमाल है! बहुत बहुत उत्साहित

तो क्या बंदरगाह प्रयास अभी भी खुला है? यदि हां, तो घटकों को लागू करने की प्रक्रिया पर क्या समझौता किया गया था?

@dorthwein यह अभी भी खुला है।

मेरे दृष्टिकोण से, प्रक्रिया निम्नलिखित है:

• [ ] प्रतिक्रिया-मूल के नवीनतम संस्करण में अपग्रेड करें और प्रतिक्रिया-मूल-वेबपैक-सर्वर को हटा दें। मैंने इसे इस परियोजना पर पहले ही कर लिया है। https://github.com/callemall/material-ui/pull/3829
• [ ] रिएक्ट-लुक के साथ खेलें और देखें कि संदर्भ से आने वाले muiTheme लिए हम इसका कितना अच्छा उपयोग कर सकते हैं। https://github.com/callemall/material-ui/pull/3829
• [x] फ़ोल्डर पुनर्गठन पर प्रतीक्षा करें ताकि हमारे पास नए घटकों को रखने के लिए कहीं न कहीं हो
• [ ] दस्तावेज़ीकरण ऐप पर काम करना शुरू करें जिसका उपयोग हम नए घटक को प्रदर्शित करने के लिए करेंगे।
• [ ] घटकों के मूल संस्करण पर काम करना शुरू करें।

@oliviertassinari - आगे बढ़ने का रास्ता तय होने के बाद मैं कुछ घटकों को पोर्ट करने में थोड़ा सा समय दे सकता हूं। अपनी सूची को देखते हुए अभी केवल अज्ञात ही प्रतिक्रिया-दिखने वाली सामग्री है?

@dorthwein हम इसे सुनकर खुश हैं।
मैं यहाँ #3829 प्रतिक्रिया-देखो का उपयोग कर रहा हूँ। मेरे पास एकमात्र मुद्दा मामूली है। प्रतिक्रिया मूल निवासी StyleSheet API के गलत उपयोग के संबंध में कुछ चेतावनी प्रदर्शित कर रहा है। मैंने इसे विस्तार से नहीं देखा है लेकिन मुझे विश्वास है कि इसे हल किया जा सकता है।

@oliviertassinari @dorthwein मुझे खुशी है कि यह प्रयास (अर्थात material-ui से react-native ) मृत नहीं है। मैं केवल यह बताना चाहता था कि एक और नया material-ui से react-native प्रोजेक्ट भी है जिसका इस थ्रेड में उल्लेख नहीं किया गया है: https://github.com/react-native-material- डिजाइन/प्रतिक्रिया-देशी-सामग्री-डिजाइन । ऐसा लगता है कि यह प्रोजेक्ट https://github.com/binggg/mrn पर आधारित है

@oliviertassinari मैंने एक और सूत्र में देखा कि अगर आईओएस का समर्थन इस बंदरगाह के लिए समझ में आता है - मुझे लगता है कि यह बिल्कुल विशेष रूप से तब होता है जब आप देखते हैं कि Google मानचित्र और अन्य Google सामग्री + आईओएस ऐप्स कैसे हैं। जहां यह समझ में आता है और एक मजबूत पूर्व मौजूदा आईओएस घटक (जैसे स्विच) है, इसे आईओएस पर आईओएस स्विच में उपयोग करना चाहिए। एंड्रॉइड और आईओएस को लागू करना भी ज्यादा बोझ नहीं है।

@oliviertassinari कॉम्पोनेन्ट . ios.js फाइल स्ट्रक्चर भी मेरे लिए सबसे ज्यादा मायने रखता है।

@oliviertassinari मैंने दस्तावेज़ों को प्राप्त करने और भाग्य चलाने की कोशिश की। कुछ मुद्दे:

• package.json: प्रतिक्रिया-मूल को पैकेज का नाम पसंद नहीं है सामग्री-यूआई - सामग्री में बदलनायूआई ने समस्या का समाधान किया
• वर्तमान सामग्री-यूआई/प्रतिक्रिया-मूल शाखा में प्रतिक्रिया-मूल पैकेजर के साथ कोई समस्या है और mainjs.bundle फ़ाइल नहीं बना रहा है। मैं समझ नहीं पा रहा था कि यहाँ क्या हो रहा है।
• मुझे मौजूदा सामग्री-यूआई रेपो के शीर्ष पर एक काम कर रहे प्रतिक्रिया-मूल ऐप नहीं मिल रहा है। अगर किसी को इस मोर्चे पर कोई भाग्य मिला है, तो यहां एक स्थिर हो जाता है कि देशी घटकों के सेट को कैसे योगदान/विकसित किया जाए।

@dorthwein प्रतिक्रिया के लिए धन्यवाद। प्रतिक्रिया-मूल शाखा अत्यधिक प्रयोगात्मक है। हमें इसे हल करने की जरूरत है।
दूसरी ओर, मुझे अपनी ओर से कोई समस्या नहीं है (https://github.com/callemall/material-ui/pull/3829)।
मुझे एक नए सिरे से शुरू करने की कोशिश करनी चाहिए git clone ।

हाँ, तो मेरे वर्तमान प्रोजेक्ट का अगला चरण मटेरियल डिज़ाइन का उपयोग करके एक मोबाइल ऐप पर काम कर रहा है - मैं इसका उपयोग करना चाहता हूँ क्योंकि इसमें हमारी सभी वेब सामग्री भी है। अगर हमें काम करने का माहौल मिल सकता है तो मैं अपनी परियोजना के साथ इसे खत्म करना शुरू कर दूंगा।

कुछ सामान पर पढ़ रहा था और एफबी रिएक्ट नेटिव पेज से इस टिडबिट को देखा।

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

यह संसाधन भी मिला - इसे अभी आज़माएं। बहुत सीधे आगे लगता है और शायद एक जेंडर के लायक है

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

@dorthwein महान विचार! लेकिन अगर हम इस रास्ते का अनुसरण करते हैं, तो मुझे लगता है कि केवल रिएक्ट नेटिव के लिए एक संस्करण विकसित करना बेहतर होगा।

हम नेटिव और डोम के लिए अलग-अलग कोड के बजाय रिएक्ट नेटिव एपीआई के तहत पूरी परियोजना को फिर से लिख सकते हैं। अद्भुत! मैंने इस बारे में कभी नहीं सोचा।

@quanglam2807 हाँ - इस तरह से नई सुविधाएँ आदि ... एक दूसरे के अनुरूप रहें। मुझे लगता है कि सबसे बड़ी चुनौती शैलियों और एनिमेशन के काम करने की है। इसके अलावा एक और बड़ा प्लस यह है कि हम धीरे-धीरे विभिन्न घटकों के लिए समर्थन जोड़ सकते हैं।

नीचे की ओर सब कुछ फ्लेक्स बॉक्स का उपयोग करने की आवश्यकता होगी।

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

@ quanglam2807 @oliviertassinari इस दृष्टिकोण के साथ एक और लाभ यह है कि सामग्री-यूआई आसानी से https://github.com/ptmt/react-native-desktop पर भी पोर्ट हो जाएगा।

@oliviertassinari प्रतिक्रिया-मूल-वेब का उपयोग कर रहा है जो इस परियोजना के अनुरक्षकों को पीछे मिल सकता है यदि यह अपेक्षित रूप से काम करता है?

@dorthwein मुझे इस परियोजना के पीछे का विचार पसंद है। लेकिन मुझे नहीं लगता कि इससे निकट भविष्य में मदद मिलेगी।
react-native-web उपयोग करने से पहले क्या हमें पहले अपने घटकों का मूल संस्करण लिखने की आवश्यकता नहीं है?

@oliviertassinari नहीं, प्रतिक्रिया-मूल-वेब क्या करता है मंच के आधार पर सबसे "मूल" घटक का उपयोग करता है। तो उदाहरण के लिए एक व्यू टैग दिया गया है, यह ब्राउज़र में एक div का उपयोग करेगा, आईओएस में एक UIView और जो भी UIView के बराबर है वह एंड्रॉइड है।

प्रक्रिया तब प्रत्येक घटक के मूल संस्करण लिखने के बजाय होगी, कि हमें मौजूदा लोगों को एच 1 और लेबल जैसी चीजों का उपयोग करने के बजाय div और स्टाइल टेक्स्ट के बजाय व्यू का उपयोग करने के लिए कनवर्ट करना होगा।

निश्चित रूप से एक छोटा उपक्रम नहीं है, लेकिन फिर प्रक्रिया कई संस्करणों को बनाने और बनाए रखने की कोशिश करने के बजाय मौजूदा घटकों को अपडेट कर रही होगी।

प्रक्रिया तब प्रत्येक घटक के मूल संस्करण लिखने के बजाय होगी, कि हमें मौजूदा लोगों को एच 1 और लेबल जैसी चीजों का उपयोग करने के बजाय div और स्टाइल टेक्स्ट के बजाय व्यू का उपयोग करने के लिए कनवर्ट करना होगा।

यह बिल्कुल मूल संस्करण लिखने जैसा लगता है जो उम्मीद है कि ब्राउज़र में भी काम करेगा। जहां तक ​​​​मुझे पता है react-native-web वेब पर मूल प्रतिक्रिया ला रहा है न कि दूसरी तरफ।
फिर भी, वही कोड साझा करना वास्तव में आसान हो सकता है: +1:।
मैंने अब तक इस lib के साथ एक छोटी सी समस्या देखी है। उनका StyleSheet.create कार्यान्वयन गतिशील मानों (muiTheme के लिए आवश्यक) का समर्थन नहीं करता है। हम इस उपयोग के मामले के लिए प्रतिक्रिया देखो का उपयोग कर सकते हैं।

@oliviertassinari आपका अधिकार - मैं इसे पीछे की ओर समझ रहा था। चरण 1 ऐसा लगता है कि अभी भी घटकों के प्रतिक्रिया-मूल संस्करण बना रहा है। चरण 2 प्रतिक्रिया-मूल वेब जैसी किसी चीज़ का उपयोग करके संभावित रूप से उन्हें एकल कोड आधार में विलय कर देगा।

@wordyallen : अच्छा लग रहा है

@pgangwani मैंने अभी इसके साथ खिलवाड़ करना शुरू किया है ... यह अभी तैयार नहीं है।

मैं अंतराल को भरने के लिए https://github.com/react-native-material-design/react-native-material-design का उपयोग कर रहा हूं लेकिन यह किनारों के आसपास भी बहुत मोटा है और कोई सक्रिय विकास नहीं है

मैं इस प्रयास के लिए आर्थिक रूप से दान करूंगा, अगर मैं कर सकता हूं ।

हाय दोस्तों,

मैं प्रतिक्रिया-मूल-सामग्री-यूआई पर काम करता हूं, जो इस पुस्तकालय से प्रेरित है। कोशिश करने के लिए स्वतंत्र महसूस करें - मैं कोई प्रतिक्रिया सुनना चाहता हूं;)

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

मुझे नहीं लगता कि बहुत आम कोड है, मुझे लगता है कि स्क्रैच से बनाना समझ में आता है। RN में स्टाइलिंग इससे 90% अलग होगी। और एनिमेशन जैसे कुछ प्लेटफॉर्म विशिष्ट मैकेनिक हैं ...

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

मैं @jhabdas से सहमत

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

एफडब्ल्यूआईडब्ल्यू, इसने मेरी आंख पकड़ ली।

react-native-material-kit लिए वेब समर्थन पर @necolas :

यदि कोई स्टाइलशीट अनुकूलता के रूप में रिएक्ट नेटिव के वेब कार्यान्वयन द्वारा प्रदान की जाती है, तो आपको बहुत अधिक पोर्ट करने की आवश्यकता नहीं है

@jhabdas यदि आप प्रतिक्रिया देशी के साथ थोड़ा सा खेलते हैं तो आप देखेंगे कि यह इतना सीधा नहीं है। स्टाइलशीट एपीआई बहुत बढ़िया है लेकिन आपको कुछ चीजें फिर से लिखनी होंगी;)

उचित बिंदु @antoinerousseau। मैं आरएन पर जेम्स लॉन्ग के एक उद्धरण के बारे में सोचता रहता हूं:

इसे वेब के लिए एक अलग दिशा के लिए एक प्रोटोटाइप के रूप में सोचें

अगर मैं पुस्तकालय के उद्देश्य को समझ रहा हूं @necolas काम कर रहा है तो ऐसा लगता है कि समस्या को रिएक्ट नेटिव मटेरियल किट में पहले से ही समस्या पर अच्छी छलांग है।

चूंकि react-native-web बहुत बढ़िया दिखाई देता है, मैं बस अपने निजी प्रोजेक्ट में material-ui.android.js , material-ios.ios.js , और material-ui.web.js फाइलें बनाने जा रहा हूं और इसे अच्छा कह रहा हूं। अगर मैं बाकी सब कुछ लपेटकर material-ui एपीआई का पालन करता हूं, तो यह अंततः काम करेगा। यदि material-ui मुझे आश्चर्यचकित करता है और बस काम करता है, तो मुझे केवल .web को .web.js से निकालने और अन्य फ़ाइलों को हटाने की आवश्यकता होगी। इस तरह मैं चुनिंदा रूप से material-ui प्रति घटक में संक्रमण कर सकता हूं।

@oliviertassinari इसलिए मैंने NPM निर्भरता के रूप में react-native शाखा को जोड़ा और सभी बैबेल प्लगइन्स को स्थापित किया। किसी भी घटक को आयात करते समय मुझे यह संदेश मिला:

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 मीडिया प्रश्नों को निष्पादित करता है? क्या हमें चाहिए?

आप एक जटिल थीमिंग समाधान को कैसे संभालते हैं?

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

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

मैंने इसका उपयोग भी नहीं किया है लेकिन थीमिंग संदर्भ के लिए react-tunnel जैसा कुछ अच्छा लगता है। हम केवल इसका उपयोग और खुलासा कर सकते हैं, केवल इसलिए कि यह अधिक समुदाय साझा करने योग्य लगता है। एक अधिक लोकप्रिय समकक्ष हो सकता है।

कितना प्रतिक्रिया देशी वेब उत्पादन तैयार है? उदाहरण के लिए मैंने दृश्य परीक्षण नहीं देखा है।

यहाँ इंटरैक्टिव उदाहरण हैं: https://necolas.github.io/react-native-web/storybook/

आप मीडिया के सवालों को कैसे हैंडल करते हैं?

जावास्क्रिप्ट में, matchMedia (या Dimension का उपयोग करके) यह निर्धारित करने के लिए कि कौन सी शैलियों और घटकों को प्रस्तुत करना है।

इसमें क्रॉस-प्लेटफ़ॉर्म एंकर-टैग href घटक नहीं है

हाँ, मुझे यकीन नहीं है कि "उचित" समाधान क्या होना चाहिए, लेकिन आप अभी के लिए View और Text जैसे लिंक का उपयोग कर सकते हैं (केवल वेब समर्थन, निश्चित रूप से):

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

आप एक जटिल थीमिंग समाधान को कैसे संभालते हैं?

रिएक्ट नेटिव को कोई फर्क नहीं पड़ता कि आप यह कैसे करते हैं। आप अभी भी context का उपयोग यह निर्धारित करने के लिए कर सकते हैं कि कौन सी शैली वस्तुओं को लागू करना है। मुझे घटकों के भीतर फेला का एपीआई काफी पसंद है, लेकिन अगर आप react-native-web का उपयोग करते हैं तो कार्यान्वयन और प्लगइन एपीआई ओवरकिल की तरह दिखता है।

परिणाम को गैर-"वेब" प्लेटफ़ॉर्म विशिष्ट संगत शैलियों में बदलने/फ़िल्टर करने के लिए हमें केवल createStyleSheet समकक्ष विधि को लपेटना होगा।

क्या समस्या यह है कि आप एक स्टाइल एपीआई का पर्दाफाश करते हैं जो आरएन संगत नहीं है? यदि ऐसा है, तो मेरा सुझाव है कि आप एक RN-संगत शैली API का पर्दाफाश करें और react-native-web इसे DOM शैलियों में बदलने दें।

@necolas

क्या समस्या यह है कि आप एक स्टाइल एपीआई का पर्दाफाश करते हैं जो आरएन संगत नहीं है? यदि ऐसा है, तो मेरा सुझाव है कि आप एक आरएन-संगत शैली एपीआई का पर्दाफाश करें और प्रतिक्रिया-मूल-वेब को इसे डीओएम शैलियों में परिवर्तित करने दें।

अच्छी बात। क्या react-native-web में उदाहरण के लिए :hover भावना है?

@necolas और मैं जो विशेष कार्य कर रहा हूं, उसे केवल सदाबहार ब्राउज़रों का समर्थन करने की आवश्यकता है, लेकिन क्या react-native-web को पोर्ट करने की संभावना है कि किसी भी पुराने संस्करणों के साथ material-ui ब्राउज़र संगतता खर्च होगी? मैं वास्तव में इसके बारे में कुछ नहीं जानता। मुझे सच में लगता है कि react-native-web सही तरीका है।

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

मुझे यकीन नहीं है कि आपको किस ब्राउज़र समर्थन की आवश्यकता है, लेकिन समस्या आने पर इसे समायोजित करने में सक्षम हो सकता है

मुझे लगता है कि react-native-web बनाम react-dom घटक शैली एपीआई के बीच चयन करने के लिए MuiThemeProvider माध्यम से घटक पदानुक्रम संदर्भ में एक बूलियन इंजेक्ट करना आवश्यक हो सकता है।

सबसे अच्छा जवाब सिर्फ react-native-web स्टाइल एपीआई पर स्विच करना है, और यही मैं वकालत करता हूं, लेकिन इससे शायद परेशान हो जाएगा।

@oliviertassinari क्या हम material-ui को react-native स्टाइल एपीआई पर स्विच करने से दूर हो सकते हैं? हो सकता है कि माउस विशिष्ट शैलियों को लीक होने दें?

@necolas @oliviertassinari एक FYI करें। यह अभी मैला है, लेकिन मैं पिछले 2-3 दिनों से एक शाखा (https://github.com/mattferrin/material-ui-build/tree/mine) को क्रॉस-प्लेटफॉर्म पर पोर्ट करने पर काम कर रहा हूं क्योंकि मैं वास्तव में मुझे इसकी आवश्यकता है (लंबी अवधि में मेरे कुल काम को कम करने के लिए)।

मैं सब कुछ react-native-web सिंटैक्स में पोर्ट कर रहा हूं और उन शैलियों पर टिप्पणी कर रहा हूं जो पोर्ट नहीं करते हैं, लेकिन मुझे लगता है कि मैं मूल कोड को अनिवार्य रूप से बनाए रखने के लिए Platform.OS == 'web' का उपयोग करके उन्हें वापस टिप्पणी कर दूंगा जिस वेबसाइट पर मैं काम कर रहा हूं उसे पोर्ट करने के बाद अपरिवर्तित। उस समय केवल वही चीज़ें जो मुझे व्यक्तिगत रूप से चाहिए उन्हें पोर्ट किया जाएगा और अपूर्ण रूप से।

यह पूरी तरह से गड़बड़ है (जब तक कि मैं इसे बाद में स्पर्श नहीं करता) क्योंकि मैं मक्खी पर मैक और विंडोज मशीनों के बीच कूदने के लिए धक्का देता हूं।

जो लोग एमयूआई के आरएन में आने का इंतजार नहीं कर सकते, उनके लिए विकल्प हैं, और कुछ बहुत अच्छे दिखने वाले हैं। मैं यहाँ एक सदाबहार सूची बना रहा हूँ: https://habd.as/awesome-react-components/#react -native

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

@mattferrin खरोंच से बिल्कुल नहीं (हालांकि कुछ मामलों में यह सच है, उदाहरण के लिए Table ) हालांकि शैली समाधान परिवर्तन के लिए कई एपीआई परिवर्तनों की आवश्यकता होती है, लेकिन इसके अलावा हमें कई घटकों के लिए अन्य क्षेत्रों में एपीआई को युक्तिसंगत बनाने का अवसर मिलता है। . मुझे खेद है कि यदि आपके प्रयास व्यर्थ गए - मुझे आशा है कि यह आपको सामग्री-यूआई से दूर नहीं करेगा!

@mbrookes यह नहीं है। मैं बंद शाखाओं की गलती की master के बजाय next और अंतर (और सामान्य में कुल काम) underestimating। यह मेरी गलती थी और मुझे पता था कि जोखिम था। मैं बस खाली Text तत्वों को प्लेसहोल्डर के रूप में बाद में अपने रिएक्ट नेटिव material-ui मुखौटा में वापस कर दूंगा। जब मैंने अपनी वेबसाइट को पूरी तरह से react-native-web पर पोर्ट कर लिया है, तो मैं वापस आऊंगा और next से नए परिवर्तनों को रीबेस करने का प्रयास करूंगा।

आज इस आदमी को रिहा कर रहा हूँ: https://carbon-ui.com

सामग्री-यूआई से प्रेरित, वेब पर काम करता है और प्रतिक्रिया-मूल :)

@tuckerconnelly आपने मेरा दिन बना दिया

@tuckerconnelly वाह, इस परियोजना पर बहुत संभावनाएं हैं ... अच्छा किया! यहाँ उम्मीद है कि इस प्रयास के पीछे बड़ा समुदाय रैली करेगा! मैं

@tuckerconnelly मैं थोड़ा भ्रमित हूँ। मैंने पाया कि material-ui सशर्त रूप से क्रॉस-प्लेटफ़ॉर्म बनाना वास्तव में बहुत आसान है ( master बजाय next और अपना समय बर्बाद करने की मेरी गलती के बावजूद)। मैं उत्सुक हूं कि आप एक स्वतंत्र परियोजना के लिए क्या लाभ देखते हैं?

मैंने इसे फरवरी में वापस करने की कोशिश की, और इसके साथ एक कठिन समय था, विशेष रूप से लहर घटक के साथ और क्रॉस-प्लेटफ़ॉर्म मीडिया प्रश्नों के साथ।

कभी-कभी खरोंच से शुरू करना आसान होता है।

मेरे लिए रिएक्ट घटकों के होने का कोई मतलब नहीं है जो रिएक्ट नेटिव पर काम नहीं करते हैं ... और चूंकि मटेरियल-यूआई के डेवलपर्स ने आरएन को प्राथमिकता नहीं माना है ... नए रास्ते पर शुरू करना केवल उचित/तार्किक है

@tuckerconnelly मुझे नहीं लगता कि यह मायने रखता है कि घटकों को कैसे लागू किया जाता है। मुझे उम्मीद है कि दोनों परियोजनाएं अपने घटकों के लिए एक ही एपीआई (और समान नामों पर सहमत) को लागू करने का प्रयास करती हैं। मुझे खुशी है कि आपने इस पर काम किया और साझा किया।

तो v1.0.0 के बाद 2017/2018 के लिए आरएन सामग्री-यूआई के लिए अगला लक्ष्य होगा?

के रूप में देखा:

• v1 . में समुदाय की भागीदारी
• जितने लोग RN सपोर्ट चाहते हैं
• तथ्य यह है कि कई परियोजनाएं आरएन घटकों की पेशकश करने के लिए सामग्री-यूआई द्वारा आधारित या प्रेरित हैं
• इस सब से अनुभव प्राप्त हुआ और तथ्य यह है कि इस मुद्दे को खोले जाने में काफी समय बीत चुका है

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

@NitroBAY 1.0 स्टाइल के लिए JS ऑब्जेक्ट्स के बजाय JSS का उपयोग करता है, इसलिए यह रिएक्ट नेटिव को सपोर्ट करने के लिए cssinjs/jss#368 पर निर्भर करता है। लेकिन मुझे लगता है कि इस तरह रिएक्ट नेटिव के लिए एक समानांतर संस्करण विकसित करना बेहतर है: https://github.com/xotahal/react-native-material-ui। फिर हम https://github.com/necolas/react-native-web का उपयोग करके वेब पर रिएक्ट नेटिव संस्करण चला सकते हैं

तो क्या यह कोई फिक्स नहीं है? यदि ऐसा है तो कृपया इसे इस तरह टैग किया जा सकता है?

@jhabdas मुझे रिएक्ट नेटिव में सामग्री विनिर्देश लाने के लिए एक अच्छी लाइब्रेरी देखना अच्छा लगेगा।
थ्रेड में पोस्ट किए गए लिंक से, उम्मीदवारों की एक अच्छी सूची पहले से ही है।

अगर हम उस मुद्दे को खुला रखते हैं तो यह वेब और देशी को एकीकृत करने के संबंध में है। दो प्लेटफार्मों के बीच एक सुसंगत एपीआई प्रदान करना। काश मेरे पास उस पर काम करने का समय होता लेकिन मैं नहीं करता और मुझे संदेह है कि यह बदलने वाला है।
@ कैलेमॉल/मटेरियल-यूआई टीम किसी को उस मुद्दे पर आगे बढ़ते हुए देखना पसंद करेगी।

अभी भी कार्बन-यूआई का समर्थन :) मैं केवल घटकों को जोड़ता हूं क्योंकि मुझे उनकी आवश्यकता है (पूरी कल्पना को सक्रिय रूप से भरने की कोशिश नहीं कर रहा है), लेकिन मुझे लगता है कि लोगों के पीछे रैली करने के लिए वहां एक अच्छा ढांचा है।

• यह घटक टिप्पणियों से डॉक्स स्वतः उत्पन्न करता है
• डॉक्स साइट है (carbon-ui.com)
• समान घटकों के साथ मूल और वेब का समर्थन करता है

जो कोई भी घटक जोड़ना चाहता है उसकी मदद करेगा :)

@tuckerconnelly आप https://github.com/xotahal/react-native-material-ui के बारे में क्या सोचते हैं https://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.js पर लागू किया है, तो मुझे लगता है कि यह काम करेगा। @oliviertassinari एक अच्छा मुद्दा बनाता है कि हमें एक साथ काम करने के लिए एक मुख्य परियोजना पर निर्णय लेने की जरूरत है।

@quangbuule प्रतीक्षा करें कि आप कहते हैं कि हमें आरएन ऐप्स के रूप में ऐप्स विकसित करना चाहिए और फिर उस टूल का उपयोग आरएन को वेब संस्करण में बदलने के लिए करना चाहिए?
मैंने उस बात के बारे में कभी नहीं सुना लेकिन ठीक है। लेकिन फिर इसका मतलब है कि हम अब material-ui नहीं करेंगे बल्कि एक RN कांटा का अधिक उपयोग करेंगे?

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

सभी नोब प्रश्नों के लिए क्षमा करें, लेकिन मैं लगभग 1 सप्ताह से ReactLand में उतरा हूं।

आपको लगता है कि आपका पैकेज इसे बदलने जा रहा है?
आप दृष्टिकोण बहु-प्लेटफ़ॉर्म प्रतीत होते हैं और बहुत अच्छे हैं। मटेरियल-यूआई केवल वेब से चिपके रहते हैं क्योंकि उनके पास समय नहीं है लेकिन उनके पास आगे के लिए समय है, क्यों?
आप कहते हैं कि next next पर आइसोमॉर्फिक दृष्टिकोण का उपयोग करें, लेकिन अगर मैं जो भी घटक यानी कागज लेता हूं तो यह केवल वेब के लिए काम करेगा क्योंकि इसमें div घटक है।
कौन हैं we , क्या आप इस टीम का हिस्सा हैं ?
तकनीकी कारणों के बावजूद, क्या आपको नहीं लगता कि IOS पर MD का उपयोग करने से उपयोगकर्ता परेशान हो सकते हैं?

संपादित करें: विषय से हटकर लेकिन किसी ने मुझे उत्तर नहीं दिया, जब इसकी तुलना jss-react करने की बात आती है तो jss-theme-reactor क्या लाभ लाता है?

@ नाइट्रोबे :

1. मैं इस प्रोजेक्ट या किसी रिएक्ट नेटिव प्रोजेक्ट का डेवलपर नहीं हूं। लेकिन मैंने इस मुद्दे को महीनों तक देखा है, और फिलहाल, मैं react-native-material-ui योगदान देना शुरू करने के लिए उत्सुक हूं।
2. paper या शैडो थिंग अब वेब, आईओएस, एंड्रॉइड पर काम कर रहा है। तो यह कोई बड़ी बात नहीं है।
3. material-ui master शाखा स्टाइलशीट को परिभाषित करने के लिए वस्तुओं का उपयोग करती है लेकिन प्रदर्शन में सुधार करने के लिए (30% बढ़ावा), योगदानकर्ता next शाखा में JSS (JS में CSS) पर स्विच करते हैं। फिलहाल, जेएसएस रिएक्ट नेटिव के साथ संगत नहीं है।
4. Google iOS पर मटीरियल डिज़ाइन का उपयोग करता है और मुझे नहीं लगता कि उपयोगकर्ता बहुत अधिक ध्यान देते हैं। बेशक, आपको प्लेटफ़ॉर्म में फ़िट होने के लिए कुछ हिस्सों को संशोधित करना चाहिए जैसे कि स्टेटस बार का रंग बदलना, iOS शेयरिंग आइकन का उपयोग करना, आदि। मैंने अपने विंडोज 10 और मैकओएस ऐप के लिए material-ui उपयोग किया और मैंने बहुत कुछ नहीं देखा उपयोगकर्ताओं ने इसके बारे में शिकायत की (http://moderntranslator.com/)। कुछ ने यह भी कहा कि एमडी का उपयोग करना आसान था।

लेकिन मुझे अभी भी समझ में नहीं आया कि next शाखा आरएन में किस तरह काम कर सकती है यदि घटक HTML तत्वों जैसे span या div । मुझे कुछ याद आ गया होगा लेकिन आरएन में विकसित करने के लिए आपको आरएन घटकों का उपयोग करने की आवश्यकता है, है ना?
मैं आपको उद्धृत कर रहा हूं:

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

लेकिन क्या मैं इसे सही ढंग से नहीं मिला। क्या आपका मतलब है next शाखा हमें RN में घटकों का उपयोग करने में सक्षम बनाएगी?

@NitroBAY : next शाखा material-ui को रिएक्ट नेटिव के साथ कम संगत बनाएगी। इसके अलावा, भले ही आरएन घटक सशर्त नियमों का उपयोग करके स्पैन या डिव का समर्थन नहीं करता है, आप कुछ इस तरह कर सकते हैं:

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

आप देख सकते हैं: https://github.com/necolas/react-native-web

ओह ठीक है, मैंने सोचा कि आपका मतलब है कि उन्होंने आरएन को संगत बनाया है।

क्या टीएल; डीआर है कि इस परियोजना को रिएक्ट नेटिव एपीआई के माध्यम से बहु-मंच समर्थन में कोई दिलचस्पी नहीं है, और यह प्रयास https://github.com/xotahal/react-native-material-ui पर जाना चाहिए

कार्बन-यूआई के लिए डॉक्स बेहतर हैं, और यह पहले से ही वेब पर काम करता है। प्रतिक्रिया देशी-सामग्री-ui का क्या फायदा है?

तो सभी सहमत हैं कि material-ui का उपयोग बंद कर दिया जाएगा और कुछ ही समय में सिफारिश की जाएगी? तो यह अफ़सोस की बात है कि इस पैकेज के मालिक आरएन नहीं चाहते हैं?

carbon-ui ऐसा लगता है कि इसमें StyleSheet का उपयोग न करने और इतने सारे वेब फोंट को इंजेक्ट करने से प्रदर्शन संबंधी समस्याएं होंगी

शांत हो जाओ, दोस्तों! यह अभी भी आ रहा है।

टीएल; डीआर: यदि आप रिएक्ट नेटिव के लिए एक घटक बनाते हैं, तो यह आरएन और वेब पर काम करेगा। लेकिन अगर आप वेब के लिए एक कंपोनेंट बनाते हैं, तो यह RN पर काम नहीं करेगा। और material-ui वेब के लिए बनाया गया है, वेब के लिए अनुकूलित => इसे 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

@नेकोलस #4066

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

सबसे बड़ा प्रदर्शन हिट एनिमेटेड से आता है: https://github.com/animatedjs/animated/issues/48 लेकिन यह सभी RNW अनुप्रयोगों को प्रभावित करता है।

क्या वेब फोंट लगाने से प्रदर्शन में सार्थक कमी आती है? यह उन्हें सीधे Google फोंट से लोड करता है, इसलिए वे पहले से ही उपयोगकर्ता के सिस्टम पर कैश्ड होने की संभावना रखते हैं।

मुझे लगता है कि सबसे महत्वपूर्ण बात यह है कि हर किसी के लिए एक पुस्तकालय के पीछे रैली करना है। और मुझे नहीं लगता कि सामग्री-यूआई रिएक्ट नेटिव का समर्थन करने जा रहा है।

@necolas TL; DR यह है कि आगे जाने का रास्ता अस्पष्ट है ।

ए = प्रतिक्रिया-मूल
बी = वेब

1. सबसे विवश मंच

एक संभावित दृष्टिकोण सबसे विवश मंच को लक्षित करना है, इसलिए प्रतिक्रिया-मूल से शुरू करना। फिर सुविधाओं को वेब पर विस्तारित करने के लिए। वेब पर सुविधाओं का विस्तार करने के लिए, हम इसका उपयोग कर सकते हैं:

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

हालाँकि, यह एक ट्रेडऑफ़ के साथ आता है, हम कोड साझाकरण जीतेंगे। लेकिन मैं कुछ आयामों में हारने की उम्मीद कर रहा हूं।

देशी एपीआई को वेब पर लाना

ब्राउज़र के साथ काम करने के लिए एपीआई को फिर से लागू करना होगा। ओवरहेड क्या है?

देशी में लापता वेब एपीआई को संभालना

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

2. कम विवश मंच

एक अन्य समाधान कम सीमित प्लेटफॉर्म से शुरू करना है, इसलिए web. फिर लापता मूल सुविधाओं को फिर से लागू करना।

हालाँकि, यह एक ट्रेडऑफ़ के साथ आता है, हम कोड साझाकरण जीतेंगे। लेकिन मैं कुछ आयामों में हारने की उम्मीद कर रहा हूं।

वेब एपीआई को मूल में लाना

हमें बलिदान देना होगा, मैं उम्मीद कर रहा हूं कि कुछ वेब फीचर देशी पर लागू करना वास्तव में कठिन होगा, उदाहरण के लिए, सीएसएस मीडिया प्रश्न, सीएसएस एनिमेशन। (उन्नत सीएसएस नियम)

वेब में लापता देशी एपीआई को संभालना

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

3. अनुबंध साझा करना

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

• जब हम CSS ट्रांज़िशन का उपयोग कर सकते हैं तो ब्राउज़र पर एनिमेटेड.जेएस का उपयोग क्यों करें?
• जब हम मूल घटक का उपयोग कर सकते हैं तो प्रतिक्रिया-मूल पर दराज तर्क क्यों लागू कर रहे हैं?

मुझे लगता है कि विकल्प 3 सबसे आशाजनक है। इस तरह मैंने प्रतिक्रिया-स्वाइप-विचारों में समस्या को हल करने का प्रयास किया है।

https://github.com/tuckerconnelly/uranium क्रॉस-प्लेटफ़ॉर्म मीडिया प्रश्नों का समर्थन करता है :)

आरएन की खूबी यह है कि आपके पास अमूर्त एपीआई और आदिम का एक सरल पुस्तकालय है, और निम्न-स्तरीय कार्यान्वयन का ध्यान रखा जाता है। एनिमेटेड समान है - एनिमेशन के लिए सरल पुस्तकालय, निम्न-स्तरीय कार्यान्वयन (आईओएस/एंड्रॉइड पर देशी एनिमेशन, वेब पर सीएसएस संक्रमण) का ध्यान रखा जाता है।

मुझे लगता है कि एनिमेटेड.जेएस को सीएसएस ट्रांज़िशन का उपयोग करने के लिए जोड़ा जा सकता है। निश्चित रूप से प्रदर्शन में सुधार होगा।

@quanglam2807 वह धागा बहुत लंबा है, मुझे क्या देखना चाहिए?

वेब पर सुविधाओं का विस्तार करने के लिए, हम इसका उपयोग कर सकते हैं: https://github.com/necolas/react-native-web , https://github.com/taobaofed/react-web

react-web प्रदर्शनकारी या कार्यात्मक रूप से सही IMO होने से बहुत दूर है।

ब्राउज़र के साथ काम करने के लिए एपीआई को फिर से लागू करना होगा। ओवरहेड क्या है?

ओवरहेड किन आयामों में? बंडल-आकार के संदर्भ में निर्धारित करना कठिन है। आप शायद अपने कुछ मौजूदा कोड को छोड़ने में सक्षम होंगे; लेकिन अगर आप आरएनडब्ल्यू कोर निर्यात से परे किसी भी चीज पर निर्भर थे, तो यह जल्दी से जुड़ जाएगा। mobile.twitter.com के लिए स्टाइल-हैवी कंपोनेंट्स में, मैंने कंपोनेंट साइज को css-मॉड्यूल से RNW स्टाइलशीट में कनवर्ट करने वाले कंपोनेंट्स के आकार में 20-40% की कमी देखी है। रनटाइम प्रदर्शन के संदर्भ में, यह वर्तमान में css-modules से बहुत दूर नहीं है ।

मीडिया के सवालों के बारे में क्या?

आप शैलियों और घटक संरचना को बदलने के लिए matchMedia का उपयोग कर सकते हैं, हालांकि घटकों को बदलने के लिए मीडिया प्रश्नों का उपयोग करने के लाभ मुझे स्पष्ट नहीं हैं।

सीएसएस विरासत, सीएसएस एनिमेशन?

RNW CSS एनिमेशन का समर्थन करता है (हालाँकि मुझे कीफ़्रेम को परिभाषित करने के लिए एक API जोड़ने की आवश्यकता है)। CSS इनहेरिटेंस से संबंधित प्रश्न क्या है?

हम मूल संस्करण को ब्लो किए बिना एक्सेसिबिलिटी और कीबोर्ड इवेंट कैसे लागू करेंगे?

निश्चित नहीं इसका क्या मतलब। मुझे संदेह है कि एक देशी ऐप में "ब्लोट" के लिए दहलीज एक वेब ऐप की तुलना में कहीं अधिक है।

इसलिए शायद तुलना करना कि कैसे प्रतिक्रिया-मूल-वेब सीएसएस-मॉड्यूल प्रदर्शन के लिए सीएसएस प्रदर्शन प्रस्तुत करने के लिए शैलियों को संभालता है, अब कम प्रासंगिक है

ऐसा क्यों होगा?

एक प्रकार का प्रतिक्रिया-मूल-वेब होना बहुत अच्छा होगा जो एफ़्रोडाइट या जेएसएस जैसे कुछ का उपयोग करता है

ये दोनों पुस्तकालय धीमे, बड़े और नियतात्मक शैली प्रदान करने के लिए उपयुक्त नहीं हैं

@necolas material-ui css-in-js मेथड से स्टाइलशीट मेथड ( <style> में css) में स्विच करने के लिए एक बेहतरीन प्रयास प्रदान कर रहा है। वे घटकों को बदलने के लिए महीनों से सक्रिय प्रयास कर रहे हैं। कारण यहाँ हैं । जेएसएस का उपयोग करके मैंने जो पढ़ा है उससे एक बड़ा फायदा है और अब तक शैली को संभालने का सबसे सही समाधान प्रतीत होता है।

वैसे रोडमैप.एमडी को दोबारा पढ़कर रोडमैप पर आरएन सपोर्ट है।

मुझे प्रतिक्रिया-मूल, प्रगति पर किसी भी शब्द के साथ सामग्री-यूआई का उपयोग करने में बहुत दिलचस्पी है?

@wswoodruff आप इसे अभी के लिए देख सकते हैं - https://github.com/xotahal/react-native-material-ui

वर्तमान में, हमारे पास इसके लिए तीन अद्भुत पुस्तकालय हैं:

• प्रतिक्रिया देशी सामग्री किट ★3110 - मूल निवासी प्रतिक्रिया करने के लिए सामग्री डिजाइन लाना।

• प्रतिक्रिया-मूल-सामग्री-डिज़ाइन ★2447 - प्रतिक्रिया मूल सामग्री डिज़ाइन घटक

• रिएक्ट-नेटिव-मटेरियल-यूआई ★1040 - रिएक्ट नेटिव के लिए अत्यधिक अनुकूलन योग्य सामग्री डिजाइन घटक।

आनंद लेना!

यदि आप सार्वभौमिक जा रहे हैं तो कम ज्ञात कार्बन UI भी है। लेकिन अपने समय के लिए मैं शायद इनमें से

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

यदि उस प्रकार के आदिम का उपयोग किया जाता है, तो प्रतिक्रिया-स्केचअप और प्रतिक्रिया-पीडीएफ जैसे अन्य उपकरण भी सक्षम किए जा सकते हैं।

व्यक्तिगत रूप से, वे मूल निवासी की तुलना में मेरे लिए अधिक दिलचस्प हैं, लेकिन उन्हीं परिवर्तनों से सक्षम होंगे।

@jhabdas कार्बन यूआई का उपयोग करने का आपका अनुभव कैसा है? Bcz मेरे लिए यह बहुत अच्छा लग रहा है लेकिन अभी तक इसका उपयोग नहीं किया है।

@ deadcoder0904 ने इसे अभी तक व्यक्तिगत रूप से उपयोग नहीं किया है। शायद अनंत लाल रंग के लोगों में से किसी एक तक पहुंचने का प्रयास करें। वे आरएन न्यूजलेटर चलाते हैं और उन्हें विषय-विशेषज्ञ होना चाहिए। यदि और जब मैं एक और आर एन ऐप्लिकेशन का निर्माण करते हैं (ठीक है, जब ...) मैं चीजों को एक साथ इस समय clobbering नहीं किया जाएगा या निर्माण एक और बॉयलरप्लेट -IMHO अंतरिक्ष से हल किया जाता है मौजूदा boilerplates और घटकों ।

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

• JSS को RN का समर्थन करने की आवश्यकता है, अर्थात् स्टाइल ऑब्जेक्ट को इस तरह से बनाना कि withStyles बस काम करे। इस बारे में अधिक जानकारी https://github.com/cssinjs/jss/issues/368#issuecomment -376708219 में
• यह मानते हुए कि कोई हैकी रैपर या बेबेल ट्रांसफॉर्म नहीं है, हमें classes पैटर्न को बढ़ाने की आवश्यकता होगी ताकि यह वही काम करे लेकिन इस तथ्य के लिए जिम्मेदार है कि आरएन पर इसे style बजाय एक सरणी पास करनी चाहिए , और संभवत: इसका नाम styles होना चाहिए। शायद इसे classnames छोड़कर और फैलाने योग्य सहायकों को जोड़कर संभाला जा सकता है जो पर्दे के पीछे कक्षाओं/वर्गनाम हैंडलिंग और शैलियों/शैलियों के बीच स्विच करते हैं।
  शायद:
  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 में चीजों के निम्न स्तर के हिस्से (प्रवेश/निकास प्रबंधन, आदि) को संभालने के लिए कुछ अच्छे आदर्श हैं, लेकिन यह समस्याग्रस्त/दूसरों के रास्ते में है। इसके अलावा सीएसएस संक्रमण आधारित डिजाइन के बजाय मुझे लगता है कि आगे बढ़ने का तरीका नए वेब एनिमेशन एपीआई का उपयोग करना होगा और इसके लिए पॉलीफिल की आवश्यकता होगी।
  दूसरे शब्दों में, मुझे लगता है कि रिएक्ट में एनिमेशन को संभालने के लिए एक नई लाइब्रेरी के निर्माण के लिए जगह है जो ब्राउज़र में वेब एनिमेशन और रिएक्ट नेटिव में एनिमेटेड एपीआई का उपयोग करती है और एमयूआई एनीमेशन को कैसे संभालती है, इस पर एक सामान्य सुधार है।
• एमयूआई को इस उम्मीद को त्यागने की जरूरत है कि कैस्केडिंग व्यवहार उपलब्ध है। और सबट्री के भीतर थीम में संशोधनों को आसानी से लागू करने में सहायता के लिए थीम सेटअप को बढ़ाने की आवश्यकता है।
  अभी AppBar + Icons जैसी चीज़ें टेक्स्ट रंग सेट करके काम करती हैं, एक स्पष्ट रंग = 'विरासत' का उपयोग करके और यह मानते हुए कि रंग नीचे गिर जाएगा। और यह संभव है कि एमयूआई के अन्य भागों में भी ऐसा ही हो।
  रिएक्ट नेटिव में इस तरह का कोई कैस्केडिंग नहीं है। इसके बजाय आपको प्रत्येक दृश्य के लिए अपनी शैलियों को स्पष्ट रूप से घोषित करना होगा। इस प्रकार की चीजों के लिए ऐपबार और अन्य घटकों को आसानी से थीम का एक संशोधित संस्करण प्रदान करने में सक्षम होने की आवश्यकता होगी, उन्हें उस संदर्भ में थीम को dark बदलने जैसे संशोधन के साथ प्रदान किया जाता है ताकि आइकन सही विपरीत आइकन प्राप्त कर सकें रंग (और टेक्स्ट रंग के बजाय वास्तविक आइकन रंग कल्पना पर आधारित हो सकते हैं)। ध्यान दें कि इसका ऐप बार में नेस्टेड मेनू जैसी चीज़ों पर प्रभाव पड़ सकता है।
• इस व्यापक मुद्दे के विस्तार के रूप में। एमयूआई को <Button>Text</Button> जैसी चीजों के आसपास भी डिज़ाइन किया गया है, जहां यह माना जाता है कि एमयूआई बटन की जड़ के फ़ॉन्टफेस/रंग इत्यादि को स्टाइल कर सकता है, आपको बच्चों में कुछ भी डालने देता है, और बस रिएक्ट डोम डालने दें तत्वों और टेक्स्ट नोड्स के मिश्रण और टेक्स्ट नोड्स को सही स्टाइल मिलता है।
  यह रिएक्ट नेटिव में अलग हो जाता है। सभी पाठ एक <Text> का हिस्सा होना चाहिए, सभी पाठ शैलियाँ उस घटक की शैलियों पर होनी चाहिए, और एक पाठ तत्व में गैर-पाठ बच्चे नहीं हो सकते हैं (अर्थात)
  कुछ विकल्प हैं:
  
  
  
  • रिएक्ट नेटिव में <Button text='Text' /> पैटर्न काफी बेहतर काम करता है। दुर्भाग्य से यह मूल रूप से एमयूआई के लोकाचार से अलग है, इसलिए यह कोई विकल्प नहीं है।
  
  
  • हम बच्चों को मैप कर सकते हैं और स्ट्रिंग्स को स्टाइल वाले टेक्स्ट तत्वों से बदल सकते हैं। हालांकि यह भंगुर है, जिस क्षण आप स्ट्रिंग को किसी भी चीज़ में लपेटते हैं, वह अलग हो जाती है (यहां तक ​​​​कि प्रतिक्रिया-इंटल भी इसे अलग कर देगी)। उह।
  
  
  • यह करने का यह सबसे सुंदर तरीका नहीं है, हमें इंतजार करना होगा, और मैं 100% प्रदर्शन प्रभावों को नहीं समझता हूं। लेकिन हम रिएक्ट 16.3 के नए संदर्भ एपीआई का उपयोग कर सकते हैं, और एक <MuiText>Text</MuiText> पर्दाफाश कर सकते हैं। मूल रूप से Button जैसे एमयूआई घटकों में प्रदाता होंगे जो वर्तमान संदर्भ की शैलियों (फ़ॉन्ट, टेक्स्ट रंग, आदि ...) के बारे में जानकारी प्रदान करेंगे और मुईटेक्स्ट केवल उस डेटा का उपभोग करेगा और इसे टेक्स्ट तत्व पर लागू करेगा।
  
  

आज v1 जारी किया गया तो रिएक्ट नेटिव की क्या योजनाएं हैं❓

रिएक्ट नेटिव मटीरियल सपोर्ट के लिए, रिएक्ट नेटिव पेपर नामक एक सुंदर पुस्तकालय है जिसे कॉलस्टैक टीम द्वारा बनाए रखा और समर्थित किया जाएगा।

लेकिन क्या इसे रिएक्ट नेटिव में पोर्ट करने की कोई योजना है क्योंकि मुझे लगता है कि पेपर पूरी तरह से ठीक काम करता है❓

यदि नहीं, तो आप शायद इस मुद्दे को बंद कर सकते हैं :)

@ Deadcoder0904 साझा करने के लिए धन्यवाद। मैंने पेपर को विस्मयकारी प्रतिक्रिया घटकों में जोड़ा है। कॉलस्टैक के बारे में नहीं सुना है। सबसे पहले मैंने इसे कॉल-एम-ऑल के रूप में पढ़ा। लगता है कि वे वही झांकियां नहीं हैं, हां?

@jhabdas नहीं, वे एक जैसे नहीं हैं

@dantman देशी समर्थन प्राप्त करने के सर्वोत्तम तरीके पर मेरे विचार यहां दिए गए हैं

• अगर जेएसएस से चिपके रहना पूर्ण आवश्यकता नहीं है, तो मुझे लगता है कि फेला एक व्यवहार्य विकल्प है:
  
  
  
  • fela-native मीडिया प्रश्नों का समर्थन करता है और StyleSheet.create का ठीक से उपयोग करता
  
  
  • यह पागलपन से एक्स्टेंसिबल है । हम वेब गुणों के लिए उनके प्रतिक्रिया-मूल प्रॉक्सी के लिए नियमों को फिर से लिख सकते हैं, मूल पर :hover नियमों जैसी चीजों को पट्टी कर सकते हैं, और संभवत: जेएसएस से जो भी वाक्यविन्यास खो गया है उसे पुनः प्राप्त कर सकते हैं।
  
  
• प्रतिक्रिया-मूल-एनिमेबल में कीफ़्रेम समर्थन है, और संभवतः संक्रमण-समूह के बजाय भी इसका उपयोग किया जा सकता है, जो मूल के साथ काम कर सकता है या नहीं भी कर सकता है ।
• मैं प्रतिक्रिया-मूल के नो-कैस्केडिंग दृश्य को नष्ट करने से सहमत हूं। यह cascade और inherit प्रोप के साथ प्रदाता और उपभोक्ता में ऑप्ट-इन हो सकता है।
  प्रत्येक प्रतिक्रिया-मूल पुस्तकालय जिसके साथ मैंने काम करने का प्रयास किया है, अत्यधिक कठोर एपिस और गैर-अतिरंजित शैलियों के कारण दर्दनाक या अनुपयोगी रहा है, उन लोगों के अपवाद के साथ जो ओवरराइड की अनुमति देने के लिए @shoutem/theme का उपयोग करते हैं (जैसे देशी-आधार) .

अभी भी इस समर्थन का इंतजार है। वेब पर खूबसूरती से उपयोग करना लेकिन मैं मोबाइल पर भी विकसित होता हूं!

समर्थन के बारे में कोई अद्यतन देशी प्रतिक्रिया?

@oliviertassinari मैं ऊपर उल्लिखित कार्यान्वयन पथ की खोज करना और शुरू करना चाहता हूं। मेरी प्राथमिकता उन घटकों को प्राप्त करने जा रही है जिनकी मुझे किसी अन्य परियोजना के लिए काम करने की आवश्यकता है, इसलिए मैं शायद जल्द ही किसी भी समय मजबूत प्रतिक्रिया मूल समर्थन नहीं पाऊंगा, लेकिन मैं इसे मास्टर के साथ "सिंक में" रखने की कोशिश करूंगा जितना मैं कर सकता हूं उम्मीद है कि यह एक दिन उपयोगी होगा (या संभवतः विलय)

@micimize मुझे बताने के लिए धन्यवाद। मैं आपको इस परियोजना में शुभकामनाएं देता हूं! :) इस बारे में कि हम अभी तक प्रतिक्रिया-मूल पर काम क्यों नहीं कर रहे हैं। मुझे लगता है कि यह विभिन्न स्वादों में आता है। सबसे महत्वपूर्ण बात यह है कि हमारे पास ऐसा करने में रुचि रखने वाला कोई कोर रखरखाव नहीं है। मैं इसे समझ सकता हूं, प्रतिक्रिया-मूल का उपयोग प्रतिक्रिया-मूल की तुलना में तेजी से बढ़ता है और यह कठिन है।

इस पर अपडेट करें: हमने सूची, बटन, कार्ड, आइकन, चयन नियंत्रण, टेक्स्ट फ़ील्ड और पृष्ठभूमि सहित कुछ हद तक उपयोग करने योग्य स्थिति में कार्यक्षमता का एक बड़ा हिस्सा माइग्रेट किया। दुर्भाग्य से, एक बार जब हम अंततः प्रतिक्रिया-मूल पर अपना ऐप विकसित कर रहे थे, तो कई मुद्दे सामने आए और हमें फ़्लटर में जाने के लिए मजबूर कर दिया।

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

@rogerstorm ने इस मुद्दे को $200 के साथ वित्त पोषित किया। इसे इश्यूहंट पर देखें

समस्या पर काम करना हमारे लिए एक अवसर लागत होगी। मैं बंद कर रहा हूँ। हम ब्राउज़र के उपयोग के मामलों को बेहतर ढंग से समर्थन देने पर दोगुना काम करेंगे।

@oliviertassinari , क्या इसका मतलब यह है कि प्रतिक्रिया देशी समर्थन दायरे से बाहर है और निकट भविष्य में (जैसे 1 वर्ष) यह रडार पर नहीं होगा?

हां

https://github.com/lightningtgc/react-native-material-ui एक और घोटाला npm पैकेज के अलावा और कुछ नहीं है