Material-ui: ReactNativeをサポートする

このリポジトリを発見したばかりです： https ：
でも、それが良いかどうかはわかりません。

ありがとう@ chadobado-私たちは確かにそれについて話しました、そしてそれは始めるのが楽しいプロジェクトになるでしょう。 ただし、現時点では、このプロジェクトに完全に取り組んでいます。 ネイティブライブラリを作成する場合は、この問題を開いたまま更新します。

これは実際には素晴らしいアイデアです。 material-uiをReact-Nativeに移植することをテストしようとしました。 少しだけスタイルシートを作成し、すべてのdivをViewに変更し、すべてのh1 、 h2などをTextあります。それはうまくいくでしょう。 私が見つけた唯一の問題は、React NativeがboxShadow完全にサポートしていないため、現時点でPaperコンポーネントを実装するのが難しいことです。 また、コードをReact-Nativeに自動移植するためのスクリプトを作成できれば、それほど違いはありません。

すべてのdivをViewに変更し、すべてのh1、h2などをTextに変更すると、うまく機能します

それを行うためにbabel-plugin-transformerを使用できませんでしたか？

これは実際には素晴らしいアイデアです

デモプロジェクトはありますか？

@oliviertassinari

それを行うためにbabel-plugin-transformerを使用できませんでしたか？

React NativeのスタイルシートはCSSとはかなり異なるため、トランスフォーマーの作成は非常に複雑になるため、よくわかりません。

デモプロジェクトはありますか？

まだ原因ではありません」私はかなり忙しいですが、すぐに小さなデモをお見せしようと思います。
しかし、これが私たちがしなければならないことです

スタイルシート

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

に

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

zIndexソリューション

JSX

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

に

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

また、 styles/transition.jsx （React Nativeはobject代わりにstring ）、 mixins/style-propable.jsxを変更する必要があります。これは、複数のブラウザーを処理する必要がないためです。

https://github.com/lenaten/material-ui-nativeでreact-nativeへのWIPフォークを公開してい
現在、CardとRaiseButtonのみが機能していますが、スタイルはありません（WIPを覚えていますか？）

@lenatenおもしろい！
また、このプロジェクトとmrn（https://github.com/oliviertassinari/react-material）の間のラッパーの作業を開始したいと思いました。
あなたのフォークはreact-nativeでしか機能していないようですが、ブラウザでもどのように機能させるのでしょうか？
これが最も難しい点であり、2つの作業コンポーネントがあると言っているので、今すぐ対処する必要があると思います。 よろしければお手伝いさせていただきます。
前に述べたように、ネイティブ実装についてはhttps://github.com/binggg/mrnも調査したいと思いました。

それが答えられたら、私たちはあなたのフォークをここにマージすることができると思います。

Material-UIは、多くのマテリアルコンポーネントが欠落しているmrnプロジェクトに対する成熟したプロジェクトです。 私のPOCが例外として機能する場合は、それをクロスプラットフォームのファイル構造にマージするのは簡単です。 車輪の再発明をして、ゼロからプロジェクトを始める時間がありません。

とにかく、思考とコードのあなたの助けは大歓迎です。

@oliviertassinari私も。

material-uiをブラウザとネイティブの両方で機能させるという私の考えは、 react-activeがiOSとAndroidを同時に処理するのと同じように、ファイル名構造を使用することです。

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

または、ブラウザとネイティブの両方に同じコンポーネントを使用して、それらを処理するラッパーを作成することもできます。 たとえば、 react-nativeはViewを使用し、ブラウザはdivを使用して、次のようにします。

div.browser.jsx

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

div.native.jsx

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

app-bar.jsx

import {div} from "div"

このラッパー用に別のプロジェクトを実際に作成できます。

@ quanglam2807それを聞いてうれしいです。

コード編成に関しては、個別のファイル拡張子を持つというアイデアが好きです。
その方法として、 https：//github.com/benoitvallon/react-native-nw-react-calculator/tree/master/src/common/componentsの例を取り上げ

プロジェクトの組織については、気が変わったかもしれません。
Googleのアプローチに従い、大きな単一のリポジトリで作業する方が良いと思います。 したがって、material-uiまたはここでフォーク同期に取り組むことはそれを行うための良い方法かもしれません。

.nativeファイルから始めるには、

• https://github.com/binggg/mrn
• またはhttps://github.com/xinthink/react-native-material-kit

コンポーネント。

@oliviertassinari 「ファイル拡張子」モデルのアイデアも大好きです。 今私にとって最も重要なのは、ネイティブコンポーネントの動作です。 コードの抽象化を支援したい場合は、歓迎します。 リポジトリ名から「ネイティブ」サフィックスを削除することを約束します:)

@lenatenは、material-ui-nativeとtcomb-form-nativeとの互換性があります。そうでない場合、プロジェクトの規模はどのくらいになりますか？

@mvayngrib私はしばらくの間このプロジェクトに

@lenatenそれは残念です、応答してくれてありがとう

了解しました。この。
少し時間がかかります！

@oliviertassinari素晴らしい！ とても興奮しています

それで、港の努力はまだ開いていますか？ もしそうなら、コンポーネントを実装するためのプロセスで何が決まったのですか？

@dorthweinまだ開いています。

私の観点からすると、プロセスは次のとおりです。

• []最新バージョンのreact-nativeにアップグレードし、 react-native-webpack-serverを削除しプロジェクトでそれを行っています。 https://github.com/callemall/material-ui/pull/3829
• [] react-lookを試して、コンテキストからのmuiThemeどれだけうまく使用できるかを確認してください。 https://github.com/callemall/material-ui/pull/3829
• [x]フォルダの再編成を待って、新しいコンポーネントを配置する場所を確保します
• []新しいコンポーネントを紹介するために使用するドキュメントアプリの作業を開始します。
• []コンポーネントのネイティブバージョンでの作業を開始します。

@ oliviertassinari-前進が設定されたら、いくつかのコンポーネントの移植に少し

@dorthweinそれを聞いてうれしいです。
私はreactを使用しています-ここを見てください＃3829。 私が持っている唯一の問題はマイナーなものです。 React Nativeは、 StyleSheet APIの誤った使用に関する警告を表示しています。 詳細は調べていませんが、解決できると思います。

@oliviertassinari @dorthweinこの努力（つまり、 material-uiをreact-nativeにもたらす）が死んでいないことを嬉しく思います。 このスレッドで言及されていない別の新しいmaterial-uiからreact-nativeプロジェクトもあることを指摘したいと思います： https ： https://github.com/binggg/mrnに基づいているよう

@oliviertassinariこの移植でiOSをサポートすることが理にかなっている場合は、別のスレッドで見ました。特に、Googleマップやその他のGoogle Material + iOSアプリがどのように存在するかを見ると絶対にそうだと思います。 それが理にかなっていて、強力な既存のiOSコンポーネント（スイッチなど）がある場合は、iOSのiOSスイッチに使用する必要があります。 AndroidとiOSの実装もそれほど負担にはなりません。

@oliviertassinari component.native.js、component.android.js、component.ios.jsのファイル構造も私にとって最も理にかなっているようです。

@oliviertassinariドキュメントを起動して実行しようとしましたが、うまくいきませんでした。 いくつかの問題：

• package.json：react-nativeはパッケージ名material-uiを好みません-materialUIに変更すると問題が解決しました
• 現在のmaterial-ui / react-nativeブランチには、react-native packagerに問題があり、mainjs.bundleファイルが作成されていません。 ここで何が起こっているのか理解できませんでした。
• 既存のマテリアルUIレポの上にreact-nativeアプリが機能しているようには見えません。 誰かがこの面で運が良ければ、ネイティブコンポーネントセットを提供/開発する方法をここで安定させましょう。

@dorthweinフィードバックをありがとう。 反応ネイティブブランチは非常に実験的です。 これを解決する必要があります。
一方、私は自分の側で問題はありません（https://github.com/callemall/material-ui/pull/3829）。
新しいgit cloneから始めてみるべきです。

ええ、私の現在のプロジェクトの次の段階は、マテリアルデザインを使用したモバイルアプリに取り組んでいます。これを使用したいのは、すべてのWebコンテンツもこれに含まれているからです。 作業環境を整えることができれば、プロジェクトと一緒にそれをノックアウトし始めます。

いくつかのことを読んでいて、FB React NativePageからこの一口に気づきました。

「UIを構築するための最も基本的なコンポーネントであるViewは、フレックスボックス、スタイル、一部のタッチ処理、およびアクセシビリティコントロールを備えたレイアウトをサポートするコンテナであり、他のビュー内にネストされ、あらゆるタイプの0から多数の子を持つように設計されています。View UIViewであるかどうかに関係なく、Reactが実行されているプラ​​ットフォームに相当するネイティブビューに直接マップします。

また、このリソースを見つけました-今それを試してみてください。 かなり簡単なようで、多分一見の価値があります

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

@dorthwein素晴らしいアイデアです！ しかし、この道をたどれば、ReactNativeのみのバージョンを開発する方が良いと思います。

ネイティブとDOMの別々のコードの代わりに、React NativeAPIでプロジェクト全体を書き直すことができます。 すばらしい！ 私はこれについて考えたことがありません。

@ quanglam2807ええ-そうすれば新機能など...

欠点は、すべてがフレックスボックスを使用する必要があることです。

これがコードベースの主要なリファクタリングであることを考えると、先に進むために誰がこれを承認する必要がありますか？ 私はまだ遊んで、react-native-webのものがどれほど堅牢であるかを確認する必要があります。

@ quadnglam2807 @oliviertassinariこのアプローチのもう1つの利点は、material-uiがhttps://github.com/ptmt/react-native-desktopにも簡単に移植できることです。

@oliviertassinariはreact-native-webを使用していますが、このプロジェクトのメンテナは、期待どおりに機能した場合に遅れをとることができますか？

@dorthweinこのプロジェクトの背後にあるアイデアが大好きです。 しかし、近い将来、それが役立つとは思いません。
react-native-web使用する前に、まずコンポーネントのネイティブバージョンを作成する必要はありませんか？

@oliviertassinariいいえ、react-native-webが行うことは、プラットフォームに応じて最も「ネイティブ」なコンポーネントを使用することです。 たとえば、Viewタグが与えられた場合、ブラウザではdiv、iOSではUIView、そしてUIViewに相当するものはAndroidを使用します。

このプロセスでは、各コンポーネントのネイティブバージョンを作成する代わりに、既存のコンポーネントを変換して、divの代わりにViewを使用し、h1やlabelなどを使用する代わりにTextのスタイルを設定する必要があります。

確かに小さな仕事ではありませんが、プロセスは、複数のバージョンを作成して維持しようとするのではなく、既存のコンポーネントを更新することになります。

このプロセスでは、各コンポーネントのネイティブバージョンを作成する代わりに、既存のコンポーネントを変換して、divの代わりにViewを使用し、h1やlabelなどを使用する代わりにTextのスタイルを設定する必要があります。

これは、ブラウザでも機能するネイティブバージョンを作成するのとまったく同じように聞こえます。 私の知る限り、 react-native-webはWebにネイティブな反応をもたらし、その逆ではありません。
それでも、同じコードを共有するのは本当に便利です：+1:。
私はこれまでこのlibで1つの小さな問題を見てきました。 それらのStyleSheet.create実装は、動的な値をサポートしていません（muiThemeに必要）。 このユースケースでは、reactlookを使用できます。

@oliviertassinariあなたの権利-私はそれを逆に理解していました。 ステップ1まだコンポーネントのreact-nativeバージョンを構築しているようです。 ステップ2は、react-native webのようなものを使用して、それらを単一のコードベースにマージする可能性があります。

@wordyallen ：よさそうだ👍

@pgangwani私はちょうどそれをいじり始めました...それはまだ準備ができていません。

私はhttps://github.com/react-native-material-design/react-native-material-designを使用してギャップを埋めてきましたが、エッジの周りも非常に粗く、活発な開発はありません

できれば、この取り組みに寄付をします。

こんにちは、みんな、

私はこのライブラリに触発されたreact-native-material-uiに取り組んでいます。 お気軽にお試しください-フィードバックをお聞かせください;）

@xotahalet 。 al、私たちがすべきことを最初から作成する代わりに、IMHOはこのライブラリをフォークし、既存のコンポーネントを再作成するのではなく移植します。 私に言わせれば、RNスペースではマテリアルスタイルの入力の必要性が非常に必要です。 OSSの努力に感謝します。

一般的なコードはあまりないと思います。最初から作成するのは理にかなっていると思います。 RNのスタイリングはこれとは90％異なります。 そして、アニメーションのようなプラットフォーム固有のメカニズムがかなりあります...

コンポーネント構造、小道具（およびドキュメント）を採用し、アップストリームを明確にすることは、たとえ多くの変更があったとしても、Webからネイティブに移行する人々にとって長期的に有益であり、最も重要であるようです。 残りは実装の詳細になります。

@jhabdasに同意し

@chadobadoまたはメンテナ、このSupportReactNative 」に変更して

FWIW、これが私の目に留まりました。

@necolas on Webサポートreact-native-material-kit ：

React NativeのWeb実装によって互換性が提供されるため、スタイルシートがあれば、移植する必要はほとんどありません。

@jhabdas反応ネイティブで少し遊んそれほど単純ではないことがわかります。 StyleSheet APIは素晴らしいですが、かなりの部分を書き直す必要があります;）

フェアポイント@antoinerousseau。 RNに関するJamesLongからの引用を思い出します。

Webの別の方向性のプロトタイプと考えてください

ライブラリ@necolasの目的が機能していることを理解している場合、問題を逆転させるのがReact Native Material Kitは、すでに問題をうまく解決しています。

react-native-webは素晴らしいように見えるので、私は自分の個人プロジェクトでmaterial-ui.android.js 、 material-ios.ios.js 、およびmaterial-ui.web.jsファイルを作成してそれを適切と呼びます。 他のすべてをラップしてmaterial-ui APIに従うと、最終的にはうまくいきます。 場合はmaterial-ui私に驚きとだけ動作しますが、私は削除する必要があります.webから.web.js他のファイルを、削除します。 このようにして、コンポーネントごとにmaterial-ui選択的に移行できます。

@oliviertassinariそこで、NPM依存関係としてreact-nativeブランチを追加し、すべてのBabelプラグインをインストールしました。 コンポーネントをインポートすると、次のメッセージが表示されます。

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

私の目標は、コンポーネントごとに実行可能になるのが最も早くmaterial-uiを使用することです。 確かに、私はgit rebase masterを実行しましたが、どちらかといえばgit rebase nextを実行する必要がありました。 現在、すべての個々のreact-nativeコンポーネントは、 nextブランチ作業の準備によって障害がありますか？

そして、 material-uiアイコンを消費するのとまったく同じ方法でreact-native-vector-iconsを消費できるようにするコードをいくつか作成しました。

// <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をインポートして繰り返し処理し、リスト全体を1つの大きなオブジェクトとしてエクスポートする必要がありました。

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ブランチはかなり古くなっています。 ユーザーが消費することを意図したものではありません。 これは、今後の方向性に関する概念実証でした。
私がこの問題を見た限り、有望なアプローチの1つは、 react-nativeをターゲットにするように書き直すことです。 次に、 react-native-webが私たちにとって難しい部分を行います。
ただし、いくつかの課題があります。

• どのくらいの_react-native-web_が本番環境に対応していますか？ たとえば、私は視覚テストを見たことがありません。
• メディアクエリをどのように処理しますか？
• 複雑なテーマソリューションをどのように処理しますか？

リアクション・ウィズ・スタイルも一見の価値があります。

どのくらいのreact-native-webが本番環境に対応していますか？

@oliviertassinari現在、ウェブサイトをreact-native-webに移植していますが、受け入れる価値があると感じています。 クロスプラットフォームのアンカータグhrefコンポーネントが欠落しており、他の優れた機能が欠落している可能性がありますが、基盤となるReactDOMは本番環境に対応しており、それが必要です。

メディアクエリをどのように処理しますか？

material-ui気にする必要がありますか？ すべてのプラットフォームでコンポーネントまたは画面の寸法を見つける方法があります。 material-uiコンポーネントに、スタイリングを制御する小道具を渡すことができる限り、私たちは金色だと思います。

material-uiはメディアクエリを実行しますか？ する必要がありますか？

複雑なテーマソリューションをどのように処理しますか？

プラットフォームをチェックして、React Nativeでサポートされていない小道具を省略または名前変更することはできません。これは、（メモリが適切に機能する場合）ReactNativeではパディングとマージンが本質的に逆になるためです。 createStyleSheetと同等のメソッドをラップして、結果を非「Web」プラットフォーム固有の互換性のあるスタイルに変換/フィルタリングするだけです。

まだ使っていませんが、 Felaはクロスプラットフォームを目指しており、それが重要だと思います。 Felaの作者がReactLookを書いたので、そしてそれが事前の選択だったように思われるので、それは自然な選択のように感じます。

私も使用していませんが、 react-tunnelようなものはテーマのコンテキストに適しているようです。 コミュニティで共有できると感じたという理由だけで、単純に使用して公開することができました。 より人気のある同等のものがあるかもしれません。

どのくらいのreact-native-webが本番環境に対応していますか？ たとえば、私は視覚テストを見たことがありません。

ここにインタラクティブな例があります： https ：

メディアクエリをどのように処理しますか？

JavaScriptでは、 matchMediaを使用して（またはDimension ）、レンダリングするスタイルとコンポーネントを決定します。

クロスプラットフォームのanchor-taghrefコンポーネントがありません

ええ、「適切な」ソリューションがどうあるべきかはわかりませんが、今のところリンクのようにViewとTextを使用できます（もちろん、Webサポートのみ）。

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

複雑なテーマソリューションをどのように処理しますか？

React Nativeは、これをどのように行うかを気にしません。 contextを使用して、適用するスタイルオブジェクトを決定できます。 コンポーネント内のFelaのAPIは非常に気に入っていますが、 react-native-webを使用する場合、実装とプラグインのAPIはやり過ぎのように見えます。

createStyleSheetと同等のメソッドをラップして、結果を非「Web」プラットフォーム固有の互換性のあるスタイルに変換/フィルタリングするだけです。

RN互換ではないスタイルAPIを公開するという問題はありますか？ もしそうなら、RN互換のスタイルAPIを公開し、 react-native-webそれをDOMスタイルに変換することをお勧めします。

@necolas

RN互換ではないスタイルAPIを公開するという問題はありますか？ もしそうなら、RN互換のスタイルAPIを公開し、react-native-webにそれをDOMスタイルに変換させることをお勧めします。

いい視点ね。 たとえば、 react-native-webは:hover意味がありますか？

@necolasそして私が行っている特定の作業は常緑のブラウザをサポートする必要があるだけですが、 react-native-web移植すると、古いバージョンとのmaterial-uiブラウザの互換性が失われる可能性はありますか？ 私はそれについて本当に何も知りません。 react-native-webが正しいアプローチだと思います。

ホバースタイルに特別なことは何も提供しません（RNも提供しません）。 WindowsとUbuntuのデスクトップ実装は、マウスインターフェイス用に何かをバンドルしているのか、それともイベントを介してあなたに任せているのだろうか。

どのブラウザサポートが必要かわかりませんが、問題が発生したときに対応できる可能性があります

react-native-webとreact-domコンポーネントスタイルAPIのどちらかを選択するには、 react-native-web MuiThemeProviderを介してブール値をコンポーネント階層コンテキストに注入する必要があると思います。

最善の答えは、 react-native-webスタイルのAPIに切り替えることです。これは私が提唱することですが、それはおそらく混乱を引き起こすでしょう。

@oliviertassinari material-uiをreact-nativeスタイルのAPIに切り替えることで逃げることができますか？ たぶん、マウス固有のスタイルが漏れることを許可しますか？

@ necolas @ oliviertassinari参考までに。 今はだらしのないものですが、私は過去2〜3日間、ブランチ（https://github.com/mattferrin/material-ui-build/tree/mine）をクロスプラットフォームに移植することに取り組んできました。本当に自分で必要です（長期的に私の総作業量を減らすため）。

私はすべてをreact-native-web構文に移植し、移植しないスタイルをコメントアウトしてきましたが、最終的にはコメントを付け直し、 Platform.OS == 'web'を使用して元のコードを本質的に保持することになります。作業中のWebサイトの移植が完了したら、変更はありません。 その時点で、私が個人的に必要とするものだけが移植され、不完全になります。

MacとWindowsのマシン間をその場でジャンプするためにプッシュするので、（後で修正するまでは）完全に混乱します。

MUIがRNに来るのを待つことができない人のために、代替案があり、いくつかのかなり見栄えの良いものがあります。 私はここで常緑樹のリストを維持しています： https ：//habd.as/awesome-react-components/#react -native

スタイリングソリューション全体が変更されていることはわかっていましたが、ライブラリが最初から書き直されている部分を見逃していました。 それは私のせいです。 いくつかのコードを見て、エンドスタイルは基本的に同じままであり、テクノロジーのみが変更されると思いました。 私は間違っていました。 私はロードマップを完全に無視しませんでした、私はただ非常に間違った仮定をしました。 私はここでの私の試みを保釈しなければならないと思います。

@mattferrin完全にゼロからではありませんが（場合によってはTable ）、スタイルソリューションの変更には多くのAPIの変更が必要ですが、それに加えて、多くのコンポーネントについて他の領域のAPIを合理化する機会があります。 。 あなたの努力が無駄になってしまったらごめんなさい-それがあなたをMaterial-UIから遠ざけないことを願っています！

@mbrookesそうではありません。 私は、分岐の間違い作っmasterの代わりに、 nextとの違い（と一般的には総作業）を過小評価します。 それは私のせいであり、リスクがあることを知っていました。 後でReactNative material-uiファサードに配置されるまで、空のText要素をプレースホルダーとして返すだけです。 Webサイトをreact-native-webに完全に移植したら、戻って新しい変更をnextからリベースしようとします。

今日この男を解放する： https ：

マテリアルUIに触発され、ウェブ上で動作し、react-native :)

@tuckerconnellyあなたは私の日を作りました

@tuckerconnellyすごい、このプロジェクトには多くの可能性があります...よくできました！ より大きなコミュニティがこの取り組みの背後に集結することを期待しています！ 🍻

@tuckerconnelly私は少し混乱しています。 material-ui条件付きでクロスプラットフォームにするのは実際には非常に簡単であることがわかりました（ master代わりにnext masterを分岐して時間を無駄にするという私の間違いにもかかわらず）。 独立したプロジェクトにどのようなメリットがあるのか​​知りたいです。

2月に試してみましたが、特にリップルコンポーネントやクロスプラットフォームのメディアクエリで苦労しました。

ゼロから始める方が簡単な場合もあります。

私にとって、React Nativeで動作しないReactコンポーネントを使用することは意味がありません...そしてmaterial-uiの開発者はRNを優先事項と見なしていなかったため、新しいパスを開始することは公正/論理的です

@tuckerconnellyコンポーネントの実装方法は重要ではないと思います。 両方のプロジェクトがコンポーネントに同じAPIを実装しようとする（そして同じ名前に同意する）ことを願っています。 あなたがこれに取り組み、共有してくれてうれしいです。

したがって、v1.0.0以降の2017/2018では、RNがmaterial-uiの次の目標になりますか？

のように：

• v1へのコミュニティの参加
• RNサポートを希望する人の数
• 多くのプロジェクトが、RNコンポーネントを提供するためにMaterial-uiに基づいているか、それに触発されているという事実
• これらすべてから得られた経験と、この号が発行されてから多くの時間が経過したという事実

（おそらくv1のリリース後に）RNコンポーネントを提供するプロジェクトを開始する場合は、多くの人があなたを助けてくれるでしょう。 明確なパスを開始して定義するだけで、すぐに実行できます。 あなたは素晴らしいコミュニティを持っています。それを使って最高の製品を作りましょう。

@NitroBAY 1.0は、スタイリングにJSオブジェクトではなくJSSを使用するため、ReactNativeをサポートするためにcssinjs / jss＃368に依存しています。 しかし、 https ： ます。 次に、 https：//github.com/necolas/react-native-webを使用してReactNativeバージョンをWeb上で実行でき

それで、これは修正されませんか？ もしそうなら、それはそのようにタグ付けできますか？

@jhabdasマテリアル仕様を取り入れた優れたライブラリが欲しいです。
スレッドに投稿されたリンクから、候補者の良いリストがすでにあります。

その問題を開いたままにしておくと、それはWebとネイティブの統合に関するものです。 2つのプラットフォーム間で一貫したAPIを提供します。 それに取り組む時間があればいいのにと思いますが、そうはなりませんし、それが変わるのではないかと思います。
@ callemall / Material-uiチームは、誰かがその問題を主導するのを見たいと思っています。

引き続きcarbon-uiをサポートします:)必要に応じてコンポーネントを追加するだけです（仕様全体を積極的に記入しようとはしません）が、人々が後れを取るための優れたフレームワークがあると思います。

• コンポーネントのコメントからドキュメントを自動生成します
• ドキュメントサイト（carbon-ui.com）があります
• 同じコンポーネントでネイティブとWebをサポート

コンポーネントを追加したい人を助けます:)

@tuckerconnelly https://github.com/xotahal/react-native-material-uiについてどう思いhttps://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.jsを適用した場合は、動作します。 @oliviertassinariは、一緒に作業するためのメインプロジェクトを決定する必要があるという良い点を示しています。

@quangbuuleは、アプリをRNアプリとして開発し、そのツールを使用してRNをWEBバージョンに変換する必要があると言っているのを待ちますか？
私はそのことを聞いたことがありませんが、大丈夫です。 しかし、それは、 material-uiもう使用せず、RNフォークを使用することを意味しますか？

@NitroBAY基本的にmaterial-uiをRNフォークに移植します。準備ができたら、Webとネイティブの両方の公式バージョンになると思います。 マテリアルUIを考慮すると、問題はないと思います。次のブランチでも同様のアプローチを使用しています。

すべての初心者の質問で申し訳ありませんが、私は約1週間からReactLandに着陸します。

あなたはあなたのパッケージがこれを置き換えるつもりだと思いますか？
あなたのアプローチはマルチプラットフォームのようで、とても良いです。 Material-uiは時間がないのでウェブだけに固執しますが、次の時間はあります。なぜですか？
nextはnext同形アプローチを使用すると言いますが、紙などのコンポーネントを使用すると、 divコンポーネントがあるため、Webでのみ機能します。
weは誰ですか、あなたはこのチームの一員ですか？
技術的な考慮事項に関係なく、IOSでMDを使用するとユーザーを困らせる可能性があると思いませんか？

編集：トピックから外れていますが、誰も私に答えませんjss-theme-reactorをjss-reactと比較すると、どのような利点がありますか？

@NitroBAY ：

1. 私はこのプロジェクトやReactNativeプロジェクトの開発者ではありません。 しかし、私はこの問題を何ヶ月も見てきました。そして今のところ、 react-native-material-ui貢献し始めるのを楽しみにしています。
2. paperまたはshadowthingyが現在Web、iOS、Androidで動作しています。 ですから、大したことではありません。
3. material-ui masterブランチはオブジェクトを使用してスタイルシートを定義しますが、パフォーマンスを向上させるために（30％ブースト）、寄稿者はnextブランチでJSS（JSのCSS）に切り替えます。 現時点では、JSSはReactNativeと互換性がありません。
4. GoogleはiOSでマテリアルデザインを使用しており、ユーザーはそれほど気にしないと思います。 もちろん、ステータスバーの色を変更したり、iOS共有アイコンを使用したりするなど、プラットフォームに合わせて一部を変更する必要があります。Windows10とmacOSアプリにmaterial-uiましたが、あまり表示されませんでした。ユーザーはそれについて不平を言った（http://moderntranslator.com/）。 MDの方が使いやすいと言う人さえいました。

しかし、コンポーネントがspanやdivなどのHTML要素を使用している場合、 nextブランチがRNでどのように機能するかはまだわかりません。 何かが足りなかったかもしれませんが、RNで開発するには、RNコンポーネントを使用する必要がありますね。
私はあなたを引用しています：

Webとネイティブの両方の公式バージョンになります。 マテリアルUIを考慮すると、問題はないと思います。次のブランチでも同様のアプローチを使用しています。

しかし、私はそれを正しく取得できなかったかもしれません。 nextブランチでRNのコンポーネントを使用できるようになるということですか？

@NitroBAY ： nextブランチは、 material-uiとReactNativeとの互換性を低下させます。 また、RNコンポーネントはspanまたはdivをサポートしていませんが、条件付きルールを使用すると、次のようになります。

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

確認できます： //github.com/necolas/react-native-web

ああ、そうだね、彼らがRNと互換性を作ったということだと思った。

このプロジェクトがReactNative APIを介したマルチプラットフォームサポートに関心がないTL; DRであり、その取り組みはhttps://github.com/xotahal/react-native-material-uiに移動する必要があり

carbon-uiのドキュメントの方が優れており、すでにWeb上で機能しています。 react-native-material-uiの利点は何ですか？

それで、誰もがmaterial-uiが使用されなくなり、数時間以内に推奨されることに同意しますか？ それでは、このパッケージの所有者がRNを望まないのは残念ですか？

carbon-uiは、 StyleSheetを使用しないことと、非常に多くのWebフォントを挿入することにより、パフォーマンスの問題が発生するようです。

落ち着いて、みんな！ それはまだ来ています。

TL; DR：React Nativeのコンポーネントをビルドすると、RNとWebで機能します。 ただし、Web用のコンポーネントを作成すると、RNでは機能しません。 そして、 material-uiはWeb用に構築され、Web用に最適化されています=> RNで動作させるには、パフォーマンスを犠牲にする必要があります（少なくとも現時点では）。 したがって、RNがより成熟するまで、2つのプロジェクトを分離しておく方がよいと思います。

Web用に最適化=> RNで動作させるには、パフォーマンスを犠牲にする必要があります（少なくとも現時点では）

それについて共有するデータはありますか？

これまでのRNWに関する私の調査結果は次のとおりです。

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

@ necolas ＃4066

うーん、ウランでStyleSheetを使用することを検討できます。 CSS関連のパフォーマンスの問題には気づいていませんが、StyleSheetのものとより適切に統合できるかどうかを確認します。

最大のパフォーマンスヒットはAnimatedから来ています： //github.com/animatedjs/animated/issues/48しかし、それはすべてのRNWアプリケーションに影響します。

Webフォントを挿入すると、パフォーマンスが大幅に低下しますか？ それらはグーグルフォントから直接ロードされるので、それらはすでにユーザーのシステムにキャッシュされている可能性があります。

私が思うに最も重要なことは、誰もが単一の図書館の後ろに集まるということです。 そして、私はmaterial-uiがReactNativeをサポートするとは思わない。

@necolas TL; DRは、今後の進路が不明確であるということです。

A = react-native
B =ウェブ

1.最も制約のあるプラットフォーム

考えられるアプローチは、最も制約のあるプラットフォームをターゲットにすることです。したがって、

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

ただし、これにはトレードオフが伴い、コード共有に勝ちます。 しかし、私はいくつかの側面で失うことを期待しています。

ネイティブAPIをWebに導入する

ブラウザで動作するには、APIを再実装する必要があります。 オーバーヘッドは何ですか？

不足しているWebAPIをネイティブで処理する

最も制約のあるプラットフォームから始めると、Webで利用可能な機能を再実装する必要があります。 メディアクエリはどうですか？ CSSの継承、CSSアニメーション？
ネイティブバージョンを肥大化させることなく、アクセシビリティとキーボードイベントを誰に実装しますか？

2.制約の少ないプラットフォーム

もう1つの解決策は、制約の少ないプラットフォーム、つまりWebから開始することです。 次に、不足しているネイティブ機能の再実装を作成します。

ただし、これにはトレードオフが伴い、コード共有に勝ちます。 しかし、私はいくつかの側面で失うことを期待しています。

WebAPIをネイティブに持ち込む

犠牲を払う必要があります。たとえば、CSSメディアクエリやCSSアニメーションなど、一部のWeb機能をネイティブに実装するのは非常に難しいと思います。 （高度なCSSルール）

Webで欠落しているネイティブAPIの処理

不足しているWebAPI機能のいくつかは、タッチ処理、スクロールと無限のリストビュー、DatePickerやDrawerなどのネイティブコンポーネントに関するものです。

3.契約の共有

3番目の解決策は、APIとテストを共有するインフラストラクチャをセットアップしてから、基盤となる2つのプラットフォームでコンポーネントを再実装することです。 私の認識では、それはリアクションネイティブがiOSとAndroidにどのように近づいているかです。
次に、前の2つのアプローチを混合して、契約を完全に履行します。 つまり、それが理にかなっているときにコード分岐を使用し、可能な限りコードを共有します。
例えば：

• CSSトランジションを使用できるのに、なぜブラウザでanimated.jsを使用するのですか？
• ネイティブコンポーネントを使用できるのに、 react-nativeにDrawerロジックを実装するのはなぜですか？

オプション3が最も有望だと思います。 これが、 react-swipeable-viewsの問題を解決しようとした方法です。

https://github.com/tuckerconnelly/uraniumはクロスプラットフォームのメディアクエリをサポートしています:)

RNの利点は、抽象APIとプリミティブの単純なライブラリがあり、低レベルの実装が処理されることです。 アニメーションは同じです。アニメーション用のシンプルなライブラリ、低レベルの実装（iOS / Androidのネイティブアニメーション、Webのcssトランジション）が処理されます。

私はanimated.jsがcssトランジションを使用するようにジガーできると思います。 確かにパフォーマンスが向上します。

@ quanglam2807そのスレッドは非常に長いです、私は何を見るべきですか？

機能をWebに拡張するために、 https ： //github.com/necolas/react-native-web、https ： 。

react-webは、パフォーマンスや機能的に正しいIMOとはほど遠いものです。

ブラウザで動作するには、APIを再実装する必要があります。 オーバーヘッドは何ですか？

どの次元でオーバーヘッドがありますか？ バンドルサイズの観点から判断するのは難しい。 おそらく、既存のコードの一部を削除できるでしょう。 ただし、RNWコアのエクスポート以外のものに依存する場合は、すぐに追加されます。 mobile.twitter.comのスタイルを多用するコンポーネントでは、スタイルをcss-modulesからRNW StyleSheetに変換するコンポーネントサイズが20〜40％削減されています。 実行時のパフォーマンスに関しては、現在css-modulesからそれほど遠くありません。

メディアクエリはどうですか？

matchMediaを使用してスタイルとコンポーネント構造を変更できますが、メディアクエリを使用してコンポーネントを変更する利点は私にはわかりません。

CSSの継承、CSSアニメーション？

RNWはCSSアニメーションをサポートしています（ただし、キーフレームを定義するためにAPIを追加する必要があります）。 CSSの継承に関連する質問は何ですか？

ネイティブバージョンを肥大化させることなく、アクセシビリティとキーボードイベントをどのように実装しますか？

これが何を意味するのかわからない。 ネイティブアプリの「膨張」のしきい値は、Webアプリよりもはるかに高いと思います。

したがって、react-native-webがスタイルを処理してcssパフォーマンスをcss-modulesパフォーマンスにレンダリングする方法を比較することは、今ではあまり適切ではありません。

なぜそうなるのでしょうか？

アフロディーテやjssのようなものを使用する一種のreact-native-webがあると素晴らしいでしょう

これらのライブラリはどちらも低速で大きく、決定論的なスタイルを提供するのにはあまり適していません

@necolas material-uiは、css-in-jsメソッドからスタイルシートメソッド（ <style> css）に切り替えるための多大な努力を提供しています。 彼らは、コンポーネントを切り替えるために何ヶ月も積極的な努力をしてきました。 理由はここにあります。 私がjssを使用して読んだことから、これは大きな利点であり、これまでのところスタイルを処理するための最も完璧なソリューションのようです。

ちなみに、Roadmap.mdをもう一度読むと、RNサポートはロードマップにあります。

Material-UIをreact-nativeで使用することに非常に興味がありますが、進捗状況について教えてください。

@wswoodruff今のところこれを確認できます：//github.com/xotahal/react-native-material-ui

現在、そのための3つの素晴らしいライブラリがあります。

• react-native-material-kit★3110-マテリアルデザインをReactNativeにもたらします。

• react-native-material-design★2447 -ReactNative MaterialDesignコンポーネント

• react-native-material-ui★1040 -ReactNative用の高度にカスタマイズ可能なマテリアルデザインコンポーネント。

楽しみ！

あまり知られていないもありますカーボンUIはあなたがユニバーサルつもりなら。 しかし、私の時間の間、私はおそらくこれらの1つに固執するでしょう。

このスレッドでは何度か触れられていますが、この変更への関心にどのように影響するかを考えて、もう一度呼びかけたいと思います。私が見ているreact-nativeサポートの主な利点は、実際にはreact-nativeに関するものではありません。 、代わりに、同じコンポーネントをネイティブとWebの両方で使用できるようにするプリミティブに基づいて構築することについて。

そのタイプのプリミティブが使用された場合、 react-sketchupやreact-pdfなどの他のツールも有効にできます。

個人的には、それらはネイティブよりも私にとって興味深いものですが、同じ変更によって可能になります。

@jhabdas Carbon UIの使用経験はどうですか？ 私にはBczはかなり良さそうに見えますが、まだ使用していません。

@ deadcoder0904はまだ個人的に使用していません。 おそらく、無限の赤で男の一人に手を差し伸べてみてください。 彼らはRNニュースレターを運営しており、対象分野の専門家である必要があります。 別のRNアプリを作成する場合（わかりました、いつ...）今回は、物事をまとめたり、別の定型文を作成したりすることはありません。IMHOのスペースは、既存の定型文とコンポーネントによって解決され

React NativeでMUIを利用できるようにするには、克服する必要があると私が考えることができるいくつかのハードルがあります。 v1 MUIを想定し、JSS、 classesパターン、およびこの時点でMUIのAPI設計の重要な部分であるその他のものを保持します。

• JSSはRNをサポートする必要があります。つまり、withStylesが正しく機能するようにスタイルオブジェクトを作成する必要があります。 詳細については、 https： //github.com/cssinjs/jss/issues/368#issuecomment-376708219を
• ハッキーなラッパーやbabel変換がないと仮定すると、 classesパターンを拡張して同じように機能させる必要がありますが、RNでは代わりに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は、物事の低レベルの部分（入口/出口の処理など）を処理するためのいくつかの優れた理想がありますが、他の場合は問題があります。 また、cssトランジションベースのデザインの代わりに、新しいWeb Animations APIを使用し、そのためのポリフィルを必要とするという前向きな方法があると思います。
  言い換えれば、ブラウザのWebアニメーションとReact NativeのアニメーションAPIを使用するReactのアニメーションを処理するための新しいライブラリを作成する余地があり、MUIがアニメーションを処理する方法を全般的に改善していると思います。
• MUIは、カスケード動作が利用可能であるという期待を捨てる必要があります。 また、サブツリー内のテーマに簡単に変更を適用できるように、テーマの設定を強化する必要があります。
  現在、AppBar + Iconsのようなものは、テキストの色を設定し、明示的なcolor = 'inherit'を使用して、色がカスケードダウンすると想定することで機能します。 そして、これはMUIの他の部分でも同じである可能性があります。
  React Nativeには、このようなカスケードはありません。 代わりに、ビューごとにスタイルを明示的に宣言する必要があります。 これらのタイプのものについては、AppBarおよびその他のコンポーネントは、アイコンが正しい対照的なアイコンを取得するように、そのコンテキスト内のテーマをdark変更するなどの変更を加えて、提供されるテーマの変更バージョンを簡単に提供できる必要があります。色（テキストの色ではなく、実際のアイコンの色の仕様に基づくことができます）。 これは、アプリバーにネストされたメニューなどに影響を与える可能性があることに注意してください。
• このカスケード問題の延長として。 MUIは<Button>Text</Button>ようなものも中心に設計されており、MUIはボタンのルートのfontFace / colorなどのスタイルを設定し、子に何でも挿入でき、ReactDOMに挿入させることができると想定されています。要素とテキストノードの組み合わせとテキストノードが適切なスタイルになります。
  これはReactNativeでは崩壊します。 すべてのテキストは<Text>一部である必要があり、すべてのテキストスタイルはそのコンポーネントのスタイル上にある必要があり、テキスト要素に非テキストの子を含めることはできません（つまり、）。
  いくつかのオプションがあります：
  
  
  
  • <Button text='Text' />パターンは、ReactNativeではるかにうまく機能します。 残念ながら、それはMUIの精神とは根本的に異なるため、オプションではありません。
  
  
  • 子をマップし、文字列をスタイル付きのテキスト要素に置き換えることができます。 ただし、これは壊れやすく、文字列をバラバラにするもので包んだ瞬間に（react-intlでもバラバラになります）。 うーん。
  
  
  • それはそれを行うための最も美しい方法ではありません、私たちは待たなければならないでしょう、そして私はパフォーマンスへの影響を100％理解していません。 しかし、React 16.3の新しいコンテキストAPIを使用して、 <MuiText>Text</MuiText>を公​​開することはできます。 基本的に、 ButtonなどのMUIコンポーネントには、現在のコンテキストのスタイル（フォント、テキストの色など）に関する情報を提供するプロバイダーがあり、MuiTextはそのデータを消費してText要素に適用します。
  
  

本日v1がリリースされたので、ReactNative❓の計画は何ですか

React Native Material Supportには、CallStackチームによって保守およびサポートされるReact NativePaperと呼ばれる美しいライブラリがあります。

しかし、Paperは完全に正常に機能すると思うので、これをReactNativeに移植する計画はありますか❓

そうでない場合は、おそらくこの問題を閉じることができます:)

@ deadcoder0904を共有していただきありがとうございます。 Awesome ReactComponentsにPaperを追加しました。 CallStackについて聞いたことがありません。 最初はCall-Em-Allと読みました。 彼らは同じのぞき見ではないと思いますか？

@jhabdasいいえ、彼らは同じではありません

@dantmanネイティブサポートを実現するための最善の方法についての私の考えは

• jssに固執することが絶対的な要件ではない場合、私はfelaが実行可能な代替手段であると思います。
  
  
  
  • fela-nativeはメディアクエリをサポートし、 StyleSheet.createを適切に使用
  
  
  • それはめちゃくちゃ拡張可能です。 Webプロパティのルールをreact-nativeプロキシに書き換え、ネイティブの:hoverルールなどを削除し、jssから失われた構文を取り戻すことができます。
  
  
• react-native-animatableはキーフレームをサポートしており、おそらくtransition-groupの代わりに使用できます。これは、nativeで機能する場合と機能しない場合があります。
• 私は、react-nativeのカスケードされていない見方を覆すことに同意します。 cascadeとinherit小道具を使用して、プロバイダーとコンシューマーでオプトインすることができます。
  @shoutem/themeを使用してオーバーライドを許可するもの（native-baseなど）を除いて、私が試したすべてのreact-nativeライブラリは、過度に厳密なAPIとオーバーライドできないスタイルのために苦痛または使用できません

まだこのサポートを待っています。 Webで美しく使用していますが、私もモバイルで開発しています。

サポートリアクションネイティブに関する更新はありますか？

@oliviertassinariフォークして、上記で概説した実装パスの調査を開始する予定です。 私の優先事項は、別のプロジェクトに必要なコンポーネントを機能させることです。そのため、すぐに堅牢なReact NativeサポートをPRすることはおそらくないでしょうが、できる限りマスターと「同期」させておくようにします。いつか役立つ（またはおそらくマージされる）ことを願って

@micimize教えてくれてありがとう。 このプロジェクトで頑張ってください！ :)なぜreact-nativeにまだ取り組んでいないのかについて。 いろいろな味があると思います。 最も重要なことは、そのようなことに関心のあるコアメンテナがいないことです。 私はそれを理解することができます、react-domの使用はreact-nativeよりも速く成長し、それは難しいです。

これに関する更新：リスト、ボタン、カード、アイコン、選択コントロール、テキストフィールド、背景など、機能のかなりの部分をある程度使用可能な状態に移行しました。 残念ながら、最終的にReact-Nativeでアプリ自体を開発すると、多数の問題が発生し、Flutterに移行せざるを得なくなりました。

ある時点で、私たちが行った作業の一部、主にcss-shorthand-propertiesやその他の優れたものを活用したwithStyles / classesスタイリングソリューションの移植を取り戻したいと思いますが、それはもはや優先事項ではありません私のため。

@rogerstormはこの問題に200ドルの資金を提供しました。 IssueHuntでご覧ください

問題に取り組むことは私たちにとって機会費用になります。 閉店します。 ブラウザのユースケースをより適切にサポートすることを倍増します。

@oliviertassinari 、それは、react 載らないことを意味しますか？

はい

https://github.com/lightningtgc/react-native-material-uiは別の詐欺npmパッケージに他なりません