Material-ui: Dukung React Asli

Baru saja menemukan repo ini: https://github.com/lightningtgc/react-native-material-ui
Tidak tahu apakah itu ada gunanya.

Terima kasih @chadobado - Kami sudah membicarakannya dengan pasti dan ini akan menjadi proyek yang menyenangkan untuk dimulai. Namun, kami memiliki tangan penuh dengan proyek ini saat ini. Saya akan membiarkan masalah ini terbuka dan memperbarui jika kita pernah membuat perpustakaan asli.

Ini sebenarnya ide yang bagus. Saya telah mencoba menguji porting material-ui ke React-Native. Kita hanya perlu sedikit stylesheet, ubah semua div menjadi View , ubah semua h1 , h2 , dll menjadi Text dan itu akan bekerja dengan baik. Satu-satunya masalah yang saya temukan adalah bahwa React Native tidak sepenuhnya mendukung boxShadow sehingga sulit untuk mengimplementasikan komponen Paper saat ini. Juga, akan sangat bagus jika kita dapat membuat skrip yang bagus untuk mem-porting kode secara otomatis ke React-Native karena tidak terlalu berbeda.

ubah semua div ke View, ubah semua h1, h2, dll ke Teks dan itu akan berfungsi dengan baik

Tidak bisakah kita menggunakan transformator babel-plugin untuk melakukannya?

Ini sebenarnya ide yang bagus

Apakah Anda memiliki proyek demo?

@olivietassinari

Tidak bisakah kita menggunakan transformator babel-plugin untuk melakukannya?

Saya tidak yakin karena stylesheet React Native sangat berbeda dengan CSS sehingga akan cukup rumit untuk membuat transformer.

Apakah Anda memiliki proyek demo?

Belum karena' Saya cukup sibuk tapi saya akan mencoba menunjukkan demo kecil segera.
Tapi inilah yang perlu kita lakukan

lembar gaya

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

ke

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

zSolusi indeks

BEJ

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

ke

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

Kita juga perlu memodifikasi styles/transition.jsx (React Native menggunakan object bukan string ), mixins/style-propable.jsx karena kita tidak perlu berurusan dengan banyak browser, dll

Saya baru saja menerbitkan forking WIP untuk bereaksi-asli di https://github.com/lenaten/material-ui-native.
Saat ini hanya Card dan RaiseButton yang berfungsi, tetapi tanpa gaya (ingat WIP?)

@lenaten Menarik!
Saya juga ingin mulai mengerjakan pembungkus antara proyek ini dan mrn (https://github.com/oliviertasinari/react-material).
Tampaknya garpu Anda hanya berfungsi dengan reaksi asli, bagaimana Anda membuatnya bekerja dengan browser juga?
Saya pikir itu adalah poin yang paling sulit dan harus ditangani sekarang, karena Anda mengatakan bahwa Anda memiliki dua komponen yang berfungsi. Saya dapat membantu jika Anda mau.
Seperti yang dikatakan sebelumnya, saya juga ingin menyelidiki https://github.com/binggg/mrn untuk implementasi asli kami.

Ketika dijawab, saya pikir kita bisa menggabungkan garpu Anda kembali ke sini.

Material-UI adalah proyek yang matang terhadap proyek mrn yang kehilangan banyak komponen material. Jika POC saya akan berfungsi seperti yang dikecualikan, menggabungkannya ke struktur file lintas platform seharusnya mudah. Saya tidak punya waktu untuk menemukan kembali roda dan memulai dari proyek awal.

Bagaimanapun, bantuan Anda dalam pemikiran dan kode sangat diterima.

@olivietassinari Saya juga.

Ide saya untuk membuat material-ui bekerja dengan browser dan asli adalah dengan menggunakan struktur nama file, mirip dengan cara react-active menangani iOS dan Android secara bersamaan.

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

atau kita masih dapat menggunakan komponen yang sama untuk browser dan native dan kemudian menulis pembungkus untuk menanganinya. Misalnya, react-native menggunakan View , browser menggunakan div lalu lakukan seperti ini:

div.browser.jsx

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

div.native.jsx

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

app-bar.jsx

import {div} from "div"

Kami sebenarnya dapat membuat proyek terpisah untuk pembungkus ini.

@quanglam2807 Saya senang mendengarnya.

Mengenai organisasi kode, saya menyukai gagasan memiliki ekstensi file terpisah.
Saya akan mengambil https://github.com/benoitvallon/react-native-nw-react-calculator/tree/master/src/common/components contoh sebagai cara untuk melakukannya.

Mengenai organisasi proyek, saya mungkin telah berubah pikiran.
Saya pikir lebih baik mengikuti pendekatan Google dan bekerja pada satu repositori besar. Karenanya mengerjakan sinkronisasi garpu dengan material-ui atau di sini bisa menjadi cara yang baik untuk melakukannya.

Untuk memulai dengan file .native kami, kami dapat bergantung pada

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

komponen.

@olivietassinari Saya juga menyukai ide model "ekstensi file". Yang paling penting bagi saya sekarang, adalah bekerja dengan komponen asli. Jika Anda ingin membantu dengan abstraksi kode, Anda dipersilakan. Saya berkomitmen untuk menghapus akhiran "asli" dari nama repo :)

@lenaten apakah material-ui-native kompatibel dengan tcomb-form-native, atau jika tidak, seberapa besar proyek itu?

@mvayngrib Saya berhenti untuk mengerjakan proyek ini untuk sementara waktu..

@lenaten itu memalukan, terima kasih telah menanggapi

Baiklah, saya sudah mulai bekerja di https://github.com/callemall/material-ui/pull/2611 ini
Itu akan memakan waktu!

@olivietassinari luar biasa! sangat sangat bersemangat

jadi apakah usaha pelabuhan masih buka? Jika ya, bagaimana proses penyelesaian komponen implementasi?

@dorthwein Masih buka.

Dari sudut pandang saya, prosesnya adalah sebagai berikut:

• [ ] Tingkatkan ke versi terbaru react-native dan hapus react-native-webpack-server . Saya sudah melakukannya di proyek ini. https://github.com/callemall/material-ui/pull/3829
• [ ] Mainkan dengan react-look dan lihat seberapa baik kita dapat menggunakannya untuk muiTheme yang berasal dari konteksnya. https://github.com/callemall/material-ui/pull/3829
• [x] Tunggu reorganisasi folder jadi kita punya tempat untuk meletakkan komponen baru
• [ ] Mulai kerjakan aplikasi dokumentasi yang akan kita gunakan untuk menampilkan komponen baru.
• [ ] Mulai mengerjakan komponen versi asli.

@oliviertassinari - Saya dapat menyumbangkan sedikit waktu untuk memindahkan beberapa komponen setelah langkah maju ditetapkan. Melihat daftar Anda, satu-satunya yang tidak diketahui saat ini adalah hal-hal yang terlihat seperti reaksi, bukan?

@dorthwein kami senang mendengarnya.
Saya menggunakan reaksi-lihat di sini #3829. Satu-satunya masalah yang saya miliki adalah masalah kecil. React Native menampilkan beberapa peringatan tentang penggunaan yang salah dari StyleSheet API. Saya belum melihatnya secara detail tetapi saya yakin itu bisa diselesaikan.

@olivietassinari @dorthwein Saya senang bahwa upaya ini (yaitu, membawa material-ui ke react-native ) tidak mati. Saya hanya ingin menunjukkan bahwa ada juga proyek material-ui untuk react-native yang belum disebutkan di utas ini: https://github.com/react-native-material- desain/react-native-material-design . Proyek itu tampaknya didasarkan pada https://github.com/binggg/mrn.

@olivietassinari Saya melihat di utas lain jika mendukung iOS masuk akal untuk port ini - saya pikir itu benar-benar terjadi terutama ketika Anda melihat bagaimana Google Maps & aplikasi Google Material + iOS lainnya ada di luar sana. Jika masuk akal dan ada komponen iOS yang sudah ada sebelumnya (misalnya sakelar) yang harus digunakan untuk sakelar iOS di iOS. Menerapkan Android & iOS juga tidak terlalu membebani.

@oliviertassinari Struktur file component.native.js, component.android.js, component.ios.js juga tampaknya paling masuk akal bagi saya.

@olivietassinari Saya mencoba menjalankan dokumen dan tidak berhasil. Beberapa masalah:

• package.json: react-native tidak menyukai nama paket material-ui - mengubah ke materialUI menyelesaikan masalah
• Cabang material-ui/react-native saat ini mengalami masalah dengan pembuat paket react-native dan tidak membuat file mainjs.bundle. Saya belum bisa memahami apa yang terjadi di sini.
• Sepertinya saya tidak bisa mendapatkan aplikasi reaksi asli yang berfungsi di atas repo material-ui yang ada. Jika ada yang beruntung di bagian depan ini, mari kita stabil di sini cara berkontribusi/mengembangkan set komponen asli.

@dorthwein Terima kasih atas umpan baliknya. Cabang reaksi-asli sangat eksperimental. Kita perlu menyelesaikan ini.
Di sisi lain, saya tidak memiliki masalah apa pun di pihak saya (https://github.com/callemall/material-ui/pull/3829).
Saya harus mencoba memulai dari git clone .

Ya, jadi tahap selanjutnya dari proyek saya saat ini adalah mengerjakan aplikasi seluler menggunakan desain material - Saya ingin menggunakan ini karena semua barang web kami juga ada di sini. Jika kita bisa mendapatkan lingkungan kerja, saya akan mulai merobohkannya bersama dengan proyek kami.

Sedang membaca beberapa hal dan memperhatikan berita gembira ini dari Halaman Asli FB React.

"Komponen paling mendasar untuk membangun UI, View adalah wadah yang mendukung tata letak dengan flexbox, gaya, beberapa penanganan sentuh, dan kontrol aksesibilitas, dan dirancang untuk bersarang di dalam tampilan lain dan memiliki 0 hingga banyak turunan dari jenis apa pun. View memetakan langsung ke tampilan asli yang setara pada platform apa pun yang dijalankan React, baik itu UIView,

Juga menemukan sumber ini - mencobanya sekarang. Tampaknya cukup lurus ke depan dan mungkin layak untuk dilihat

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

@dorthwein Ide bagus! Tetapi jika kita mengikuti jalan ini, saya pikir mengembangkan versi untuk React Native saja akan lebih baik.

Kita dapat menulis ulang seluruh proyek di bawah React Native API daripada kode terpisah untuk Native dan DOM. Luar biasa! Saya tidak pernah memikirkan hal ini.

@quanglam2807 ya - begitulah fitur baru dll... Tetap sejalan satu sama lain. Tantangan terbesar menurut saya adalah membuat gaya dan animasi berfungsi. Plus besar lainnya adalah kami dapat secara bertahap menambahkan dukungan untuk komponen yang berbeda.

Sisi bawahnya adalah semuanya perlu menggunakan kotak fleksibel.

Mengingat bahwa ini adalah refactoring utama dari basis kode - siapa yang perlu menandatangani ini untuk maju? Saya masih perlu bermain-main dan melihat seberapa kuat hal-hal reaksi-asli-web juga.

@quanglam2807 @oliviertasinari keuntungan lain dengan pendekatan ini adalah material-ui akan dengan mudah https://github.com/ptmt/react-native-desktop juga.

@oliviertassinari menggunakan react-native-web sesuatu yang dapat diperoleh oleh pengelola proyek ini jika berhasil seperti yang diharapkan?

@dorthwein Saya suka ide di balik proyek ini. Tapi saya tidak berpikir itu akan membantu dalam waktu dekat.
Bukankah kita harus menulis versi asli dari komponen kita terlebih dahulu sebelum kita dapat menggunakan react-native-web ?

@olivietassinari tidak, apa yang dilakukan react-native-web adalah menggunakan komponen paling "asli" tergantung pada platformnya. Jadi misalnya diberi tag View, itu akan menggunakan div di browser, UIView di iOS dan apa pun yang setara dengan UIView adalah Android.

Prosesnya kemudian akan menjadi alih-alih menulis versi asli dari setiap komponen, bahwa kita hanya perlu mengonversi yang sudah ada untuk menggunakan View alih-alih div dan gaya Teks alih-alih menggunakan hal-hal seperti h1 dan label.

Jelas bukan usaha kecil tetapi prosesnya kemudian akan memperbarui komponen yang ada alih-alih mencoba membuat & memelihara beberapa versi.

Prosesnya kemudian akan menjadi alih-alih menulis versi asli dari setiap komponen, bahwa kita hanya perlu mengonversi yang sudah ada untuk menggunakan View alih-alih div dan gaya Teks alih-alih menggunakan hal-hal seperti h1 dan label.

Kedengarannya persis seperti menulis versi asli yang mudah-mudahan berfungsi di browser juga. Sejauh yang saya tahu react-native-web membawa reaksi asli ke web dan bukan sebaliknya.
Namun, itu bisa sangat berguna untuk berbagi kode yang sama :+1:.
Saya telah melihat satu masalah kecil dengan lib ini sejauh ini. Implementasi StyleSheet.create tidak mendukung nilai dinamis (diperlukan untuk muiTheme). Kita bisa menggunakan react look untuk use case ini.

@olivietassinari Anda benar - saya memahaminya secara terbalik. Langkah 1 tampaknya masih membangun versi komponen asli-reaksi. Langkah 2 berpotensi menggabungkannya menjadi satu basis kode menggunakan sesuatu seperti react-native web.

@wordyallen : terlihat bagus 👍

@pgangwani Saya baru saja mulai mengotak-

Saya telah menggunakan https://github.com/react-native-material-design/react-native-material-design untuk mengisi celah tetapi juga sangat kasar di sekitar tepinya dan tidak ada pengembangan aktif

Saya akan menyumbang secara finansial untuk usaha ini, jika saya bisa.

Hai kawan,

Saya mengerjakan react-native-material-ui , yang terinspirasi oleh perpustakaan ini. Jangan ragu untuk mencoba - saya ingin mendengar umpan balik;)

@xotahal dkk. al, Alih-alih membuat dari awal apa yang harus kita lakukan IMHO adalah forking perpustakaan ini dan porting komponen yang ada daripada membuatnya kembali. Kebutuhan input gaya material sangat dibutuhkan di ruang RN, jika Anda bertanya kepada saya. Terima kasih kepada semua atas upaya OSS Anda.

Saya tidak berpikir ada banyak kode umum, saya pikir membuat dari awal masuk akal. Styling di RN akan 90% berbeda dari yang ini. Dan ada beberapa mekanik khusus platform seperti animasi...

Tampaknya mengadopsi struktur komponen, alat peraga (dan dokumen) dan memiliki hulu yang jelas, bahkan jika banyak perubahan, akan bermanfaat dalam jangka panjang bagi mereka yang beralih dari web ke asli dan yang paling penting. Selebihnya menjadi detail implementasi.

Saya setuju dengan @jhabdas ; semakin mirip API untuk mencari setiap komponen, semakin sedikit hal yang mengganggu bagi pengembang untuk beralih dari proyek web dan proyek asli. Semakin sedikit pengalaman yang menggelegar, semakin produktif mereka. Saya berharap detail khusus platform diabstraksikan di belakang layar komponen.

@chadobado atau pengelola, maukah Anda mengganti nama masalah ini menjadi "Support React Native" untuk meningkatkan visibilitas saat mencari repo ini? Saat ini pencarian "React Native" mengubur ini dalam daftar karena istilah tersebut ditulis dengan tanda penghubung dalam judul.

FWIW, ini menarik perhatian saya.

@necolas di Web dukungan untuk react-native-material-kit :

Anda tidak perlu banyak port jika ada Stylesheet sebagai kompatibilitas yang disediakan oleh implementasi web dari React Native

@jhabdas jika Anda bermain sedikit dengan reaksi asli, Anda akan melihat bahwa itu tidak

Poin wajar @antoinerousseau. Saya terus memikirkan kembali kutipan dari James Long di RN:

Anggap saja sebagai prototipe untuk arah yang berbeda untuk web

Jika saya memahami tujuan perpustakaan @necolas berfungsi, tampaknya pendekatan yang waras adalah membalikkan masalahnya: daripada mem-porting CSS ke RN, cukup buat kembali semuanya di RN dan kembalikan port untuk web menggunakan shim. React Native Material Kit sudah memiliki lompatan yang baik pada masalah ini.

Karena react-native-web tampak luar biasa, saya hanya akan membuat file material-ui.android.js , material-ios.ios.js , dan material-ui.web.js dalam proyek pribadi saya dan menyebutnya bagus. Jika saya mengikuti material-ui API dengan membungkus yang lainnya, pada akhirnya akan berhasil. Jika material-ui mengejutkan saya dan berhasil, saya hanya perlu menghapus .web dari .web.js dan menghapus file lainnya. Dengan cara ini saya dapat secara selektif bertransisi ke material-ui per komponen.

@oliviertasinari Jadi saya menambahkan cabang react-native sebagai ketergantungan NPM dan menginstal semua plugin Babel. Saya mendapat pesan ini saat mengimpor komponen apa pun:

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

Tujuan saya adalah menggunakan material-ui secepat mungkin per komponen. Memang, saya melakukan git rebase master dan seharusnya melakukan git rebase next jika ada. Apakah semua komponen individu react-native terhalang oleh persiapan kerja cabang next sekarang?

Dan saya menulis beberapa kode yang memungkinkan saya untuk menggunakan react-native-vector-icons dengan cara yang persis sama dengan saya menggunakan ikon 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>)
  }
})

Meskipun saat ini react-native-vector-icons dan material-ui memiliki sintaks impor yang tidak kompatibel. @oblador Saya harus mengimpor glyphMap dan mengulanginya dan mengekspor seluruh daftar sebagai satu objek besar.

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

Akan lebih baik jika ikon material react-native-vector-icons dikelompokkan berdasarkan kategori seperti material-ui memungkinkan ekspor individu dari dalam kategori:

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

Haruskah kita mengerjakan permintaan tarik untuk membuat react-native-vector-icons kompatibel dengan konvensi impor material-ui ?

@mattferrin Cabang react-native sudah cukup tua sekarang. Ini tidak dimaksudkan untuk dikonsumsi oleh pengguna. Itu adalah Bukti Konsep tentang jalan ke depan.
Sejauh yang saya lihat pada masalah ini, salah satu pendekatan yang menjanjikan adalah menulis ulang untuk menargetkan react-native . Kemudian react-native-web akan melakukan bagian yang sulit untuk kita.
Namun, ada beberapa tantangan:

• Berapa banyak _react-native-web_ yang siap produksi? Misalnya saya belum melihat tes visual.
• Bagaimana Anda menangani kueri media?
• Bagaimana Anda menangani solusi bertema yang kompleks?

react-with-styles juga layak untuk dilihat.

Berapa banyak react-native-web yang siap produksi?

@oliviertasinari Saat ini saya sedang mem-porting situs web ke react-native-web , dan merasa bahwa itu layak untuk dirangkul. Itu tidak memiliki komponen href tag jangkar lintas platform dan mungkin kehilangan fitur lainnya, tetapi ReactDOM yang mendasarinya adalah siap produksi dan itulah yang kami butuhkan.

Bagaimana Anda menangani kueri media?

Haruskah material-ui peduli? Ada cara untuk menemukan dimensi komponen atau layar di semua platform. Selama komponen material-ui dapat diteruskan alat peraga yang mengontrol gaya, yang mereka lakukan, saya pikir kami adalah emas.

Apakah material-ui melakukan kueri media? Apakah kita perlu?

Bagaimana Anda menangani solusi bertema yang kompleks?

Tidak bisakah kita memeriksa Platform untuk menghilangkan atau mengganti nama props React Native yang tidak didukung, karena (jika ingatanku benar) padding dan margin pada dasarnya dibalik di React Native. Yang harus kita lakukan adalah membungkus metode yang setara dengan createStyleSheet untuk mengubah/memfilter hasilnya menjadi gaya kompatibel khusus platform non-"web".

Saya belum menggunakannya, tetapi Fela bertujuan untuk menjadi lintas platform, dan saya pikir itu penting. Sejak penulis Fela menulis React Look dan karena itu tampaknya telah menjadi pilihan sebelumnya, rasanya seperti pilihan yang wajar.

Saya juga belum pernah menggunakannya tetapi sesuatu seperti react-tunnel tampaknya bagus untuk konteks bertema. Kami hanya dapat menggunakan dan mengeksposnya, sekali lagi hanya karena rasanya lebih dapat dibagikan oleh komunitas. Mungkin ada padanan yang lebih populer.

Berapa banyak react-native-web yang siap produksi? Misalnya saya belum melihat tes visual.

Ada contoh interaktif di sini: https://necolas.github.io/react-native-web/storybook/

Bagaimana Anda menangani kueri media?

Dalam JavaScript, menggunakan matchMedia (atau menggunakan Dimension ) untuk menentukan gaya dan komponen mana yang akan dirender.

Tidak ada komponen href jangkar-tag lintas platform

Ya, saya tidak yakin seperti apa solusi yang "tepat", tetapi Anda dapat menggunakan tautan seperti View dan Text untuk saat ini (hanya dukungan web, tentu saja):

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

Bagaimana Anda menangani solusi bertema yang kompleks?

React Native tidak keberatan bagaimana Anda melakukan ini. Anda masih dapat menggunakan context untuk menentukan objek gaya mana yang akan diterapkan. Saya cukup menyukai API Fela di dalam komponen, tetapi implementasi dan plugin API terlihat berlebihan jika Anda menggunakan react-native-web .

Yang harus kita lakukan adalah membungkus metode yang setara dengan createStyleSheet untuk mengubah/memfilter hasilnya menjadi gaya yang kompatibel dengan platform non-"web".

Apakah masalah Anda mengekspos gaya API yang tidak kompatibel dengan RN? Jika demikian, saya sarankan Anda mengekspos gaya API yang kompatibel dengan RN dan membiarkan react-native-web mengonversinya menjadi gaya DOM.

@necolas

Apakah masalah Anda mengekspos gaya API yang tidak kompatibel dengan RN? Jika demikian, saya sarankan Anda mengekspos API gaya yang kompatibel dengan RN dan biarkan react-native-web mengonversinya menjadi gaya DOM.

Poin bagus. Apakah react-native-web memiliki arti :hover misalnya?

@necolas Dan pekerjaan tertentu yang saya lakukan hanya perlu mendukung browser yang selalu hijau, tetapi apakah ada kemungkinan porting ke react-native-web akan dikenakan biaya material-ui kompatibilitas browser dengan versi yang lebih lama? Aku tidak tahu apa-apa tentang itu. Saya hanya benar-benar berpikir react-native-web adalah pendekatan yang tepat.

Itu tidak memberikan sesuatu yang istimewa untuk gaya hover (begitu juga RN). Saya ingin tahu apakah implementasi desktop untuk Windows dan Ubuntu menggabungkan apa pun untuk antarmuka mouse atau menyerahkannya kepada Anda melalui acara.

Saya tidak yakin dukungan browser apa yang Anda butuhkan tetapi mungkin dapat mengakomodasi saat masalah muncul

Saya pikir mungkin perlu untuk menyuntikkan boolean ke dalam konteks hierarki komponen melalui MuiThemeProvider untuk memilih antara react-native-web versus API gaya komponen react-dom .

Jawaban terbaik adalah beralih ke API gaya react-native-web , dan itulah yang saya anjurkan, tetapi itu mungkin akan menyebabkan gangguan.

@olivietassinari Bisakah kita beralih dari material-ui ke react-native style API? Mungkin membiarkan gaya khusus mouse bocor?

@necolas @oliviertasinari Hanya sebagai FYI. Ini ceroboh sekarang, tetapi saya telah bekerja untuk mem-porting cabang (https://github.com/mattferrin/material-ui-build/tree/mine) menjadi lintas platform selama 2-3 hari terakhir karena saya sangat membutuhkannya sendiri (untuk mengurangi total pekerjaan saya dalam jangka panjang).

Saya telah mem-porting semuanya ke sintaks react-native-web dan mengomentari gaya yang tidak porting, tetapi saya pikir saya akhirnya akan mengomentarinya kembali dan menggunakan Platform.OS == 'web' untuk mempertahankan kode asli pada dasarnya tidak berubah setelah saya selesai mem-porting situs web yang sedang saya kerjakan. Pada saat itu hanya hal-hal yang saya butuhkan secara pribadi akan porting dan tidak sempurna.

Ini benar-benar berantakan (sampai saya menyentuhnya nanti) karena saya mendorong untuk melompat antara mesin Mac dan Windows dengan cepat.

Bagi yang sudah tidak sabar menunggu MUI datang ke RN ada alternatifnya, dan ada beberapa alternatif yang lumayan bagus. Saya mempertahankan daftar evergreen di sini: https://habd.as/awesome-react-components/#react -native

Saya tahu seluruh solusi penataan berubah, tetapi saya melewatkan bagian di mana perpustakaan sedang ditulis ulang dari awal. Itu salahku. Saya berasumsi, dari melihat beberapa kode, bahwa gaya akhir pada dasarnya akan tetap sama dan hanya teknologinya yang akan berubah. saya tidak benar. Saya tidak sepenuhnya mengabaikan roadmap, saya hanya membuat asumsi yang sangat salah. Kurasa aku harus menebus usahaku di sini.

@mattferrin Tidak cukup dari awal (walaupun dalam beberapa kasus itu benar, misalnya Table ) meskipun perubahan solusi gaya memerlukan banyak perubahan API, tetapi selain itu memberi kita kesempatan untuk merasionalisasi API di area lain untuk banyak komponen . Saya minta maaf jika upaya Anda sia-sia - saya harap itu tidak membuat Anda keluar dari Material-UI!

@mbrookes Belum. Saya membuat kesalahan dengan bercabang master bukannya next dan meremehkan perbedaan (dan total pekerjaan secara umum). Itu salah saya dan saya tahu ada risiko. Saya hanya akan mengembalikan elemen Text kosong sebagai placeholder sampai nanti di fasad material-ui React Native saya. Ketika saya telah sepenuhnya mem-porting situs web saya ke react-native-web Saya akan kembali dan mencoba untuk mengubah basis perubahan baru dari next .

Melepaskan orang ini hari ini: https://carbon-ui.com

Terinspirasi oleh material-ui, bekerja di web dan reaksi-asli :)

@tuckerconnelly kamu membuat hariku menyenangkan

@tuckerconnelly wow, banyak potensi dalam proyek ini... bagus sekali! Ini untuk berharap bahwa komunitas yang lebih besar akan mendukung upaya ini! 🍻.

@tuckerconnelly saya agak bingung. Saya menemukan bahwa sebenarnya cukup mudah untuk membuat material-ui kondisional lintas-platform (terlepas dari kesalahan saya dengan bercabang master bukannya next dan membuang-buang waktu saya). Saya ingin tahu apa manfaat yang Anda lihat dari proyek independen?

Saya mencobanya kembali pada bulan Februari, dan mengalami kesulitan dengannya, khususnya dengan komponen riak dan dengan kueri media lintas platform.

Terkadang lebih mudah untuk memulai dari awal.

bagi saya tidak masuk akal untuk memiliki komponen React yang tidak bekerja pada React Native ... dan karena pengembang material-ui tidak menganggap RN sebagai prioritas ... itu wajar/logis untuk memulai di jalur baru

@tuckerconnelly Saya tidak berpikir itu penting bagaimana komponen diimplementasikan. Saya hanya berharap kedua proyek mencoba mengimplementasikan API yang sama (dan menyetujui nama yang sama) untuk komponennya. Saya senang Anda mengerjakan ini dan berbagi.

Jadi untuk 2017/2018 setelah v1.0.0 akankah RN menjadi tujuan berikutnya untuk materi-ui?

Seperti yang terlihat dari:

• Partisipasi masyarakat untuk v1
• Jumlah orang yang menginginkan dukungan RN
• Fakta bahwa banyak proyek telah didasarkan atau terinspirasi oleh Material-ui untuk menawarkan komponen RN
• Pengalaman yang didapat dari semua ini dan fakta bahwa banyak waktu telah berlalu sejak edisi ini dibuka

Jika Anda akan memulai (mungkin setelah peluncuran v1) proyek untuk menawarkan komponen RN, banyak orang akan membantu Anda. Anda hanya perlu memulai dan menentukan jalur yang jelas dan itu akan baik untuk dilakukan. Anda memiliki komunitas yang hebat, mari kita gunakan untuk membuat produk terbaik.

@NitroBAY 1.0 menggunakan JSS alih-alih objek JS untuk penataan sehingga bergantung pada cssinjs/jss#368 untuk mendukung React Native. Tapi saya pikir lebih baik mengembangkan versi paralel untuk React Native seperti ini: https://github.com/xotahal/react-native-material-ui. Kemudian kita dapat menjalankan versi React Native di web menggunakan https://github.com/necolas/react-native-web

Jadi apakah ini tidak akan diperbaiki? Jika demikian dapatkah itu ditandai seperti itu?

@jhabdas Saya ingin melihat perpustakaan yang bagus membawa spesifikasi materi ke dalam React Native.
Dari tautan yang diposting di utas, sudah ada daftar kandidat yang bagus.

Jika kami membiarkan masalah itu terbuka, ini tentang menyatukan web dan asli. Menyediakan API yang konsisten antara kedua platform. Saya berharap saya punya waktu untuk mengerjakannya tetapi saya tidak melakukannya dan saya ragu itu akan berubah.
Tim @callemall/material-ui akan senang melihat seseorang memimpin dalam masalah itu.

Masih mendukung carbon-ui :) Saya hanya menambahkan komponen saat saya membutuhkannya (tidak secara proaktif mencoba mengisi seluruh spesifikasi), tetapi saya pikir ada kerangka kerja yang baik di sana bagi orang-orang untuk mendukungnya.

• Ini menghasilkan dokumen secara otomatis dari komentar komponen
• Memiliki situs dokumen (carbon-ui.com)
• Mendukung native dan web dengan komponen yang sama

Akan membantu siapa saja yang ingin menambahkan komponen :)

@tuckerconnelly Apa pendapat Anda tentang https://github.com/xotahal/react-native-material-ui? Itu tidak berfungsi di web karena bug dengan Elevation, tetapi jika kami menerapkan kode Anda https://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.js , saya pikir itu akan bekerja. @oliviertasinari membuat poin bagus bahwa kita perlu memutuskan proyek utama untuk bekerja sama.

@quangbuule tunggu Anda mengatakan bahwa kami harus mengembangkan aplikasi sebagai aplikasi RN dan kemudian menggunakan alat itu untuk mengubah RN ke versi WEB?
Saya tidak pernah mendengar hal itu tapi oke. Tapi kemudian itu berarti bahwa kita tidak akan menggunakan material-ui lagi tetapi lebih ke RN fork ?

@NitroBAY Kami pada dasarnya port material-ui ke garpu RN dan saya pikir ketika sudah siap, itu akan menjadi versi resmi untuk web dan asli. Saya pikir tidak apa-apa mengingat material-ui menggunakan pendekatan serupa dengan cabang berikutnya.

Maaf untuk semua pertanyaan noob tapi saya masuk ke ReactLand sejak sekitar 1 minggu.

Anda berpikir bahwa paket Anda akan menggantikan yang ini?
Pendekatan Anda tampaknya multi-platfom dan sangat bagus. Material-ui hanya menempel pada web karena mereka tidak punya waktu tetapi mereka punya waktu untuk berikutnya, mengapa?
Anda mengatakan next menggunakan pendekatan isomorfik pada next tetapi jika saya mengambil komponen apa pun yaitu kertas, itu hanya akan berfungsi untuk web karena ada komponen div .
Siapa we , apakah Anda bagian dari tim ini ?
Terlepas dari pertimbangan teknis, apakah menurut Anda menggunakan MD di iOS dapat mengganggu pengguna?

EDIT: di luar topik tetapi tidak ada yang menjawab saya, keuntungan apa yang diberikan jss-theme-reactor ketika membandingkannya dengan jss-react ?

@NitroBAY :

1. Saya bukan pengembang proyek ini atau proyek React Native mana pun. Tetapi saya telah melihat masalah ini selama berbulan-bulan, dan saat ini, saya berharap untuk mulai berkontribusi pada react-native-material-ui .
2. paper atau benda bayangan sekarang bekerja di web, iOS, Android. Jadi itu bukan masalah besar.
3. Cabang material-ui master menggunakan objek untuk mendefinisikan stylesheet tetapi untuk meningkatkan kinerja (peningkatan 30%), kontributor beralih ke JSS (CSS dalam JS) di cabang next . Saat ini, JSS tidak kompatibel dengan React Native.
4. Google menggunakan Desain Material di iOS dan menurut saya pengguna tidak terlalu keberatan. Tentu saja, Anda harus memodifikasi beberapa bagian agar sesuai dengan platform seperti mengubah warna bilah status, menggunakan ikon berbagi iOS, dll. Saya menggunakan material-ui untuk aplikasi Windows 10 & macOS saya dan saya tidak melihat banyak pengguna mengeluh tentang hal itu (http://moderntranslator.com/). Beberapa bahkan mengatakan MD lebih mudah digunakan.

Tetapi saya masih tidak mengerti bagaimana cabang next dapat bekerja di RN jika komponen menggunakan elemen HTML seperti span atau div . Saya mungkin melewatkan sesuatu tetapi untuk mengembangkan di RN Anda perlu menggunakan komponen RN, bukan?
Saya mengutip Anda:

itu akan menjadi versi resmi untuk web dan asli. Saya pikir tidak apa-apa mengingat material-ui menggunakan pendekatan serupa dengan cabang berikutnya.

Tapi mungkin saya tidak mendapatkannya dengan benar. Maksud Anda next branch akan membuat kita bisa menggunakan komponen di RN ?

@NitroBAY : next cabang akan membuat material-ui kurang kompatibel dengan React Native. Juga, meskipun komponen RN tidak mendukung span atau div, dengan menggunakan aturan bersyarat, Anda dapat melakukan sesuatu seperti ini:

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

Anda dapat memeriksa: https://github.com/necolas/react-native-web

Oh oke, saya pikir maksud Anda mereka membuat RN kompatibel.

Apakah TL;DR bahwa proyek ini tidak tertarik pada dukungan multi-platform melalui React Native API, dan upaya itu harus dipindahkan ke https://github.com/xotahal/react-native-material-ui?

Dokumen untuk carbon-ui lebih baik, dan sudah berfungsi di web. Apa manfaat dari react-native-material-ui?

Jadi semua orang setuju bahwa material-ui akan dihentikan untuk digunakan dan direkomendasikan dalam beberapa waktu ? Lalu sayang sekali kalau pemilik paket ini tidak mau RN ?

carbon-ui sepertinya akan memiliki masalah kinerja karena tidak menggunakan StyleSheet dan dari menyuntikkan begitu banyak font web

Tenang, teman-teman! Ini masih datang.

TL;DR: Jika Anda membuat komponen untuk React Native, itu akan berfungsi di RN dan web. Tetapi jika Anda membuat komponen untuk web, itu tidak akan berfungsi di RN. Dan material-ui dibuat untuk web, dioptimalkan untuk web => Untuk membuatnya berfungsi di RN, kinerja harus dikorbankan (setidaknya, saat ini). Jadi, saya pikir lebih baik memisahkan kedua proyek sampai RN lebih matang.

dioptimalkan untuk web => Untuk membuatnya berfungsi di RN, kinerjanya harus dikorbankan (setidaknya, saat ini)

Apakah Anda memiliki data untuk dibagikan tentang itu?

Berikut adalah temuan saya untuk RNW sejauh ini:

• 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

Hmm, saya bisa melihat penggunaan StyleSheet dengan Uranium. Saya akan mengatakan, belum melihat masalah kinerja terkait CSS, tetapi akan melihat apakah saya dapat mengintegrasikan lebih baik dengan barang-barang StyleSheet Anda.

Hit kinerja terbesar berasal dari Animated: https://github.com/animatedjs/animated/issues/48 Tapi itu mempengaruhi semua aplikasi RNW.

Apakah menyuntikkan font web secara signifikan menurunkan kinerja? Ini memuatnya langsung dari font google, jadi kemungkinan besar sudah di-cache di sistem pengguna.

Hal terpenting menurut saya adalah semua orang berkumpul di belakang satu perpustakaan. Dan saya tidak berpikir material-ui akan mendukung React Native.

@necolas TL;DR adalah bahwa jalan ke depan tidak jelas .

A = reaksi-asli
B = jaring

1. Platform yang paling dibatasi

Pendekatan yang mungkin adalah menargetkan platform yang paling dibatasi, maka mulai dari react-native . Kemudian untuk memperluas fitur ke web. Untuk memperluas fitur ke web, kita dapat menggunakan:

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

Namun, itu datang dengan pengorbanan, kami akan memenangkan berbagi kode. Tapi saya berharap kalah dalam beberapa dimensi.

Membawa API asli ke web

API harus diimplementasikan kembali untuk bekerja dengan browser. Apa itu overhead?

Menangani API web yang hilang dalam bahasa asli

Saat kita mulai dari platform yang paling terbatas, kita perlu mengimplementasikan kembali beberapa fitur web yang tersedia. Bagaimana dengan pertanyaan media? Warisan CSS, animasi CSS?
Siapa yang akan kami implementasikan aksesibilitas dan acara keyboard tanpa menggembungkan versi asli?

2. Platform yang kurang dibatasi

Solusi lain adalah memulai dari platform yang tidak terlalu dibatasi, maka web. Kemudian membuat implementasi ulang fitur asli yang hilang.

Namun, itu datang dengan pengorbanan, kami akan memenangkan berbagi kode. Tapi saya berharap kalah dalam beberapa dimensi.

Membawa web API ke native

Kita harus berkorban, saya berharap beberapa fitur web akan sangat sulit untuk diterapkan di native, misalnya, kueri media CSS, animasi CSS. (aturan CSS lanjutan)

Menangani API asli yang hilang di web

Beberapa fitur API web yang hilang adalah seputar penanganan sentuh, gulir & tampilan daftar tak terbatas, komponen asli seperti DatePicker atau Laci.

3. Pembagian kontrak

Solusi ketiga adalah menyiapkan infrastruktur untuk berbagi API & pengujian, lalu mengimplementasikan kembali komponen di dua platform yang mendasarinya. Dari persepsi saya, begitulah cara react-native mendekati iOS dan Android.
Kemudian menggunakan pendekatan campuran dari dua yang sebelumnya untuk mengisi penuh kontrak. Maksud saya, menggunakan percabangan kode saat itu masuk akal dan berbagi kode sebanyak yang kami bisa.
Misalnya:

• Mengapa menggunakan animasi.js di browser ketika kita dapat menggunakan transisi CSS?
• Mengapa menerapkan logika Drawer pada react-native ketika kita dapat menggunakan komponen native?

Saya pikir opsi 3. adalah yang paling menjanjikan. Begitulah cara saya mencoba menyelesaikan masalah di

https://github.com/tuckerconnelly/uranium mendukung kueri media lintas platform :)

Keindahan RN adalah Anda memiliki perpustakaan sederhana API abstrak dan primitif, dan implementasi tingkat rendah ditangani. Animated sama--library sederhana untuk animasi, implementasi tingkat rendah (animasi asli di iOS/Android, transisi css di web) ditangani.

Saya pikir animasi.js dapat diubah untuk menggunakan transisi css. Pasti akan meningkatkan kinerja.

@quanglam2807 utas itu sangat panjang, apa yang harus saya lihat?

Untuk memperluas fitur ke web, kita dapat menggunakan: https://github.com/necolas/react-native-web , https://github.com/taobaofed/react-web

react-web cukup jauh dari kinerja atau fungsi IMO yang benar.

API harus diimplementasikan kembali untuk bekerja dengan browser. Apa itu overhead?

Overhead dalam dimensi apa? Sulit ditentukan dalam hal ukuran bundel. Anda mungkin dapat menghapus beberapa kode yang ada; tetapi jika Anda bergantung pada apa pun di luar ekspor inti RNW, itu akan bertambah dengan cepat. Dalam komponen gaya-berat untuk mobile.twitter.com, saya telah melihat pengurangan 20-40% dalam ukuran komponen yang mengubah gaya dari css-modul ke RNW StyleSheet. Dalam hal kinerja runtime, saat ini tidak jauh dari css-modules .

Bagaimana dengan pertanyaan media?

Anda dapat menggunakan matchMedia untuk mengubah gaya dan struktur komponen, meskipun manfaat menggunakan kueri media untuk mengubah komponen tidak jelas bagi saya.

Warisan CSS, animasi CSS?

RNW mendukung animasi CSS (walaupun saya perlu menambahkan API untuk mendefinisikan keyframe). Apa pertanyaan yang terkait dengan pewarisan CSS?

Bagaimana kami menerapkan aksesibilitas dan acara keyboard tanpa membuat versi asli membengkak?

Tidak yakin apa maksudnya. Saya menduga ambang batas untuk "mengembang" di aplikasi asli jauh lebih tinggi daripada untuk aplikasi web.

jadi mungkin membandingkan bagaimana react-native-web menangani gaya untuk membuat kinerja css ke kinerja modul css kurang relevan sekarang

Mengapa demikian?

Akan sangat bagus untuk memiliki semacam reaksi-asli-web yang menggunakan sesuatu seperti aphrodite atau jss

Kedua perpustakaan tersebut lebih lambat, lebih besar, dan tidak cocok untuk menyediakan gaya deterministik

@necolas material-ui memberikan upaya besar untuk beralih dari metode css-in-js ke metode stylesheet (css dalam <style> ). Mereka telah melakukan upaya aktif selama berbulan-bulan untuk mengganti komponen. Alasan di sini . Dari apa yang saya baca menggunakan jss adalah keuntungan besar dan tampaknya menjadi solusi paling sempurna untuk menangani gaya sejauh ini.

Omong-omong dengan membaca Roadmap.md lagi dukungan RN ada di Roadmap.

Saya sangat tertarik menggunakan Material-UI dengan reaksi-asli, ada kabar yang sedang berlangsung?

@wswoodruff Anda dapat memeriksa yang ini untuk saat ini - https://github.com/xotahal/react-native-material-ui

Saat ini, kami memiliki tiga perpustakaan yang luar biasa untuk itu:

• react-native-material-kit 3110 - Membawa Desain Material ke React Native .

• react-native-material-design 2447 - Komponen Desain Material Asli React

• react-native-material-ui 1040 - Komponen desain material yang sangat dapat disesuaikan untuk React Native.

Menikmati!

Ada juga Carbon UI yang kurang dikenal jika Anda menggunakan universal. Tetapi untuk waktu saya, saya mungkin akan tetap berpegang pada salah satu dari ini .

telah disentuh beberapa kali di utas ini, tetapi saya ingin menyebutnya lagi karena bagaimana hal itu memengaruhi minat saya pada perubahan ini: manfaat utama dari dukungan asli-reaksi yang saya lihat sebenarnya bukan tentang reaksi-asli , melainkan tentang dibangun di atas primitif yang memungkinkan komponen yang sama digunakan di _both_ native dan web.

jika tipe primitif itu digunakan, alat lain seperti react-sketchup dan react-pdf juga dapat diaktifkan.

secara pribadi, itu lebih menarik bagi saya daripada yang asli, tetapi akan diaktifkan oleh perubahan yang sama.

@jhabdas Bagaimana pengalaman Anda menggunakan Carbon UI? Bcz bagi saya itu terlihat cukup bagus tetapi belum menggunakannya.

@deadcoder0904 belum menggunakannya secara pribadi. mungkin mencoba menjangkau salah satu dari orang-orang di merah tak terbatas. mereka menjalankan buletin RN dan harus menjadi pakar materi pelajaran. jika dan ketika saya membangun aplikasi RN lain (oke, kapan...) Saya tidak akan mengacaukan semuanya kali ini atau membangun boilerplate lain —IMHO ruang diselesaikan oleh boilerplate dan komponen yang ada .

Berikut adalah beberapa rintangan yang menurut saya perlu diatasi untuk membuat MUI tersedia di React Native. Dengan asumsi v1 MUI dan kami mempertahankan JSS, pola classes , dan hal-hal lain yang saat ini merupakan bagian penting dari desain api MUI.

• JSS perlu mendukung RN, yaitu membuat objek gaya sedemikian rupa sehingga withStyles hanya berfungsi. Lebih lanjut tentang ini di https://github.com/cssinjs/jss/issues/368#issuecomment -376708219.
• Dengan asumsi tidak ada hacky wrapper atau babel transform, kita perlu menambah pola classes agar bekerja dengan cara yang sama tetapi memperhitungkan fakta bahwa pada RN ia harus meneruskan array ke style , dan mungkin harus diberi nama styles . Mungkin ini bisa ditangani dengan menjatuhkan classnames dan menambahkan pembantu yang dapat disebarkan yang di belakang layar beralih antara penanganan kelas/kelasName dan gaya/gaya.
  Mungkin:
  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 akan menerima daftar nama gaya (dan mengabaikan nilai palsu). Di web itu akan terlihat di props.classes dan menghasilkan {classNames} . Pada asli itu akan terlihat di props.styles dan menghasilkan {style} .
  Awalnya saya memikirkan this.composeStyles dengan dekorator, tetapi alih-alih itu withStyles hanya bisa memasukkan pembantu komposisi gaya sebagai bagian dari alat peraga.
• Seperti yang disebutkan orang lain setelah semua ini untuk membuat komponen gaya dasar berfungsi, kita akan membutuhkan pekerjaan ekstra untuk membuat animasi, sentuhan, dll... berfungsi.
• Namun untuk animasi saya tidak menganggap ini hal yang buruk. Ini adalah kerugian kecil untuk transisi sederhana, di mana Anda hanya secara otomatis mentransisikan opacity , backgroundColor , dll. Kami mungkin menginginkan pembantu yang membuatnya tetap sederhana. Tetapi dari apa yang saya lihat, implementasi transisi material yang sebenarnya selain yang terlihat terlalu rumit/samar dan tidak akan ditingkatkan dengan baik. react-transition-group memiliki beberapa cita-cita yang bagus untuk menangani bagian tingkat rendah dari hal-hal (penanganan masuk/keluar, dll), tetapi bermasalah / di jalan pada orang lain. Juga alih-alih desain berbasis transisi css, saya pikir cara berpikir ke depan adalah dengan menggunakan Web Animations API baru dan memerlukan polyfill untuk itu.
  Dengan kata lain, saya pikir ada ruang untuk pembuatan perpustakaan baru untuk menangani animasi di React yang menggunakan Animasi Web di browser dan API Animated di React Native dan merupakan peningkatan umum tentang cara MUI menangani animasi.
• MUI perlu membuang harapan bahwa perilaku cascading tersedia. Dan pengaturan tema perlu ditingkatkan untuk mendukung penerapan modifikasi tema dalam subpohon dengan mudah.
  Saat ini hal-hal seperti AppBar + Icons bekerja dengan mengatur warna teks, menggunakan warna eksplisit='inherit' dan dengan asumsi warna akan turun. Dan tidak menutup kemungkinan di MUI bagian lain juga sama.
  Tidak ada cascading seperti ini di React Native. Sebagai gantinya, Anda harus mendeklarasikan gaya Anda secara eksplisit untuk setiap Tampilan. Untuk hal-hal seperti ini, AppBar dan komponen lain harus dapat dengan mudah menyediakan versi modifikasi dari tema yang disediakan dengan modifikasi seperti mengubah tema dalam konteks itu menjadi dark sehingga ikon mendapatkan ikon kontras yang benar warna (dan dapat didasarkan pada spesifikasi warna ikon yang sebenarnya, bukan warna teks). Perhatikan bahwa ini mungkin memiliki implikasi pada hal-hal seperti menu yang bersarang di bilah aplikasi.
• Sebagai perpanjangan dari masalah cascading ini. MUI juga dirancang di sekitar hal-hal seperti <Button>Text</Button> , di mana diasumsikan bahwa MUI hanya dapat menata fontFace/color, dll... dari root tombol, membiarkan Anda memasukkan apa pun ke dalam anak-anak, dan biarkan React DOM menyisipkan campuran elemen dan simpul teks dan simpul teks mendapatkan gaya yang tepat.
  Ini berantakan di React Native. Semua teks harus menjadi bagian dari <Text> , semua gaya teks harus menggunakan gaya komponen tersebut, dan elemen teks tidak boleh berisi turunan non-teks (mis.).
  Ada beberapa pilihan:
  
  
  
  • Pola <Button text='Text' /> bekerja lebih baik di React Native. Sayangnya itu berbeda secara fundamental dengan etos MUI, jadi itu bukan pilihan.
  
  
  • Kita bisa memetakan anak-anak dan mengganti string dengan elemen Teks bergaya. Namun ini rapuh, saat Anda membungkus string dengan apa pun yang berantakan (bahkan react-intl akan membuatnya berantakan). Ugh.
  
  
  • Ini bukan cara terbaik untuk melakukannya, kami harus menunggu, dan saya tidak 100% memahami implikasi kinerjanya. Tapi kita bisa menggunakan api konteks baru React 16.3, dan mengekspos <MuiText>Text</MuiText> . Pada dasarnya komponen MUI seperti Button akan memiliki penyedia yang akan memberikan informasi tentang gaya konteks saat ini (font, warna teks, dll...) dan MuiText hanya akan menggunakan data tersebut dan menerapkannya ke elemen Teks.
  
  

Hari ini v1 dirilis jadi apa rencana React Native

Untuk React Native Material Support, ada library cantik bernama React Native Paper yang akan dipelihara & didukung oleh tim CallStack.

Tetapi apakah ada rencana untuk mem-porting ini ke React Native karena menurut saya Paper berfungsi dengan baik

Jika tidak, maka Anda mungkin dapat menutup masalah ini :)

Terima kasih telah berbagi @deadcoder0904. Saya telah menambahkan Paper ke Awesome React Components . Belum pernah mendengar tentang CallStack. Awalnya saya membacanya sebagai Call-Em-All. Menebak mereka tidak mengintip yang sama, ya?

@jhabdas Tidak, mereka tidak sama

@dantman Inilah pemikiran saya tentang cara terbaik untuk mencapai dukungan asli

• jika berpegang teguh pada jss bukanlah persyaratan mutlak, saya pikir fela adalah alternatif yang layak:
  
  
  
  • fela-native mendukung kueri media dan menggunakan StyleSheet.create dengan benar
  
  
  • Ini sangat bisa diperluas . Kita dapat menulis ulang aturan untuk properti web ke proxy reaksi asli, menghapus hal-hal seperti aturan :hover pada asli, dan mungkin mendapatkan kembali sintaks apa pun yang hilang dari jss.
  
  
• react-native-animatable memiliki dukungan keyframe, dan mungkin dapat digunakan sebagai pengganti grup transisi juga, yang mungkin atau mungkin tidak berfungsi dengan native .
• Saya setuju dengan menumbangkan pandangan non-cascading dari reaksi-asli. Itu bisa menjadi pilihan di penyedia dan konsumen dengan cascade dan inherit props.
  Setiap perpustakaan reaksi-asli yang saya coba kerjakan telah menyakitkan atau tidak dapat digunakan karena apis yang terlalu kaku dan gaya yang tidak dapat ditimpa, dengan pengecualian yang menggunakan @shoutem/theme untuk mengizinkan penggantian (seperti basis asli) .

Masih menunggu dukungan ini. Menggunakan dengan indah di Web tetapi saya juga mengembangkan di seluler!

ada pembaruan tentang dukungan reaksi asli?

@olivietassinari Saya berniat untuk bercabang dan mulai menjelajahi jalur implementasi yang saya uraikan di atas. Prioritas saya adalah mendapatkan komponen yang saya butuhkan agar proyek lain berfungsi, jadi saya mungkin tidak akan memberikan dukungan React Native yang kuat dalam waktu dekat, tetapi saya akan mencoba untuk tetap "sinkron" dengan master sebanyak yang saya bisa dengan harapan suatu hari nanti akan berguna (atau mungkin digabungkan)

@micimize Terima kasih telah memberi tahu saya. Saya berharap Anda beruntung dalam proyek ini! :) Mengenai mengapa kami belum mengerjakan react-native. Saya pikir itu datang dalam rasa yang berbeda. Yang terpenting, kami tidak memiliki pengelola inti yang tertarik untuk melakukannya. Saya bisa memahaminya, penggunaan react-dom tumbuh lebih cepat daripada reaksi-asli dan sulit.

Pembaruan tentang ini: Kami memigrasikan sebagian besar fungsionalitas ke status yang dapat digunakan, termasuk daftar, tombol, kartu, ikon, kontrol pemilihan, bidang teks, dan tampilan latar. Sayangnya, setelah kami akhirnya mengembangkan aplikasi kami sendiri pada reaksi asli, banyak masalah muncul dan memaksa kami untuk pindah ke Flutter.

Pada titik tertentu saya ingin kembali dan menyelamatkan beberapa pekerjaan yang kami lakukan, terutama port solusi penataan withStyles / classes yang memanfaatkan properti css-shorthand- dan beberapa hal rapi lainnya, namun itu tidak lagi menjadi prioritas untuk saya.

@rogerstorm mendanai masalah ini dengan $200. Lihat di IssueHunt

Mengerjakan masalah akan menjadi biaya peluang bagi kami. saya tutup. Kami akan menggandakan dukungan yang lebih baik untuk kasus penggunaan browser.

@olivietassinari , apakah ini berarti bahwa reaksi dukungan asli berada di luar jangkauan dan dalam waktu dekat (misalnya 1 tahun) tidak akan ada di radar?

Ya

https://github.com/lightningtgc/react-native-material-ui Tidak lain adalah paket scam npm lainnya