Material-ui: 支持 React Native

创建于 2015-04-28  ·  119评论  ·  资料来源: mui-org/material-ui

绝对漂亮的图书馆。

将来有没有将其移植到 React-Native 的计划?

enhancement

最有用的评论

@rogerstorm用 200 美元资助了这个问题。 在 IssueHunt 上查看

所有119条评论

刚刚发现了这个仓库: https :
不过不知道好不好用。

谢谢@chadobado - 我们肯定已经讨论过了,这将是一个有趣的项目开始。 然而,我们现在已经忙于这个项目了。 如果我们创建了一个原生库,我会保持这个问题的开放和更新。

这实际上是一个好主意。 我试图测试将material-ui移植到 React-Native。 我们只需要稍微修改样式表,将所有div更改View ,将所有h1h2等更改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 中发布了一个 WIP 分叉到 react-native
目前只有 Card 和 RaiseButton 有效,但没有样式(WIP 记得吗?)

@lenaten有趣!
我还想开始研究这个项目和 mrn 之间的包装器(https://github.com/oliviertassinari/react-material)。
似乎您的 fork 仅适用于 react-native,您如何使其也适用于浏览器?
我认为这是最困难的一点,现在应该解决,因为你说你有两个工作组件。 如果你愿意,我可以帮忙。
如前所述,我还想调查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>
  }
}

应用-bar.jsx

import {div} from "div"

我们实际上可以为这个包装器创建一个单独的项目。

@quanglam2807我很高兴听到它。

关于代码组织,我喜欢拥有单独的文件扩展名的想法。
我会以https://github.com/benoitvallon/react-native-nw-react-calculator/tree/master/src/common/components示例作为实现方式。

关于项目组织,我可能改变了主意。
我认为最好遵循谷歌的方法并在一个大的单一存储库上工作。 因此,与 material-ui 或这里进行 fork 同步可能是一个好方法。

从我们的.native文件开始,我们可以依赖

组件。

@oliviertassinari我也喜欢“文件扩展名”模型的想法。 现在对我来说最重要的是使用原生组件。 如果您想帮助代码抽象,欢迎您。 我承诺从 repo 名称中删除“本机”后缀 :)

@lenaten与 tcomb-form-native 兼容 material-ui-native,或者如果不兼容,那将是一个多大的项目?

@mvayngrib我停止在这个项目上工作了一段时间..

@lenaten很遗憾,感谢您的回复

好的,我已经开始在这个https://github.com/callemall/material-ui/pull/2611工作了
这需要一些时间!

@oliviertassinari太棒了! 非常非常兴奋

那么港口的努力仍然开放吗? 如果是这样,实现组件的确定过程是什么?

@dorthwein它仍然开放。

从我的角度来看,过程如下:

@oliviertassinari - 一旦确定了前进的

@dorthwein我们很高兴听到它。
我在这里使用 react-look #3829。 我唯一的问题是一个小问题。 React Native 显示了一些关于StyleSheet API 错误使用的警告。 我没有详细查看它,但我相信它可以解决。

@oliviertassinari @dorthwein我很高兴这项努力(即把material-ui带到react-native )没有死。 我只是想指出,还有另一个新的material-uireact-native项目在这个线程中没有提到: https : https://github.com/binggg/mrn。

@oliviertassinari我在另一个线程中看到,如果支持 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 打包程序的问题,并且没有创建 mainjs.bundle 文件。 我一直无法弄清楚这里发生了什么。
  • 我似乎无法在现有的 material-ui 存储库之上获得一个可以工作的 react-native 应用程序。 如果有人在这方面有任何运气,那么让我们来了解一下如何贡献/开发原生组件集。

@dorthwein感谢您的反馈。 react-native 分支是高度实验性的。 我们需要解决这个问题。
另一方面,我这边没有任何问题(https://github.com/callemall/material-ui/pull/3829)。
我应该尝试从一个新的git clone

是的,所以我当前项目的下一个阶段是使用材料设计开发移动应用程序 - 我想使用它,因为我们所有的网络内容也都在其中。 如果我们能够获得一个工作环境,我将开始将它与我们的项目一起淘汰。

正在阅读一些东西,并注意到来自 FB React Native Page 的这个花絮。

“构建 UI 的最基本组件,View 是一个容器,它支持带有 flexbox、样式、一些触摸处理和可访问性控件的布局,并且被设计为嵌套在其他视图中,并且可以拥有 0 到多个任何类型的子视图。直接映射到 React 运行的任何平台上的原生视图等价物,无论是 UIView,

, android.view 等。此示例创建了一个视图,该视图将两个彩色框和自定义组件包装在一行中,并带有填充。”

来源: https :

鉴于此,我认为我们当前的方法可能有点偏离,因为大部分通用工作可以通过将 div 切换到 View 来完成。 标题和其他相关标签也必须以更通用的方式进行映射。

想法?

还找到了这个资源 - 现在试试。 看起来很简单,也许值得一试

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

@dorthwein好主意! 但是如果我们遵循这条路,我认为只为 React Native 开发一个版本会更好。

我们可以在 React Native API 下重写整个项目,而不是为 Native 和 DOM 单独编写代码。 惊人! 我从来没有想过这个。

@quanglam2807是的 - 新功能等...保持一致。 我认为最大的挑战是让样式和动画正常工作。 另一个大优点是我们可以逐步添加对不同组件的支持。

不利的一面是一切都需要使用弹性盒子。

鉴于这是对代码库的重大重构 - 谁都需要签署此协议才能继续前进? 我仍然需要尝试一下,看看 react-native-web 的东西有多健壮。

@quanglam2807 @oliviertassinari这种方法的另一个优点是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。

然后,该过程将代替编写每个组件的本地版本,我们只需将现有版本转换为使用 View 而不是 div 和 style Text 而不是使用 h1 和 label 之类的东西。

绝对不是一件小事,但该过程将更新现有组件,而不是尝试创建和维护多个版本。

然后,该过程将代替编写每个组件的本地版本,我们只需将现有版本转换为使用 View 而不是 div 和 style Text 而不是使用 h1 和 label 之类的东西。

这听起来就像编写一个希望也能在浏览器中工作的本机版本。 据我所知, react-native-web将 React Native 引入网络,而不是相反。
尽管如此,共享相同的代码真的很方便:+1:。
到目前为止,我已经看到了这个库的一个小问题。 他们的StyleSheet.create实现不支持动态值(muiTheme 需要)。 我们可以使用反应查找这个用例。

@oliviertassinari你的权利-我是倒着理解的。 第 1 步似乎仍在构建组件的本机版本。 第 2 步可能会使用 react-native web 之类的东西将它们合并到一个代码库中。

@wordyallen :看起来不错👍

@pgangwani我刚开始弄乱它......它还没有准备好。

我一直在使用https://github.com/react-native-material-design/react-native-material-design来填补空白,但边缘也很粗糙,没有积极的开发

如果可以的话,我会为这项工作捐款。

嗨,大家好,

我在react-native-material-ui 上工作,这是受这个库的启发。 随意尝试 - 我想听听任何反馈;)

@xotahal等。 al,恕我直言,我们应该做的不是从头开始创建,而是分叉这个库并移植现有组件,而不是重新创建它们。 如果你问我,RN 空间非常需要材料风格输入。 感谢大家为 OSS 所做的努力。

我认为没有太多通用代码,我认为从头开始创建是有意义的。 RN 中的样式将与此样式有 90% 的不同。 还有一些平台特定的机制,比如动画......

似乎采用组件结构、props(和文档)并有一个清晰的上游,即使有很多变化,对于那些从 web 到本地来回转换的人来说都是长期有益的,并且是最重要的。 其余的成为实现细节。

我同意@jhabdas ; API 对每个组件的查找越相似,开发人员切换 Web 项目和原生项目的麻烦就越小。 体验越不刺耳,他们的工作效率就越高。 我希望在组件的幕后抽象出特定于平台的细节。

@chadobado或维护者,您能否将此问题重命名为“支持 React Native”以在搜索此存储库时提高可见性? 当前搜索“React Native”将其隐藏在列表中,因为该术语在标题中带有连字符。

FWIW,这引起了我的注意。

@necolasreact-native-material-kit网络支持

如果任何样式表都由 React Native 的 Web 实现提供了兼容性,那么您不太可能需要移植太多内容

@jhabdas如果您玩一下 react native,您会发现它并不那么简单。 StyleSheet API 很棒,但你必须重写一些东西;)

公平点@antoinerousseau。 我一直在回想起 James Long 在 RN 上的一句话:

将其视为网络不同方向的原型

如果我理解库@necolas正在工作的目的,那么似乎一种理智的方法是解决问题:与其将 CSS 移植到 RN,不如使用 shim 在 RN 中重建整个事物并为 web 反向端口。 React Native Material Kit已经很好地解决了这个问题。

由于react-native-web看起来很棒,所以我将在我自己的个人项目中创建material-ui.android.jsmaterial-ios.ios.jsmaterial-ui.web.js文件并称之为好。 如果我通过包装其他所有内容来遵循material-ui API,它最终会成功。 如果material-ui让我惊讶,只是工作,我只需要在删除.web.web.js并删除其他文件。 这样我可以有选择地转换到每个组件material-ui

@oliviertassinari所以我添加了react-native分支作为 NPM 依赖项并安装了所有 Babel 插件。 导入任何组件时我收到此消息:

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

我的目标是尽可能快地使用material-ui每个组件。 当然,我做了git rebase master并且应该做git rebase next如果有的话。 现在是否所有单独的react-native组件都被next分支工作准备所阻碍?

我写了一些代码,让我消耗react-native-vector-icons以完全相同的方式,我消费material-ui图标:

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

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

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

虽然目前react-native-vector-iconsmaterial-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-iconsmaterial-ui导入约定兼容?

@mattferrin react-native分支现在已经很老了。 它不打算供用户使用。 这是关于前进道路的概念证明
就我所看到的这个问题而言,一种有前途的方法是将其重写为目标react-native 。 然后react-native-web将为我们做最困难的部分。
但是,也存在一些挑战:

  • 多少 _react-native-web_ 已准备好生产? 例如,我还没有看到视觉测试。
  • 你如何处理媒体查询?
  • 您如何处理复杂的主题解决方案?

react-with-styles也值得一看。

多少 react-native-web 准备好生产了?

@oliviertassinari我目前正在将一个网站移植到react-native-web ,并且觉得它值得拥抱。 它缺少一个跨平台的锚标签 href 组件并且可能缺少其他细节,但是底层的 ReactDOM 已经准备好生产,这就是我们所需要的。

你如何处理媒体查询?

material-ui在意吗? 有多种方法可以在所有平台上查找组件或屏幕的尺寸。 只要material-ui组件可以传递控制样式的道具,他们这样做,我认为我们是黄金。

material-ui执行媒体查询? 我们需要吗?

您如何处理复杂的主题解决方案?

我们不能只检查Platform以忽略或重命名 React Native 不支持的道具,因为(如果我没记错的话)填充和边距在 React Native 中基本上是颠倒的。 我们所要做的就是包装createStyleSheet等效方法,以将结果转换/过滤为非“web”平台特定的兼容样式。

我还没有使用它,但Fela 的目标是跨平台,我认为这很重要。 由于 Fela 的作者编写了 React Look,而且这似乎是一个优先选择,所以感觉像是一个自然的选择。

我也没有使用过它,但是像react-tunnel这样的东西对于主题上下文来说似乎不错。 我们可以简单地使用和公开它,再次只是因为它感觉更易于社区共享。 可能有一个更受欢迎的等价物。

多少 react-native-web 准备好生产了? 例如,我还没有看到视觉测试。

这里有交互式示例: https :

你如何处理媒体查询?

在 JavaScript 中,使用matchMedia (或使用Dimension )来确定要呈现的样式和组件。

它缺少一个跨平台的锚标签 href 组件

是的,我不确定“正确”的解决方案应该是什么,但是您现在可以使用ViewText类的链接(当然,仅限网络支持):

<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 的桌面实现是否为鼠标界面捆绑了任何东西,或者通过事件将其留给您。

我不确定您需要什么浏览器支持,但可能会在出现问题时提供支持

我认为可能有必要通过MuiThemeProvider将布尔值注入组件层次结构上下文中,以便在react-native-webreact-dom组件样式 API 之间进行选择。

最好的答案是只切换到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'基本上保留原始代码一旦我完成了我正在开发的网站的移植,就没有改变。 到那时,只有我个人需要的东西才会被移植并且不完美。

这完全是一团糟(直到我稍后对其进行修改),因为我推动在 Mac 和 Windows 机器之间快速跳转。

对于那些等不及 MUI 加入 RN 的人来说,还有其他选择,而且还有一些非常漂亮的选择。 我在这里维护一个常青名单: https: //habd.as/awesome-react-components/#react -native

我知道整个样式解决方案正在发生变化,但我错过了从头开始重写库的部分。 那是我的错。 通过查看一些代码,我假设最终样式基本上保持不变,只有技术会改变。 我错了。 我并没有完全忽略路线图,我只是做了非常错误的假设。 我想我将不得不放弃我在这里的尝试。

@mattferrin并非完全从头开始(尽管在某些情况下确实如此,例如Table )虽然样式解决方案更改需要许多 API 更改,但另外让我们有机会在其他领域为许多组件合理化 API . 如果你的努力被浪费了,我很抱歉 - 我希望它不会让你离开 Material-UI!

@mbrookes没有。 我犯了一个错误,即分支master而不是next并低估了差异(以及总体工作量)。 这是我的错,我知道有风险。 我将简单地返回空的Text元素作为占位符,直到稍后在我的 React Native material-ui外观中。 当我将我的网站完全移植到react-native-web我会回来尝试重新调整next新更改。

今天放出这家伙: https :

受 material-ui 启发,可在 web 和 react-native 上工作 :)

@tuckerconnelly你让我开心

@tuckerconnelly哇,这个项目有很多潜力……干得好! 希望更大的社区能够团结起来支持这项努力! 🍻

@tuckerconnelly我有点困惑。 我发现让material-ui有条件地跨平台实际上很容易(尽管我错误地分支了master而不是next并且浪费了我的时间)。 我很好奇你认为独立项目有什么好处?

我在 2 月份尝试过,但使用起来很困难,尤其是使用波纹组件和跨平台媒体查询。

有时从头开始会更容易。

对我来说,让 React 组件不能在 React Native 上运行是没有意义的……而且由于 material-ui 的开发人员并不认为 RN 是优先事项……从新的道路上开始是公平/合乎逻辑的

@tuckerconnelly我认为如何实现组件并不重要。 我只是希望两个项目都尝试为其组件实现相同的 API(并就相同的名称达成一致)。 我很高兴你在这方面工作并分享了。

那么在 v1.0.0 之后的 2017/2018 年,RN 会是 material-ui 的下一个目标吗?

如所见:

  • 社区参与到 v1
  • 需要 RN 支持的人数
  • 许多项目基于 Material-ui 或受其启发来提供 RN 组件这一事实
  • 从这一切中获得的经验以及自从这个问题被打开以来已经过去了很多时间的事实

如果您开始(可能在 v1 发布之后)一个提供 RN 组件的项目,很多人会帮助您。 您只需要开始并定义一条清晰的路径,就可以了。 你有一个很棒的社区,让我们用它来制造最好的产品。

@NitroBAY 1.0 使用 JSS 而不是 JS 对象进行样式设置,因此它依赖 cssinjs/jss#368 来支持 React Native。 但我认为最好为 React Native 开发一个像这样的并行版本: https : https://github.com/necolas/react-native-web在 Web 上运行 React Native 版本

那么这是一个不会修复的问题吗? 如果可以,可以这样标记吗?

@jhabdas我希望看到一个好的库将材料规范引入 React Native。
从帖子中发布的链接中,已经有一个很好的候选人名单。

如果我们让这个问题保持开放,那就是关于统一网络和本地。 在两个平台之间提供一致的 API。 我希望我有时间来解决这个问题,但我没有,而且我怀疑它会改变。
@callemall/material-ui 团队希望看到有人带头解决这个问题。

仍然支持 carbon-ui :) 我只在需要时添加组件(而不是主动尝试填写整个规范),但我认为那里有一个很好的框架供人们支持。

  • 它从组件注释中自动生成文档
  • 有文档站点 (carbon-ui.com)
  • 支持具有相同组件的本机和 Web

会帮助任何想要添加组件的人:)

@tuckerconnelly你觉得https://github.com/xotahal/react-native-material-ui 怎么样? 由于 Elevation 的错误,它在网络上不起作用,但如果我们应用您的代码https://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.js ,我认为它会工作。 @oliviertassinari提出了一个很好的观点,即我们需要决定一个主要项目来合作。

@quangbuule等你说我们应该将应用程序开发为 RN 应用程序,然后使用该工具将 RN 转换为 WEB 版本?
我从来没有听说过那件事,但没关系。 但这意味着我们不再使用material-ui而是更多地使用 RN fork ?

@NitroBAY我们基本上将material-ui 移植到RN fork,我认为当它准备好时,它将成为web 和native 的官方版本。 考虑到 material-ui 在下一个分支中使用类似的方法,我认为这很好。

对不起所有的菜鸟问题,但我从大约 1 周开始就进入了ReactLand

你认为你的包裹会取代这个吗?
你的方法似乎是多平台的,非常好。 Material-ui 只坚持网页,因为他们没有时间,但他们有时间下一步,为什么?
你说nextnext上使用同构方法,但如果我采用任何组件,即纸张,它只适用于网络,因为有一个div组件。
we是谁,你是这个团队的一员吗?
抛开技术上的考虑,你不觉得在 IOS 上使用 MD 会惹恼用户吗?

编辑:题外话,但没有人回答我, jss-theme-reactorjss-react相比有什么优势?

@NitroBAY

  1. 我不是这个项目或任何 React Native 项目的开发者。 但我已经关注这个问题几个月了,目前,我期待开始为react-native-material-ui做出贡献。
  2. paper或影子的东西现在正在 web、iOS、Android 上运行。 所以这没什么大不了的。
  3. material-ui master分支使用对象来定义样式表,但为了提高性能(提升 30%),贡献者在next分支中切换到 JSS(JS 中的 CSS)。 目前,JSS 与 React Native 不兼容。
  4. 谷歌在 iOS 上使用 Material Design,我认为用户并不介意。 当然,您应该修改一些部分以适应平台,例如更改状态栏的颜色,使用 iOS 共享图标等。我在我的 Windows 10 和 macOS 应用程序中使用了material-ui ,我没有看到很多用户抱怨它(http://moderntranslator.com/)。 甚至有人说 MD 更容易使用。

但是我仍然不明白如果组件使用诸如spandiv HTML 元素,那么span next分支可以在 RN 中以何种方式工作。 我可能遗漏了一些东西,但是要在 RN 中进行开发,您需要使用 RN 组件,不是吗?
我引用你的话:

它将成为 web 和 native 的正式版本。 考虑到 material-ui 在下一个分支中使用类似的方法,我认为这很好。

但可能我没有正确理解它。 你的意思是next分支会让我们能够在 RN 中使用组件吗?

@NitroBAYnext分支将使material-ui与 React Native 的兼容性降低。 此外,即使 RN 组件不支持 span 或 div,通过使用条件规则,您也可以这样:

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

您可以查看: https :

哦,好吧,我以为你的意思是他们让 RN 兼容。

TL;DR 是不是该项目对通过 React Native API 的多平台支持不感兴趣,并且该努力应该转移到https://github.com/xotahal/react-native-material-ui?

carbon-ui 的文档更好,它已经在网络上运行。 react-native-material-ui 有什么好处?

所以大家都同意material-ui会在一段时间内停止使用和推荐吗? 那么可惜这个包的所有者不想要 RN ?

carbon-ui看起来会因为不使用StyleSheet和注入这么多网络字体而出现性能问题

screen shot 2017-03-15 at 1 10 26 pm

冷静点,伙计们! 它还在来。

TL;DR:如果你为 React Native 构建一个组件,它将在 RN 和 web 上工作。 但是如果你为 web 构建一个组件,它就不能在 RN 上工作。 并且material-ui是为 web 构建的,为 web 优化 => 要使其在 RN 上工作,必须牺牲性能(至少目前是这样)。 因此,我认为最好将两个项目分开,直到 RN 更加成熟。

为 web 优化 => 为了使其在 RN 上工作,必须牺牲性能(至少,目前)

你有什么数据可以分享吗?

到目前为止,这是我对 RNW 的发现:

@necolas #4066

嗯,我可以考虑将 StyleSheet 与 Uranium 一起使用。 我会说,没有注意到任何与 CSS 相关的性能问题,但会看看我是否可以更好地与您的 StyleSheet 内容集成。

最大的性能损失来自 Animated: https :

注入网络字体是否会显着降低性能? 它直接从谷歌字体加载它们,因此它们可能已经缓存在用户的系统上。

我认为最重要的事情是让每个人都团结在一个图书馆后面。 而且我认为 material-ui 不会支持 React Native。

@necolas TL;DR 是前进的道路尚不清楚

union

A=react-native
B=网络

1. 最受约束的平台

一种可能的方法是针对最受限制的平台,因此从react-native 开始。 然后将功能扩展到网络。 为了将功能扩展到网络,我们可以使用:

但是,这需要权衡,我们将赢得代码共享。 但我预计在某些方面会失败。

将原生 API 引入网络

必须重新实现 API 才能与浏览器一起使用。 开销是多少?

在本机中处理缺少的 Web API

当我们从最受限制的平台开始时,我们需要重新实现一些网络可用功能。 媒体查询呢? CSS继承,CSS动画?
我们会在不膨胀原生版本的情况下实现可访问性和键盘事件?

2. 约束较少的平台

另一种解决方案是从限制较少的平台开始,因此是网络。 然后创建重新实现缺少的本机功能。

但是,这需要权衡,我们将赢得代码共享。 但我预计在某些方面会失败。

将 Web API 引入本机

我们将不得不做出牺牲,我预计某些 Web 功能很难在原生上实现,例如 CSS 媒体查询、CSS 动画。 (高级 CSS 规则)

处理网络中缺少的原生 API

一些缺少的 Web API 功能是围绕触摸处理、滚动和无限列表视图、DatePicker 或 Drawer 等原生组件。

3.合约共享

第三种解决方案可能是建立一个基础设施来共享 API 和测试,然后在两个底层平台中重新实现组件。 在我看来,这就是react-native如何接近 iOS 和 Android。
然后使用前两种方法的混合方法来完全履行合同。 我的意思是,在有意义的情况下使用代码分支并尽可能多地共享代码。
例如:

  • 当我们可以使用 CSS 过渡时,为什么还要在浏览器上使用
  • 当我们可以使用原生组件时,为什么要在react-native上实现 Drawer 逻辑?

我认为选项 3. 是最有希望的选项。 这就是我试图解决react-swipeable-views 中的问题的方式

https://github.com/tuckerconnelly/uranium 支持跨平台媒体查询 :)

RN 的美妙之处在于您拥有一个简单的抽象 API 和原语库,并且处理了低级实现。 Animated 是一样的——简单的动画库,低级实现(iOS/Android 上的本机动画,web 上的 css 转换)被照顾。

我认为animated.js 可以使用css 过渡。 肯定会提高性能。

@quanglam2807那个线程很长,我应该看什么?

为了将功能扩展到网络,我们可以使用: https://github.com/necolas/react-native-webhttps://github.com/taobaofed/react-web

react-web远非高性能或功能正确的 IMO。

必须重新实现 API 才能与浏览器一起使用。 开销是多少?

开销在哪些维度? 很难根据捆绑大小来确定。 您可能可以删除一些现有代码; 但是,如果您要依赖 RNW 核心出口之外的任何东西,它会很快加起来。 在 mobile.twitter.com 的样式繁重的组件中,我已经看到将样式从 css-modules 转换为 RNW StyleSheet 的组件大小减少了 20-40%。 就运行时性能而言,它目前与css-modules 相差不远

媒体查询呢?

您可以使用matchMedia更改样式和组件结构,尽管我不清楚使用媒体查询更改组件的好处。

CSS继承,CSS动画?

RNW 支持 CSS 动画(虽然我需要添加一个 API 来定义关键帧)。 与 CSS 继承相关的问题是什么?

我们如何在不膨胀原生版本的情况下实现可访问性和键盘事件?

不知道这意味着什么。 我怀疑原生应用程序中“膨胀”的阈值远高于网络应用程序。

所以也许现在比较 react-native-web 如何处理样式以呈现 css 性能与 css-modules 性能不太相关

为什么会这样?

有一种 react-native-web 使用类似 aphrodite 或 jss 的东西会很棒

这两个库都更慢、更大,并且不太适合提供确定性样式

@necolas material-ui正在努力从 css-in-js 方法切换到样式表方法( <style> css )。 几个月来,他们一直在积极努力转换组件。 原因就在这里。 从我阅读的内容来看,使用 jss 是一个巨大的优势,并且似乎是迄今为止处理样式的最完美解决方案。

顺便再次阅读 Roadmap.md,RN 支持在 Roadmap 上。

我对使用带有 react-native 的 Material-UI 非常感兴趣,有什么进展吗?

@wswoodruff你现在可以检查这个 - https://github.com/xotahal/react-native-material-ui

目前,我们为此提供了三个很棒的库:

享受!

如果您要通用,还有鲜为人知的Carbon UI 。 但就我的时间而言,我可能会坚持其中之一

它在这个线程中被触及了几次,但我想再次指出它,因为它如何影响我对这种变化的兴趣:我看到的 react-native 支持的主要好处实际上并不是关于 react-native ,而是建立在原语之上,这些原语使相同的组件既可以在本机也可以在 Web 上使用。

如果使用了这种类型的原语,还可以启用其他工具,如react-sketchupreact-pdf

就个人而言,这些对我来说比原生更有趣,但会通过相同的更改来启用。

@jhabdas 您使用 Carbon UI 的体验如何? Bcz 对我来说它看起来不错,但还没有使用它。

@deadcoder0904个人还没有使用过。 可能会尝试与无限红的人之一联系。 他们运行 RN 时事通讯,应该是主题专家。 如果我确实构建了另一个 RN 应用程序(好吧,什么时候......)我这次不会把东西拼凑在一起或构建另一个样板——恕我直言,空间是由现有的样板组件解决的。

以下是我认为需要克服的一些障碍才能使 MUI 在 React Native 中可用。 假设 v1 MUI 并且我们保留 JSS、 classes模式以及其他在这一点上是 MUI api 设计的关键部分的东西。

  • JSS 需要支持 RN,即以 withStyles 可以正常工作的方式制作样式对象。 更多信息参见
  • 假设没有 hacky 包装器或 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可以将样式组合助手作为道具的一部分传入。
  • 正如其他人提到的那样,为了使基本样式的组件工作,我们需要额外的工作来使动画、可触摸等......工作。
  • 但是对于动画,我不认为这是一件坏事。 对于简单的过渡来说,这是一个小小的损失,您只是自动过渡opacitybackgroundColor等,我们可能需要帮助保持这些简单的助手。 但据我所见,除那些之外的实际材质转换实现看起来过于复杂/神秘,并且无法很好地扩展。 react-transition-group对处理事物的低级部分(进入/退出处理等)有一些很好的理想,但在其他方面存在问题/方式。 此外,我认为取代基于 css 转换的设计,前瞻性思维方式是使用新的 Web Animations API 并需要 polyfill。
    换句话说,我认为有空间创建一个新的库来处理 React 中的动画,它使用浏览器中的 Web 动画和 React Native 中的 Animated API,并且是对 MUI 处理动画方式的总体改进。
  • MUI 需要放弃对级联行为可用的期望。 并且需要增强主题设置以支持轻松地将修改应用于子树中的主题。
    现在,像 AppBar + Icons 这样的东西通过设置文本颜色、使用明确的 color='inherit' 并假设颜色将向下层叠来工作。 这可能在 MUI 的其他部分也是一样的。
    在 React Native 中没有这样的级联。 相反,您必须为每个视图显式声明您的样式。 对于这些类型的东西,AppBar 和其他组件需要能够轻松地提供修改后的主题版本,例如将上下文中的主题更改为dark以便图标获得正确的对比图标颜色(并且可以基于实际的图标颜色规范而不是文本颜色)。 请注意,这可能会对嵌套在应用栏中的菜单等内容产生影响。
  • 作为这个级联问题的延伸。 MUI 也是围绕<Button>Text</Button>类的东西设计的,假设 MUI 可以设置按钮根的 fontFace/color 等...,让您在子项中插入任何内容,然后让 React DOM 插入元素和文本节点的混合,文本节点得到正确的样式。
    这在 React Native 中分崩离析。 所有文本必须是<Text> ,所有文本样式必须在该组件的样式上,并且文本元素不能包含非文本子元素(即)。
    有几个选项:

    • <Button text='Text' />模式在 React Native 中效果更好。 不幸的是,这与 MUI 的精神根本不同,所以它不是一个选择。

    • 我们可以映射子元素并用样式化的 Text 元素替换字符串。 然而,这很脆弱,当你将字符串包裹在任何它分崩离析的东西的那一刻(甚至 react-intl 都会让它分崩离析)。 啊。

    • 这不是最漂亮的方法,我们必须等待,而且我不能 100% 理解性能影响。 但是我们可以使用 React 16.3 的新上下文 API,并公开一个<MuiText>Text</MuiText> 。 基本上,像Button这样的 MUI 组件将具有提供有关当前上下文样式(字体、文本颜色等)的信息的提供程序,而 MuiText 只会使用该数据并将其应用于 Text 元素。

今天 v1 发布了,React Native 有什么打算❓

对于 React Native Material Support,有一个名为React Native Paper的漂亮库,它将由 CallStack 团队维护和支持。

但是有没有计划将它移植到 React Native,因为我认为 Paper 工作得非常好❓

如果没有,那么您可能可以关闭此问题:)

感谢分享@deadcoder0904。 我已将 Paper 添加到Awesome React Components 。 没听说过CallStack。 起初我把它读作 Call-Em-All。 猜猜他们不是同一个偷窥者,是吗?

@jhabdas不,他们不一样

@dantman以下是我对实现原生支持的最佳方式的看法

  • 如果坚持 jss 不是绝对要求,我认为fela是一个可行的选择:

    • fela-native 支持媒体查询正确使用

    • 它具有疯狂的可扩展性。 我们可以将 Web 属性的规则重写为它们的 react-native 代理,在原生上剥离诸如:hover规则之类的东西,并且可能重新获得从 jss 中丢失的任何语法。

  • react-native-animatable具有关键帧支持,并且可能也可以用来代替 transition-group ,它可能适用于也可能不适用于 native
  • 我同意颠覆 react-native 的无级联视图。 它可以通过cascadeinherit道具在提供者和消费者处选择加入。
    我尝试使用的每个 react-native 库都非常痛苦或无法使用,因为 API 过于僵化和不可覆盖的样式,除了那些使用@shoutem/theme来允许覆盖的库(如 native-base) .

还在等这个支持。 在 Web 上使用精美,但我也在移动设备上开发!

有关支持本机反应的任何更新?

@oliviertassinari我打算分叉并开始探索我上面概述的实现路径。 我的首要任务是让我需要的组件为另一个项目工作,所以我可能不会很快 PRing 强大的 React Native 支持,但我会尽量让它与 master 保持“同步”希望有一天它会有用(或可能合并)

@micimize感谢您告诉我。 祝你在这个项目中好运! :) 关于为什么我们还没有研究 react-native。 我认为它有不同的口味。 最重要的是,我们没有核心维护者对此感兴趣。 我可以理解,react-dom 的使用比 react-native 增长得更快,而且很难。

对此的更新:我们将大量功能迁移到有点可用的状态,包括列表、按钮、卡片、图标、选择控件、文本字段和背景。 不幸的是,一旦我们最终在 react-native 上开发我们的应用程序本身,就会出现大量问题并迫使我们转向 Flutter。

在某些时候,我想回去挽救我们所做的一些工作,主要是withStyles / classes样式解决方案的端口,它利用了css-shorthand-properties和其他一些简洁的东西,但是它不再是优先事项给我。

@rogerstorm用 200 美元资助了这个问题。 在 IssueHunt 上查看

解决这个问题对我们来说是一个机会成本。 我要关门了。 我们将加倍努力更好地支持浏览器用例。

@oliviertassinari ,这是否意味着反应原生支持超出了范围,并且在不久的将来(例如 1 年)它不会受到关注?

是的

此页面是否有帮助?
0 / 5 - 0 等级