Material-ui: Поддержка React Native

Только что обнаружил это репо: https://github.com/lightningtgc/react-native-material-ui
Хотя не знаю, хорошо ли это.

Спасибо @chadobado - мы уже говорили об этом, и было бы весело начать этот проект. Тем не менее, на данный момент мы полностью заняты этим проектом. Я оставлю этот вопрос открытым и обновлю его, если мы когда-нибудь создадим нативную библиотеку.

На самом деле это отличная идея. Я попытался протестировать перенос material-ui на React-Native. Нам нужно только немного изменить таблицы стилей, изменить все div на View , изменить все h1 , h2 и т. д. на Text и это будет работать отлично. Единственная проблема, которую я обнаружил, заключается в том, что React Native не полностью поддерживает boxShadow поэтому на данный момент сложно реализовать компонент Paper . Кроме того, было бы здорово, если бы мы могли написать отличный скрипт для автоматического переноса кода на React-Native, так как он не сильно отличается.

измените все div на 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 поскольку нам не нужно иметь дело с несколькими браузерами и т. д.

Я просто публикую разветвление WIP для реагирования на натив в https://github.com/lenaten/material-ui-native.
На данный момент работают только Card и RaiseButton, но без стиля (WIP помните?)

@ленатен Интересно!
Я также хотел начать работу над оберткой между этим проектом и mrn (https://github.com/oliviertassinari/react-material).
Кажется, что ваш форк работает только с реакцией, как бы вы заставили его работать и с браузером?
Я думаю, что это самый сложный момент и его нужно решать сейчас, так как вы говорите, что у вас есть два рабочих компонента. Я могу помочь, если хочешь.
Как было сказано ранее, я также хотел исследовать 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 пример как способ сделать это.

Что касается организации проекта, я, возможно, изменил свое мнение.
Я думаю, что лучше следовать подходу Google и работать над одним большим репозиторием. Следовательно, работа над синхронизацией форка с material-ui или здесь может быть хорошим способом сделать это.

Чтобы начать с наших файлов .native , мы могли бы полагаться на

• https://github.com/binggg/мрн
• или https://github.com/xinthink/react-native-material-kit

компоненты.

@oliviertassinari Мне также нравится идея модели «расширение файла». Самое главное для меня сейчас, это рабочие родные компоненты. Если вы хотите помочь с абстракцией кода, добро пожаловать. Я обязуюсь удалить «родной» суффикс из имени репо :)

@lenaten совместим с material-ui-native с tcomb-form-native, а если нет, то насколько большим будет этот проект?

@mvayngrib Я на некоторое время перестал работать над этим проектом..

@lenaten это позор, спасибо за ответ

Хорошо, я начал работать в этом https://github.com/callemall/material-ui/pull/2611.
Это займет некоторое время!

@oliviertassinari круто ! очень-очень взволнован

так что попытка порта все еще открыта? Если да, то каков был установлен процесс внедрения компонентов?

@dorthwein Он все еще открыт.

С моей точки зрения, процесс выглядит следующим образом:

• [] Обновите до последней версии react- native и удалите проекте . https://github.com/callemall/material-ui/pull/3829
• [ ] Поэкспериментируйте с реагирующим взглядом и посмотрите, насколько хорошо мы можем использовать его для muiTheme , исходящего из контекста. https://github.com/callemall/material-ui/pull/3829
• [x] Дождитесь реорганизации папок, чтобы нам было куда поместить новые компоненты
• [ ] Начните работу над приложением документации, которое мы будем использовать для демонстрации нового компонента.
• [ ] Начать работу над нативной версией компонентов.

@oliviertassinari - я могу

@dorthwein, мы рады это слышать.
Я использую реакцию-смотрите здесь # 3829. Единственная проблема, которая у меня есть, является незначительной. React Native отображает предупреждение о неправильном использовании API StyleSheet . Я не смотрел на это подробно, но я считаю, что это может быть решено.

@oliviertassinari @dorthwein Я рад, что это усилие (то есть material-ui в react-native ) не умерло. Я просто хотел отметить, что есть еще один новый проект от material-ui до react-native , который не упоминался в этой теме: https://github.com/react-native-material- дизайн/реагировать-родной-материал-дизайн . Этот проект, кажется, основан на https://github.com/binggg/mrn.

@oliviertassinari Я видел в другой ветке, имеет ли смысл поддержка iOS для этого порта — я думаю, что это абсолютно так, особенно если посмотреть на то, как там представлены Google Maps и другие приложения 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 и не создает файл mainjs.bundle. Я так и не смог понять, что здесь происходит.
• Кажется, я не могу получить работающее приложение для реагирования, работающее поверх существующего репозитория material-ui. Если кому-то повезло на этом фронте, давайте получим стабильную информацию о том, как вносить/разрабатывать собственный набор компонентов.

@dorthwein Спасибо за отзыв. Реактивно-родная ветвь очень экспериментальна. Нам нужно решить эту проблему.
С другой стороны, у меня нет никаких проблем с моей стороны (https://github.com/callemall/material-ui/pull/3829).
Я должен попытаться начать с нового git clone .

Да, так что следующий этап моего текущего проекта — работа над мобильным приложением с использованием материального дизайна — я хотел бы использовать его, так как все наши веб-материалы тоже в нем. Если мы сможем создать рабочую среду, я начну ее выбивать вместе с нашим проектом.

Читал кое-что и заметил этот лакомый кусочек на странице FB React Native.

«Самый фундаментальный компонент для создания пользовательского интерфейса, View — это контейнер, который поддерживает макет с помощью flexbox, стилей, некоторой обработки касаний и элементов управления доступностью, и предназначен для вложения в другие представления и может иметь от 0 до многих дочерних элементов любого типа. View сопоставляется непосредственно с эквивалентом собственного представления на любой платформе, на которой работает React, будь то UIView,

Также нашел этот ресурс - попробуйте сейчас. Кажется довольно прямолинейным и, возможно, стоит гуглить

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

@dorthwein Отличная идея! Но если мы пойдем по этому пути, я думаю, будет лучше разработать версию только для React Native.

Мы можем переписать весь проект под React Native API вместо отдельных кодов для Native и DOM. Удивительный! Я никогда не думал об этом.

@ quanglam2807 да, таким образом, новые функции и т. Д. ... Оставайтесь на одном уровне друг с другом. Я думаю, что самая большая проблема заключается в том, чтобы стили и анимация работали. Также другим большим плюсом является то, что мы можем постепенно добавлять поддержку различных компонентов.

Недостатком является то, что все нужно будет использовать flex-боксы.

Учитывая, что это серьезный рефакторинг кодовой базы — кто все должен подписать это, чтобы двигаться дальше? Мне все еще нужно поиграть и посмотреть, насколько надежен материал react-native-web.

@quanglam2807 @oliviertassinari Еще одним преимуществом этого подхода является то, что material-ui также легко https://github.com/ptmt/react-native-desktop .

@oliviertassinari использует

@dorthwein Мне нравится идея этого проекта. Но не думаю, что это поможет в ближайшем будущем.
Разве нам не нужно сначала написать собственную версию наших компонентов, прежде чем мы сможем использовать react-native-web ?

@oliviertassinari нет,

Тогда процесс будет заключаться не в написании нативных версий каждого компонента, а в том, что нам просто нужно преобразовать существующие, чтобы использовать View вместо div и стиль Text вместо таких вещей, как h1 и label.

Определенно не маленькое предприятие, но тогда процесс будет обновлять существующие компоненты, а не пытаться создавать и поддерживать несколько версий.

Тогда процесс будет заключаться не в написании нативных версий каждого компонента, а в том, что нам просто нужно преобразовать существующие, чтобы использовать View вместо div и стиль Text вместо таких вещей, как h1 и label.

Это звучит точно так же, как написать нативную версию, которая, надеюсь, будет работать и в браузере. Насколько я знаю, react-native-web привносит нативную реакцию в Интернет, а не наоборот.
Тем не менее, это может быть очень удобно, если вы используете один и тот же код :+1:.
До сих пор я видел одну небольшую проблему с этой библиотекой. Их реализация StyleSheet.create не поддерживает динамические значения (необходимые для muiTheme). Мы могли бы использовать реагирующий вид для этого варианта использования.

@oliviertassinari ваше право - я понял это задом наперед. Шаг 1, похоже, все еще создает реактивные версии компонентов. Шаг 2 потенциально может объединить их в единую кодовую базу, используя что-то вроде реактивной сети.

@wordyallen : хорошо выглядит 👍

@pgangwani Я только начал с этим возиться ... Он еще не готов.

Я использовал https://github.com/react-native-material-design/react-native-material-design, чтобы заполнить пробел, но это также очень грубо по краям и без активной разработки.

Я бы пожертвовал деньги на это начинание, если бы мог.

Привет, ребята,

Я работаю над react-native-material-ui , вдохновленным этой библиотекой. Не стесняйтесь попробовать - я хотел бы услышать любые отзывы;)

@xotahal и др. al, Вместо того, чтобы создавать с нуля то, что мы должны делать, ИМХО, это разветвление этой библиотеки и портирование существующих компонентов, а не их воссоздание. Если вы спросите меня, то потребность во входных данных стиля материала крайне необходима в пространстве RN. Спасибо всем за ваши усилия OSS.

Я не думаю, что существует много общего кода, я думаю, что создание с нуля имеет смысл. Стиль в RN будет на 90% отличаться от этого. И есть довольно специфичная для платформы механика, например, анимация...

Кажется, что принятие структуры компонентов, реквизитов (и документов) и наличие четкого апстрима, даже если многое изменится, было бы выгодно в долгосрочной перспективе для тех, кто переключается с веба на нативный и обратно, и это имеет наибольшее значение. Остальное становится деталью реализации.

Я согласен с @jhabdas ; чем более похоже API-интерфейсы могут выглядеть для каждого компонента, тем меньше неприятностей для разработчиков будет при переключении с веб-проектов на нативные проекты. Чем менее резкий опыт, тем более продуктивными они могут быть. Я ожидаю, что детали, специфичные для платформы, будут абстрагироваться за кулисами компонента.

@chadobado или сопровождающий, не могли бы вы переименовать эту проблему в «Поддержка React Native», чтобы улучшить видимость при поиске в этом репо? В настоящее время поиск «React Native» прячет это в списке, потому что термин в названии написан через дефис.

FWIW, это бросилось мне в глаза.

@necolas о веб-поддержке react-native-material-kit :

Вам вряд ли понадобится много портировать, если какая-либо таблица стилей в качестве совместимости обеспечивается веб-реализацией React Native.

@jhabdas, если вы немного

Справедливое замечание @antoinerousseau. Я все время вспоминаю цитату Джеймса Лонга из RN:

Думайте об этом как о прототипе другого направления в Интернете.

Если я понимаю цель работы библиотеки @necolas , кажется, что разумным подходом было бы обратить проблему React Native Material Kit уже хорошо справляется с этой проблемой.

Так как react-native-web выглядит потрясающе, я просто создам файлы material-ui.android.js , material-ios.ios.js и material-ui.web.js в своем личном проекте и назову его хорошим. Если я буду следовать API material-ui , обертывая все остальное, в конечном итоге это сработает. Если material-ui меня удивит и просто .web из .web.js и удалить другие файлы. Таким образом, я могу выборочно перейти на material-ui каждого компонента.

@oliviertassinari Итак, я добавил react-native в качестве зависимости NPM и установил все плагины Babel. Я получил это сообщение при импорте любого компонента:

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

Моя цель — использовать material-ui как можно скорее для каждого компонента. Конечно, я сделал git rebase master и должен был сделать git rebase next если что. Есть все индивидуальные react-native компонентов от одновременного показа next подготовки работы отделения прямо сейчас?

И я написал код, который позволяет мне потреблять react-native-vector-icons точно так же, как я потребляю значки material-ui :

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

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

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

Хотя на данный момент react-native-vector-icons и material-ui имеют несовместимый синтаксис импорта. @oblador Мне пришлось импортировать glyphMap перебрать его и экспортировать весь список как один большой объект.

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

Было бы неплохо, если бы значки материалов react-native-vector-icons были сгруппированы по категориям, например material-ui что позволяло бы экспортировать отдельные элементы из категории:

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

Должны ли мы работать над запросом на вытягивание, чтобы сделать react-native-vector-icons совместимым с соглашениями об импорте material-ui ?

@mattferrin Ветка react-native уже довольно старая. Он не предназначен для использования пользователями. Это было Proof Of Concept относительно будущего.
Насколько я рассмотрел эту проблему, одним из многообещающих подходов было бы переписать ее так, чтобы она нацеливалась на react-native . Тогда react-native-web сделает за нас всю тяжелую работу.
Однако есть некоторые проблемы:

• Насколько _react-native-web_ готов к производству? Например, я не видел визуальных тестов.
• Как вы обрабатываете медиа-запросы?
• Как вы справляетесь со сложным решением темы?

На react-with-styles тоже стоит обратить внимание.

Насколько реактивная нативная сеть готова к производству?

@oliviertassinari В настоящее время я react-native-web и считаю, что это стоит того. В нем отсутствует кросс-платформенный компонент href для тега привязки и, возможно, отсутствуют другие тонкости, но базовый ReactDOM готов к производству, и это то, что нам нужно.

Как вы обрабатываете медиа-запросы?

Должен ли material-ui волноваться? Есть способы найти размеры компонента или экрана на всех платформах. Пока компонентам material-ui можно передавать реквизиты, управляющие стилем, что они и делают, я думаю, мы в золоте.

Выполняет ли material-ui медиа-запросы? Нам это нужно?

Как вы справляетесь со сложным решением темы?

Разве мы не можем просто проверить платформу, чтобы опустить или переименовать неподдерживаемые реквизиты React Native, поскольку (если мне не изменяет память) отступы и поля в React Native по существу меняются местами. Все, что нам нужно сделать, это обернуть эквивалентный метод createStyleSheet для преобразования/фильтрации результата в стили, несовместимые с «веб-платформой».

Я еще не использовал его, но Fela стремится быть кроссплатформенным, и я думаю, что это важно. Поскольку автор Fela написал React Look, и поскольку это, кажется, был предварительный выбор, это кажется естественным выбором.

Я также не использовал его, но что-то вроде react-tunnel кажется хорошим для тематического контекста. Мы могли бы просто использовать и выставлять его, опять же, только потому, что он кажется более доступным для сообщества. Возможно, есть более популярный аналог.

Насколько реактивная нативная сеть готова к производству? Например, я не видел визуальных тестов.

Здесь есть интерактивные примеры: https://necolas.github.io/react-native-web/storybook/

Как вы обрабатываете медиа-запросы?

В JavaScript, используя matchMedia (или используя Dimension ), чтобы определить, какие стили и компоненты отображать.

Отсутствует кроссплатформенный компонент href для тега привязки.

Да, я не уверен, каким должно быть "правильное" решение, но пока вы можете использовать View и Text как ссылки (конечно, только через веб-поддержку):

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

Как вы справляетесь со сложным решением темы?

React Native не возражает против того, как вы это делаете. Вы по-прежнему можете использовать context чтобы определить, какие объекты стиля следует применить. Мне очень нравится API Fela в компонентах, но реализация и API плагинов выглядят излишними, если вы будете использовать react-native-web .

Все, что нам нужно сделать, это обернуть эквивалентный метод createStyleSheet для преобразования/фильтрации результата в стили, несовместимые с «веб-платформой».

Проблема в том, что вы предоставляете API стиля, который не совместим с RN? Если это так, я бы посоветовал вам предоставить RN-совместимый API стилей и позволить react-native-web преобразовать его в стили DOM.

@неколас

Проблема в том, что вы предоставляете API стиля, который не совместим с RN? Если это так, я бы посоветовал вам предоставить 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-web и API стиля компонента react-dom .

Лучший ответ — просто переключиться на API стиля react-native-web , и это то, что я бы рекомендовал, но это, вероятно, вызовет расстройство.

@oliviertassinari Можем ли мы перейти с material-ui на API в стиле react-native ? Может быть, разрешить просачиваться определенным стилям мыши?

@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://carbon-ui.com

Вдохновлен material-ui, работает в сети и в React-Native :)

@tuckerconnelly ты сделал мой день

@tuckerconnelly вау, у этого проекта большой потенциал... молодец! Мы надеемся, что более широкое сообщество сплотится вокруг этих усилий! 🍻

@tuckerconnelly Я немного сбит с толку. Я обнаружил, что на самом деле довольно легко сделать material-ui условно кросс-платформенным (несмотря на мою ошибку, состоящую в ответвлении master вместо next и напрасной трате времени). Мне интересно, какие преимущества вы видите в независимом проекте?

Я попробовал его еще в феврале, и мне пришлось нелегко, в частности, с компонентом ripple и с кросс-платформенными медиа-запросами.

Иногда проще просто начать с нуля.

для меня нет смысла иметь компоненты React, которые не работают на React Native ... и, поскольку разработчики material-ui не считали RN приоритетом ... справедливо/логично начать новый путь

@tuckerconnelly Я не думаю, что имеет значение, как реализованы компоненты. Я просто надеюсь, что оба проекта попытаются реализовать один и тот же API (и согласовать одинаковые имена) для своих компонентов. Я рад, что вы работали над этим и поделились.

Итак, на 2017/2018 год после v1.0.0 будет ли RN следующей целью для material-ui?

Как видно из:

• Участие сообщества в v1
• Количество людей, которые хотят получить поддержку RN
• Тот факт, что многие проекты были основаны или вдохновлены Material-ui для предложения компонентов RN.
• Опыт полученный из всего этого и тот факт, что прошло много времени с момента открытия этого вопроса

Если бы вы начали (вероятно, после запуска v1) проект по предложению компонентов RN, многие люди бы вам помогли. Вам просто нужно начать и определить четкий путь, и все будет хорошо. У вас отличное сообщество, давайте использовать его, чтобы сделать лучший продукт.

@NitroBAY 1.0 использует JSS вместо объектов JS для стилизации, поэтому он полагается на cssinjs/jss#368 для поддержки React Native. Но я думаю, что лучше разработать параллельную версию для React Native, подобную этой: https://github.com/xotahal/react-native-material-ui. Затем мы можем запустить версию React Native в Интернете, используя https://github.com/necolas/react-native-web.

Так это исправление? Если да, то можно ли его пометить как таковой?

@jhabdas Мне бы хотелось, чтобы хорошая библиотека
По ссылкам, выложенным в ветке, уже есть хороший список кандидатов.

Если мы оставим этот вопрос открытым, он касается объединения сети и нативного. Предоставление согласованного API между двумя платформами. Я бы хотел, чтобы у меня было время поработать над этим, но у меня его нет, и я сомневаюсь, что это изменится.
Команда @callemall/material-ui хотела бы, чтобы кто-то возглавил эту проблему.

По-прежнему поддерживаю углеродный пользовательский интерфейс :) Я добавляю компоненты только по мере необходимости (не пытаясь заранее заполнить всю спецификацию), но я думаю, что есть хорошая структура, за которую люди могут сплотиться.

• Он автоматически генерирует документы из комментариев к компонентам.
• Есть сайт документации (carbon-ui.com)
• Поддерживает нативные и веб-приложения с одинаковыми компонентами

Поможет любому, кто хочет добавить компоненты :)

@tuckerconnelly Что вы думаете о https://github.com/xotahal/react-native-material-ui? Это не работает в Интернете из-за ошибки с Elevation, но если бы мы применили ваш код https://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.js , я думаю, что это должно сработать. @oliviertassinari правильно

@quangbuule подождите, вы говорите, что мы должны разрабатывать приложения как приложения RN, а затем использовать этот инструмент для преобразования RN в веб-версию?
Я никогда не слышал об этом, но ладно. Но тогда это означает, что мы больше не будем использовать material-ui , а будем использовать вилку RN?

@NitroBAY Мы в основном

Извините за все нубские вопросы, но я попал в ReactLand примерно через неделю.

Вы думаете, что ваш пакет заменит этот?
Ваш подход кажется мультиплатформенным, и поэтому он очень хорош. Material-ui придерживаются только веб-сайтов, потому что у них нет времени, но у них есть время на следующий, почему?
Вы говорите, что next использует изоморфный подход к next но если я возьму любой компонент, то есть бумагу, он будет работать только для Интернета, поскольку есть компонент div .
Кто такие we , ты из этой команды?
Независимо от технических соображений, не думаете ли вы, что использование MD на IOS может раздражать пользователей?

РЕДАКТИРОВАТЬ: не по теме, но мне никто не ответил, какие преимущества дает jss-theme-reactor по сравнению с jss-react ?

@НитроБАЙ :

1. Я не являюсь разработчиком этого проекта или любого другого проекта React Native. Но я наблюдал за этим выпуском в течение нескольких месяцев, и в данный момент я с нетерпением жду возможности внести свой вклад в react-native-material-ui .
2. paper или теневая штука теперь работает в Интернете, iOS, Android. Так что это не имеет большого значения.
3. Ветвь material-ui master использует объекты для определения таблиц стилей, но для повышения производительности (повышение на 30%) участники переключаются на JSS (CSS в JS) в ветке next . На данный момент JSS несовместим с React Native.
4. Google использует Material Design на iOS, и я не думаю, что пользователи сильно возражают. Конечно, вы должны изменить некоторые части, чтобы они соответствовали платформе, такие как изменение цвета строки состояния, использование значка общего доступа iOS и т. д. Я использовал material-ui для своего приложения для Windows 10 и macOS, и я не видел много пользователи жаловались на это (http://moderntranslator.com/). Некоторые даже говорили, что MD проще в использовании.

Но я до сих пор не понимаю, каким образом ветвь next может работать в RN, если компоненты используют элементы HTML, такие как span или div . Возможно, я что-то упустил, но для разработки в RN вам нужно использовать компоненты RN, не так ли?
Я цитирую вас:

она станет официальной версией как для Интернета, так и для нативной. Я думаю, это нормально, учитывая, что material-ui использует аналогичный подход со следующей веткой.

Но может я не правильно понял. Вы имеете в виду, что ветка next позволит нам использовать компоненты в RN?

@NitroBAY : next сделает material-ui менее совместимой с React Native. Кроме того, хотя компонент RN не поддерживает span или div, используя условные правила, вы можете сделать что-то вроде этого:

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

Вы можете проверить: https://github.com/necolas/react-native-web

О, хорошо, я думал, вы имеете в виду, что они сделали RN совместимым.

Является ли TL; DR тем, что этот проект не заинтересован в многоплатформенной поддержке через React Native API, и что усилия должны быть перенесены на https://github.com/xotahal/react-native-material-ui?

Документы для carbon-ui лучше, и он уже работает в Интернете. В чем преимущество react-native-material-ui?

Итак, все согласны с тем, что через некоторое время использование material-ui будет остановлено и рекомендовано? Тогда жаль, что владельцы этого пакета не хотят RN ?

carbon-ui похоже, что у него будут проблемы с производительностью из-за того, что он не использует StyleSheet и внедряет так много веб-шрифтов.

Успокойтесь, ребята! Это все еще идет.

TL;DR: если вы создадите компонент для React Native, он будет работать в RN и в Интернете. Но если вы создадите компонент для Интернета, он не будет работать в RN. И material-ui создан для Интернета, оптимизирован для Интернета => Чтобы заставить его работать в RN, нужно пожертвовать производительностью (по крайней мере, на данный момент). Таким образом, я думаю, что лучше держать два проекта отдельно, пока RN не станет более зрелым.

оптимизирован для Интернета => Чтобы заставить его работать в RN, нужно пожертвовать производительностью (по крайней мере, на данный момент)

У вас есть какие-либо данные, чтобы поделиться об этом?

Вот мои выводы для RNW:

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

@necolas #4066

Хм, я могу изучить возможность использования StyleSheet с Uranium. Я скажу, что не заметил никаких проблем с производительностью, связанных с CSS, но посмотрю, смогу ли я лучше интегрироваться с вашим материалом StyleSheet.

Самый большой удар по производительности приходится на Animated: https://github.com/animatedjs/animated/issues/48. Но это влияет на все приложения RNW.

Внедрение веб-шрифтов существенно снижает производительность? Он загружает их непосредственно из шрифтов Google, поэтому они, скорее всего, уже кэшированы в системе пользователя.

Я думаю, самое главное, чтобы все сплотились вокруг единой библиотеки. И я не думаю, что material-ui будет поддерживать React Native.

@necolas TL; DR заключается в том, что путь вперед неясен .

A = реактивный
Б = сеть

1. Самая ограниченная платформа

Возможный подход состоит в том, чтобы ориентироваться на наиболее ограниченную платформу, поэтому начните с react-native . Затем, чтобы расширить возможности в Интернете. Чтобы расширить функции в Интернете, мы могли бы использовать:

• https://github.com/necolas/react-native-web
• https://github.com/taobaofed/реакт-веб

Однако это связано с компромиссом: мы выиграем совместное использование кода. Но я ожидаю проигрыша в некоторых измерениях.

Внедрение собственного API в Интернет

API необходимо переделать для работы с браузером. Какие накладные расходы?

Обработка отсутствующего веб-API в нативном

Поскольку мы начинаем с наиболее ограниченной платформы, нам нужно будет повторно реализовать некоторые функции, доступные в Интернете. Как насчет медиа-запросов? Наследование CSS, анимация CSS?
Как бы мы реализовали специальные возможности и события клавиатуры, не раздувая нативную версию?

2. Платформа с меньшими ограничениями

Другое решение — начать с менее ограниченной платформы, то есть с Интернета. Затем создайте заново отсутствующие нативные функции.

Однако это связано с компромиссом: мы выиграем совместное использование кода. Но я ожидаю проигрыша в некоторых измерениях.

Приведение веб-API к нативному

Нам придется пойти на жертвы, я ожидаю, что некоторые веб-функции будет очень сложно реализовать на нативном языке, например, медиа-запросы CSS, анимацию CSS. (расширенные правила CSS)

Обработка отсутствующего собственного API в Интернете

Некоторые из отсутствующих функций веб-API связаны с обработкой касаний, прокруткой и просмотром бесконечного списка, собственными компонентами, такими как DatePicker или Drawer.

3. Совместное использование контракта

Третьим решением может быть создание инфраструктуры для совместного использования API и тестов, а затем повторная реализация компонентов на двух базовых платформах. По моему мнению, именно так React Native приближается к iOS и Android.
Затем, используя смешанный подход двух предыдущих, до полного заполнения контракта. Я имею в виду использование ветвления кода, когда это имеет смысл, и совместное использование кода, насколько это возможно.
Например:

• Зачем использовать анимированный.js в браузере, когда мы можем использовать переходы CSS?
• Зачем реализовывать логику Drawer в React-Native, когда мы можем использовать собственный компонент?

Я думаю, что вариант 3. является наиболее перспективным. Именно так я пытался решить проблему в react-swipeable-views .

https://github.com/tuckerconnelly/uranium поддерживает кроссплатформенные медиазапросы :)

Прелесть RN в том, что у вас есть простая библиотека абстрактных API и примитивов, а низкоуровневые реализации позаботятся. Анимация такая же — простая библиотека для анимации, низкоуровневые реализации (собственная анимация на iOS/Android, переходы css в сети).

Я думаю, что animation.js можно было бы использовать для использования переходов css. Наверняка улучшит производительность.

@ quanglam2807 эта ветка очень длинная, на что мне следует обратить внимание?

Чтобы расширить функции в Интернете, мы могли бы использовать: https://github.com/necolas/react-native-web , https://github.com/taobaofed/react-web.

react-web довольно далек от того, чтобы быть эффективным или функционально правильным IMO.

API необходимо переделать для работы с браузером. Какие накладные расходы?

Накладные расходы в каких размерах? Трудно определить с точки зрения размера пакета. Вы, вероятно, сможете удалить часть своего существующего кода; но если бы вы зависели от чего-то помимо основного экспорта RNW, это быстро сложилось бы. В компонентах с большим количеством стилей для mobile.twitter.com я наблюдал уменьшение размера компонента на 20-40% при преобразовании стилей из css-модулей в RNW StyleSheet. С точки зрения производительности во время выполнения, на данный момент он не за горами от css-modules .

Как насчет медиа-запросов?

Вы можете использовать matchMedia для изменения стилей и структуры компонентов, хотя преимущества использования медиа-запросов для изменения компонентов мне не ясны.

Наследование CSS, анимация CSS?

RNW поддерживает анимацию CSS (хотя мне нужно добавить API для определения ключевых кадров). Какой вопрос связан с наследованием CSS?

Как бы мы реализовали специальные возможности и события клавиатуры, не раздувая нативную версию?

Не знаю, что это значит. Я подозреваю, что порог «раздувания» в нативном приложении намного выше, чем в веб-приложении.

поэтому, возможно, сравнение того, как react-native-web обрабатывает стили для рендеринга производительности css, с производительностью css-modules, сейчас менее актуально.

С чего бы это?

Было бы здорово иметь своего рода реактивную нативную сеть, которая использует что-то вроде aphrodite или jss.

Обе эти библиотеки медленнее, крупнее и плохо подходят для предоставления детерминированных стилей.

@necolas material-ui прилагает огромные усилия для перехода от метода css-in-js к методу таблицы стилей (css в <style> ). В течение нескольких месяцев они предпринимали активные усилия по замене компонентов. Причины здесь . Из того, что я прочитал, использование jss является огромным преимуществом и кажется наиболее совершенным решением для управления стилем на данный момент.

Кстати, если еще раз прочитать Roadmap.md, поддержка RN есть в дорожной карте.

Я очень заинтересован в использовании Material-UI с react-native, что-нибудь о прогрессе?

@wswoodruff Вы можете проверить это сейчас - https://github.com/xotahal/react-native-material-ui

На данный момент у нас есть три потрясающие библиотеки для этого:

• набор реактивных материалов ★ 3110 - Приведение материального дизайна в React Native .

• react-native-material-design ★2447 - React Native Material Design Components

• react-native-material-ui ★1040 — Компоненты дизайна материалов с широкими возможностями настройки для React Native.

Наслаждаться!

Есть также менее известный пользовательский интерфейс Carbon, если вы хотите быть универсальным. Но в свое время я бы, вероятно, остановился на одном из них .

это было затронуто пару раз в этой ветке, но я хочу повторить это еще раз из-за того, как это влияет на мой интерес к этому изменению: основное преимущество реактивной поддержки, которое я вижу, на самом деле не связано с реактивной нативностью. , а вместо этого основываться на примитивах, которые позволяют использовать одни и те же компоненты как в нативной, так и в веб-версии.

если бы использовался этот тип примитива, другие инструменты, такие как react-sketchup и react-pdf, также могли бы быть включены.

лично мне они более интересны, чем родные, но будут включены те же изменения.

@jhabdas Каков

@deadcoder0904 еще не использовал его лично. возможно, попробуйте связаться с одним из парней на бесконечном красном. они ведут информационный бюллетень RN и должны быть экспертами в предметной области. если и когда я создам еще одно приложение RN (хорошо, когда...), на этот раз я не буду собирать вещи вместе или создавать еще один шаблон — ИМХО, пространство решается существующими шаблонами и компонентами .

Вот некоторые из препятствий, которые, как мне кажется, необходимо преодолеть, чтобы сделать MUI доступным в React Native. Предполагая, что MUI v1 и мы сохраняем JSS, шаблон classes и другие вещи, которые на данный момент являются ключевыми частями дизайна API MUI.

• 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, я думаю, что дальновидным решением было бы использовать новый API веб-анимации и потребовать для него полифилл.
  Другими словами, я думаю, что есть место для создания новой библиотеки для обработки анимации в React, которая использует веб-анимацию в браузере и Animated API в React Native и представляет собой общее улучшение по сравнению с тем, как 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% понимаю последствия для производительности. Но мы могли бы использовать новый контекстный API React 16.3 и выставить <MuiText>Text</MuiText> . В основном компоненты MUI, такие как Button будут иметь поставщиков, которые будут предоставлять информацию о стилях текущего контекста (шрифт, цвет текста и т. д.), а MuiText просто будет использовать эти данные и применять их к элементу Text.
  
  

Сегодня вышла v1, так какие планы у React Native❓

Для поддержки материалов React Native существует прекрасная библиотека под названием React Native Paper, которая будет поддерживаться и поддерживаться командой CallStack.

Но есть ли планы портировать это на React Native, потому что я думаю, что Paper прекрасно работает❓

Если нет, то, вероятно, вы можете закрыть эту тему :)

Спасибо, что поделились @deadcoder0904. Я добавил Paper в Awesome React Components . Не слышал о CallStack. Сначала я прочитал это как Call-Em-All. Угадай, что они не те же взгляды, а?

@jhabdas Нет, они

@dantman Вот мои мысли о том, как добиться нативной поддержки.

• если придерживаться jss не является абсолютным требованием, я думаю, что fela является жизнеспособной альтернативой:
  
  
  
  • fela-native поддерживает медиа-запросы и правильно использует
  
  
  • Он безумно расширяемый . Мы могли бы переписать правила для веб-ресурсов на их собственные прокси-серверы, удалить такие вещи, как правила :hover в нативных и, возможно, восстановить синтаксис, потерянный из jss.
  
  
• У react-native-animatable есть поддержка ключевых кадров, и, вероятно, его можно было бы использовать вместо группы перехода, которая может работать или не работать с native .
• Я согласен с ниспровержением некаскадного взгляда на реактивность. Это может быть подписка у поставщика и потребителя с реквизитами cascade и inherit .
  Каждая нативная библиотека, с которой я пытался работать, была болезненной или непригодной для использования из-за чрезмерно жесткого API и непереопределяемых стилей, за исключением тех, которые используют @shoutem/theme для разрешения переопределений (например, нативная база) .

Все еще жду этой поддержки. Красиво использую в Интернете, но я разрабатываю и для мобильных устройств!

какие-либо обновления о поддержке реакции родной?

@oliviertassinari Я намерен разветвиться и начать изучать путь реализации, который я описал выше. Моим приоритетом будет получение компонентов, которые мне нужны для работы другого проекта, поэтому я, вероятно, не буду в ближайшее время рекламировать надежную поддержку React Native, но я постараюсь держать ее «синхронизированной» с мастером, насколько это возможно. в надежде, что однажды это будет полезно (или, возможно, объединено)

@micimize Спасибо, что

Обновление по этому поводу: мы перевели значительную часть функциональности в несколько пригодное для использования состояние, включая списки, кнопки, карточки, значки, элементы управления выбором, текстовые поля и фон. К сожалению, как только мы наконец приступили к разработке самого приложения на React Native, возникло множество проблем, которые вынудили нас перейти на Flutter.

В какой-то момент я хотел бы вернуться и сохранить часть проделанной нами работы, в основном порт решения для стилей withStyles / classes котором использовались css-сокращения-свойства и некоторые другие полезные вещи, однако это больше не является приоритетом. для меня.

@rogerstorm профинансировал этот выпуск на 200 долларов. Смотрите на IssueHunt

Работа над проблемой была бы альтернативной стоимостью для нас. Я закрываюсь. Мы удвоим усилия по улучшению поддержки вариантов использования браузера.

@oliviertassinari , означает ли это, что нативная поддержка реакции выходит за рамки и в ближайшем будущем (например, через 1 год) ее не будет на радарах?

да

https://github.com/lightningtgc/react-native-material-ui Это не что иное, как очередной мошеннический пакет npm