Material-ui: 리액트 네이티브 지원

이 리포지토리를 방금 발견했습니다: 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,
      }
})

지인덱스 솔루션

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 (반작용 기본 사용 object 대신 string ) mixins/style-propable.jsx 우리는 여러 브라우저 등을 처리 할 필요가 없기 때문에

https://github.com/lenaten/material-ui-native 에서 react-native로 WIP 분기를 게시했습니다
현재는 카드와 RaiseButton만 작동하지만 스타일은 없습니다(WIP 기억하시나요?)

@lenaten 재미있다!
또한 이 프로젝트와 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>
  }
}

앱 바.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 저도 "파일 확장자" 모델이라는 아이디어를 좋아합니다. 지금 나에게 가장 중요한 것은 기본 구성 요소를 작동하는 것입니다. 코드 추상화를 돕고 싶다면 환영합니다. 나는 repo 이름에서 "네이티브"접미사를 제거하기로 약속합니다. :)

@lenaten 은 material-ui-native가 tcomb-form-native와 호환됩니다. 그렇지 않다면 얼마나 큰 프로젝트가 될까요?

@mvayngrib 한동안 이 프로젝트 작업을 중단했습니다..

@lenaten 죄송 합니다 답변해주셔서 감사합니다

좋아, 나는 https://github.com/callemall/material-ui/pull/2611 에서 작업을 시작했습니다
시간이 좀 걸립니다!

@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 우리는 그것을 듣게되어 기쁩니다.
여기 #3829에서 react-look을 사용하고 있습니다. 내가 가진 유일한 문제는 사소한 문제입니다. React Native는 StyleSheet API의 잘못된 사용에 대한 경고를 표시합니다. 자세히 살펴보진 않았지만 해결될 수 있을 거라 믿습니다.

@oliviertassinari @dorthwein 이 노력( material-ui 을 react-native 가져옴)이 죽지 않았다는 사실에 기쁩니다 . 이 스레드에서 언급되지 않은 또 다른 새로운 material-ui to react-native 프로젝트가 있음을 지적하고 싶었습니다. https://github.com/react-native-material- design/react-native-material-design . 해당 프로젝트는 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 파일을 생성하지 않습니다. 여기에서 무슨 일이 일어나고 있는지 알 수 없었습니다.
• 기존 material-ui 저장소 위에 작동하는 반응 네이티브 앱을 얻을 수 없는 것 같습니다. 이 분야에서 운이 좋은 사람이 있으면 기본 구성 요소 집합을 기여/개발하는 방법을 안정적으로 얻을 수 있습니다.

@dorthwein 피드백 주셔서 감사합니다. 반응 네이티브 브랜치는 고도로 실험적입니다. 우리는 이것을 해결해야 합니다.
반면에 저는 문제가 없습니다(https://github.com/callemall/material-ui/pull/3829).
새로운 git clone 에서 시작해야 합니다.

네, 현재 프로젝트의 다음 단계는 머티리얼 디자인을 사용하는 모바일 앱에서 작업하는 것입니다. 우리의 모든 웹 항목도 여기에 있으므로 이것을 사용하고 싶습니다. 작업 환경을 확보할 수 있다면 프로젝트와 함께 작업 환경을 종료할 것입니다.

몇 가지 정보를 읽고 FB React 기본 페이지에서 이 간단한 정보를 확인했습니다.

"UI 구축을 위한 가장 기본적인 구성 요소인 View는 flexbox, 스타일, 일부 터치 처리 및 접근성 컨트롤이 있는 레이아웃을 지원하는 컨테이너이며 다른 뷰 내부에 중첩되고 모든 유형의 자식이 0개 이상 있도록 설계되었습니다. UIView이든 상관없이 React가 실행되는 플랫폼에 상관없이 기본 보기에 직접 매핑됩니다.

이 리소스도 찾았습니다. 지금 사용해 보세요. 꽤 직선적이며 한 번 살펴볼 가치가 있는 것 같습니다.

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

@dorthwein 좋은 생각입니다! 하지만 우리가 이 길을 간다면 React Native 전용 버전을 개발하는 것이 더 나을 것이라고 생각합니다.

네이티브 및 DOM에 대한 별도의 코드 대신 React 네이티브 API에서 전체 프로젝트를 다시 작성할 수 있습니다. 놀라운! 나는 이것에 대해 생각해 본 적이 없습니다.

@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를 사용합니다.

그러면 프로세스는 각 구성 요소의 기본 버전을 작성하는 대신 h1 및 레이블과 같은 항목을 사용하는 대신 div 및 스타일 텍스트 대신 보기를 사용하도록 기존 버전을 변환해야 합니다.

확실히 작은 작업은 아니지만 프로세스는 여러 버전을 만들고 유지 관리하는 대신 기존 구성 요소를 업데이트합니다.

그러면 프로세스는 각 구성 요소의 기본 버전을 작성하는 대신 h1 및 레이블과 같은 항목을 사용하는 대신 div 및 스타일 텍스트 대신 보기를 사용하도록 기존 버전을 변환해야 합니다.

그것은 브라우저에서도 작동하는 네이티브 버전을 작성하는 것과 정확히 같습니다. 내가 아는 한 react-native-web 는 웹에 기본 반응을 가져오고 그 반대는 아닙니다.
그래도 동일한 코드를 공유하는 것은 정말 편리할 수 있습니다 :+1:.
나는 지금까지 이 lib에 대한 하나의 작은 문제를 보았습니다. 그들의 StyleSheet.create 구현은 동적 값을 지원하지 않습니다(muiTheme에 필요함). 이 사용 사례에 대해 반응 보기를 사용할 수 있습니다.

@oliviertassinari 당신의 권리 - 나는 그것을 거꾸로 이해하고있었습니다. 1단계는 여전히 컴포넌트의 반응 네이티브 버전을 구축하는 것 같습니다. 2단계는 잠재적으로 반응 네이티브 웹과 같은 것을 사용하여 단일 코드 기반으로 병합하는 것입니다.

@wordyallen : 잘생김 👍

@pgangwani 이제 막 했는데 ... 아직 준비가 안됐어.

나는 격차를 채우기 위해 https://github.com/react-native-material-design/react-native-material-design 을 사용했지만 가장자리 주변도 매우 거칠고 적극적인 개발이 없습니다.

할 수만 있다면 이 노력에 재정적으로 기부할 것입니다.

안녕하세요 여러분,

저는 이 라이브러리에서 영감을 받은 react-native-material-ui 에서 작업합니다. 자유롭게 시도하십시오 - 피드백을 듣고 싶습니다 ;)

@xotahal et. al, IMHO는 처음부터 새로 만드는 대신 이 라이브러리를 포크하고 기존 구성 요소를 다시 만드는 대신 이식하는 것입니다. 나에게 묻는다면 재료 스타일 입력의 필요성은 RN 공간에서 절실히 필요합니다. OSS 노력에 감사드립니다.

일반적인 코드는 많지 않다고 생각합니다. 처음부터 만드는 것이 합리적이라고 생각합니다. RN의 스타일링은 이것과 90% 다릅니다. 그리고 애니메이션과 같은 플랫폼별 메커니즘이 꽤 있습니다...

구성 요소 구조, 소품(및 문서)을 채택하고 많은 변경 사항이 있더라도 명확한 업스트림을 갖는 것은 웹에서 네이티브로 앞뒤로 이동하는 사람들에게 장기적으로 유익할 것이며 가장 중요합니다. 나머지는 구현 세부 사항이 됩니다.

@jhabdas에 동의합니다. API가 각 구성 요소를 더 유사하게 찾을수록 개발자가 웹 프로젝트와 기본 프로젝트에서 전환하는 것이 덜 거슬리게 됩니다. 덜 거슬리는 경험일수록 더 생산적일 수 있습니다. 플랫폼별 세부 정보가 구성 요소의 배후에서 추상화되기를 기대합니다.

@chadobado 또는 유지 관리자, 이

FWIW, 이것이 내 눈을 사로 잡았습니다.

react-native-material-kit 에 대한 웹 지원의 @necols :

React Native의 웹 구현에서 호환성으로 Stylesheet가 제공된다면 많은 것을 이식할 필요가 없을 것입니다.

@jhabdas 네이티브 반응으로 조금 플레이하면 그렇게 간단하지 않다는 것을 알 수 있습니다. StyleSheet API는 훌륭하지만 꽤 많은 것을 다시 작성해야 합니다 ;)

페어 포인트 @antoinerousseau. 저는 RN에 대한 James Long의 인용문을 계속 생각합니다.

웹의 다른 방향을 위한 프로토타입으로 생각하십시오.

@necolas 라이브러리의 목적을 이해하고 있다면 문제를 역전시키는 것이 제정신인 접근 방식인 것 같습니다. CSS를 RN으로 이식하는 대신 RN에서 전체를 재구축하고 shim을 사용하여 웹용 백 포트를 백포트합니다. 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 그래서 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 지점 작업 준비로 인해 차단되어 있습니까?

그리고 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 를 가져와서 반복하고 전체 목록을 하나의 큰 개체로 내 보내야 했습니다.

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 가져오기 규칙과 호환되도록 pull 요청을 해야 합니까?

@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 구성 요소가 스타일을 제어하는 ​​props를 전달할 수 있는 한, 우리는 황금색이라고 생각합니다.

material-ui 는 미디어 쿼리를 수행합니까? 우리는 할 필요가 있습니까?

복잡한 테마 솔루션을 어떻게 처리합니까?

React Native에서 지원되지 않는 소품을 생략하거나 이름을 바꾸도록 Platform 을 확인할 수는 없습니다. (메모리가 제대로 제공되는 경우) 패딩과 여백이 기본적으로 React Native에서 반대이기 때문입니다. 우리가 해야 할 일은 createStyleSheet 상응하는 메소드를 래핑하여 결과를 "웹" 플랫폼이 아닌 특정 호환 가능한 스타일로 변환/필터링하는 것입니다.

아직 써보지는 않았지만

나는 또한 그것을 사용하지 않았지만 react-tunnel 와 같은 것이 테마 컨텍스트에 좋은 것 같습니다. 커뮤니티에서 더 많이 공유할 수 있다고 느끼기 때문에 다시 사용하고 노출할 수 있습니다. 더 인기 있는 동등물이 있을 수 있습니다.

얼마나 많은 react-native-web이 프로덕션 준비가 되어 있습니까? 예를 들어 육안 테스트를 본 적이 없습니다.

여기에 대화형 예제가 있습니다: https://necolas.github.io/react-native-web/storybook/

미디어 쿼리를 어떻게 처리합니까?

JavaScript에서 matchMedia (또는 Dimension )하여 렌더링할 스타일과 구성 요소를 결정합니다.

플랫폼 간 앵커 태그 href 구성요소가 누락되었습니다.

예, "적절한" 솔루션이 무엇인지 잘 모르겠지만 지금은 View 및 Text 같은 링크를 사용할 수 있습니다(물론 웹 지원만 가능).

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

복잡한 테마 솔루션을 어떻게 처리합니까?

React Native는 이 작업을 수행하는 방법을 신경 쓰지 않습니다. 여전히 context 를 사용하여 적용할 스타일 개체를 결정할 수 있습니다. 나는 Fela의 컴포넌트 내 API를 상당히 좋아하지만 react-native-web 을 사용한다면 구현 및 플러그인 API가 과도하게 보입니다.

우리가 해야 할 일은 createStyleSheet 등가 메서드를 래핑하여 결과를 "웹"이 아닌 플랫폼별 호환 가능한 스타일로 변환/필터링하는 것입니다.

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 중에서 선택하려면 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' 를 사용하여 원래 코드를 본질적으로 유지하게 될 것이라고 생각합니다. 내가 작업하고 있는 웹사이트 이식을 마치면 변경되지 않습니다. 그 시점에서 내가 개인적으로 필요로 하는 것만이 불완전하게 이식될 것입니다.

나는 Mac과 Windows 컴퓨터 사이를 이동하기 위해 밀어붙이기 때문에 (나중에 다룰 때까지) 완전히 엉망입니다.

MUI가 RN에 올 때까지 기다릴 수 없는 사람들을 위해 대안이 있습니다. 나는 여기에 상록수 목록을 유지하고 있습니다: https://habd.as/awesome-react-components/#react -native

전체 스타일링 솔루션이 변경되고 있다는 것을 알고 있었지만 라이브러리가 처음부터 다시 작성되는 부분을 놓쳤습니다. 그건 내 잘못이야. 일부 코드를 보고 최종 스타일은 본질적으로 동일하게 유지되고 기술만 변경될 것이라고 가정했습니다. 내가 틀렸어. 로드맵을 완전히 무시하지 않고 매우 잘못된 가정을 했습니다. 나는 여기서 나의 시도를 포기해야 할 것 같다.

@mattferrin 스타일 솔루션 변경에는 많은 API 변경이 필요하지만 처음부터 완전히 Table ). 하지만 추가로 많은 구성 요소에 대해 다른 영역에서 API를 합리화할 수 있는 기회를 제공합니다. . 귀하의 노력이 낭비되었다면 죄송합니다. Material-UI가 지연되지 않기를 바랍니다!

@mbrookes 그렇지 않습니다. 나는 떨어져 분기의 실수했다 master 대신 next 와의 차이 (그리고 일반적으로 전체 작업)을 과소 평가합니다. 내 잘못이었고 위험이 있다는 것을 알고 있었습니다. 나중에 React Native material-ui 파사드에서 빈 Text 요소를 자리 표시자로 반환할 것입니다. 내 웹 사이트를 react-native-web 완전히 이식하면 다시 돌아와 next 새 변경 사항을 리베이스하려고 시도합니다.

오늘 이 녀석을 공개합니다: https://carbon-ui.com

material-ui에서 영감을 받아 웹 및 반응 네이티브에서 작동합니다. :)

@tuckerconnelly u made my day

@tuckerconnelly 와우, 이 프로젝트의 많은 잠재력이... 수고했습니다! 더 큰 커뮤니티가 이 노력의 배후에서 결집하기를 희망합니다! 🍻

@tuckerconnelly 조금 혼란 스럽습니다. 나는 그것을 만들기 위해 아주 쉽게 실제로 발견 material-ui (오프 분기의 내 실수에도 불구하고 조건부 크로스 플랫폼을 master 대신 next 내 시간을 낭비). 독립 프로젝트에 어떤 이점이 있는지 궁금합니다.

2월에 다시 시도했는데 특히 리플 구성 요소와 플랫폼 간 미디어 쿼리로 인해 어려움을 겪었습니다.

때로는 처음부터 시작하는 것이 더 쉽습니다.

나에게 React Native에서 작동하지 않는 React 구성 요소를 갖는 것은 의미가 없습니다 ... 그리고 material-ui의 개발자는 RN을 우선 순위로 생각하지 않았기 때문에 ... 새로운 경로에서 시작하는 것이 공정하고 논리적입니다.

@tuckerconnelly 구성 요소가 구현되는 방식이 중요하지 않다고 생각합니다. 두 프로젝트가 구성 요소에 대해 동일한 API를 구현하고 동일한 이름에 동의하기를 바랍니다. 이 작업을 수행하고 공유하게 되어 기쁩니다.

따라서 v1.0.0 이후의 2017/2018년에는 RN이 material-ui의 다음 목표가 될까요?

에서 볼 수 있듯이:

• v1에 대한 커뮤니티 참여
• RN 지원을 원하는 사람들의 수
• 많은 프로젝트가 Material-ui를 기반으로 하거나 영감을 받아 RN 구성 요소를 제공한다는 사실
• 이 모든 것을 통해 얻은 경험과 이 호가 공개된 후 많은 시간이 흘렀다는 사실

(아마도 v1 출시 이후에) RN 구성 요소를 제공하는 프로젝트를 시작한다면 많은 사람들이 당신을 도울 것입니다. 명확한 경로를 시작하고 정의하기만 하면 됩니다. 당신은 훌륭한 커뮤니티를 가지고 있습니다. 그것을 사용하여 최고의 제품을 만들 수 있습니다.

@NitroBAY 1.0은 스타일링을 위해 JS 개체 대신 JSS를 사용하므로 React Native를 지원하기 위해 cssinjs/jss#368에 의존합니다. 하지만 https://github.com/xotahal/react-native-material-ui 와 같은 React Native용 병렬 버전을 개발하는 것이 더 낫다고 생각합니다 https://github.com/necolas/react-native-web을 사용하여 웹에서 React Native 버전을 실행할 수 있습니다.

그래서 이것은 고칠 수 없는 것입니까? 그렇다면 태그를 그렇게 지정할 수 있습니까?

@jhabdas 재질 사양을 React Native로 가져오는 좋은 라이브러리를 보고 싶습니다.
스레드에 게시된 링크에서 이미 좋은 후보자 목록이 있습니다.

우리가 그 문제를 열어두고 있다면 그것은 웹과 네이티브를 통합하는 것에 관한 것입니다. 두 플랫폼 간에 일관된 API를 제공합니다. 그것에 대해 작업할 시간이 있었으면 좋겠지만 그렇지 않으며 변경될지 의심스럽습니다.
@callemall/material-ui 팀은 누군가가 그 문제를 주도하는 것을 보고 싶습니다.

여전히 carbon-ui를 지원합니다. :) 필요할 때만 구성 요소를 추가하지만(전체 사양을 미리 채우려고 하지 않음), 사람들이 모여들 수 있는 좋은 프레임워크가 있다고 생각합니다.

• 구성 요소 주석에서 문서를 자동 생성합니다.
• 문서 사이트 있음(carbon-ui.com)
• 동일한 구성 요소로 기본 및 웹 지원

구성 요소를 추가하려는 사람에게 도움이 될 것입니다. :)

@tuckerconnelly https://github.com/xotahal/react-native-material-ui 에 대해 어떻게 생각 https://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.js 코드를 적용했다면 제 생각에는 작동 할 것이다. @oliviertassinari 는 함께 작업할 주요 프로젝트를 결정해야 한다는 점을 잘 지적합니다.

@quangbuule 잠깐만요. 앱을 RN 앱으로 개발한 다음 해당 도구를 사용하여 RN을 WEB 버전으로 변환해야 한다고 말씀하십니까?
나는 그것에 대해 들어본 적이 없지만 괜찮습니다. 그러나 그것은 우리가 더 이상 material-ui 하지 않고 RN 포크를 더 많이 사용한다는 것을 의미합니다.

@NitroBAY 우리는 기본적으로 material-ui를 RN 포크로 이식하고 준비가 되면 웹과 네이티브 모두의 공식 버전이 될 것이라고 생각합니다. material-ui가 다음 브랜치에서 비슷한 접근 방식을 사용하고 있다는 점을 고려하면 괜찮다고 생각합니다.

모든 멍청한 질문에 대해 죄송하지만 약 1 주 이후로 ReactLand 착륙했습니다.

귀하의 패키지가 이 패키지를 대체할 것이라고 생각하십니까?
당신의 접근 방식은 다중 플랫폼으로 보이며 매우 좋습니다. Material-ui는 시간이 없기 때문에 웹만 고집하지만 다음에는 시간이 있습니다. 그 이유는 무엇입니까?
next next 에 동형 접근 방식을 사용한다고 말하지만 종이 와 같은 구성 요소를 사용하면 div 구성 요소가 있으므로 웹에서만 작동합니다.
we 은(는) 누구입니까? 이 팀의 일원입니까?
기술적인 고려 사항에 관계없이 IOS에서 MD를 사용하는 것이 사용자를 귀찮게 할 수 있다고 생각하지 않습니까?

편집: 주제에서 벗어났지만 아무도 대답하지 않았습니다. jss-react 와 비교할 때 jss-theme-reactor 는 어떤 이점을 가져옵니까?

@니트로베이 :

1. 저는 이 프로젝트나 React Native 프로젝트의 개발자가 아닙니다. 하지만 저는 이 문제를 몇 달 동안 지켜보았고 현재로서는 react-native-material-ui 기여하기 시작하기를 고대하고 있습니다.
2. paper 또는 그림자가 이제 웹, iOS, Android에서 작동합니다. 그래서 그것은 큰 문제가 아닙니다.
3. material-ui master 분기는 개체를 사용하여 스타일시트를 정의하지만 성능 향상(30% 향상)을 위해 기여자는 next 분기에서 JSS(JS의 CSS)로 전환합니다. 현재 JSS는 React Native와 호환되지 않습니다.
4. Google은 iOS에서 Material Design을 사용하며 사용자가 크게 신경 쓰지 않는다고 생각합니다. 물론 상태 표시줄 색상 변경, iOS 공유 아이콘 사용 등 플랫폼에 맞게 일부 부분을 수정해야 합니다. Windows 10 및 macOS 앱에 material-ui 를 사용했는데 많이 보지 못했습니다. 사용자들은 그것에 대해 불평했습니다(http://moderntranslator.com/). 일부에서는 MD가 사용하기 더 쉽다고 말하기까지 했습니다.

그러나 구성 요소가 span 또는 div 와 같은 HTML 요소를 사용하는 경우 next 분기가 RN에서 작동하는 방식을 여전히 이해하지 못합니다. 내가 놓친 것이 있을 수 있지만 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과 호환되도록 만들었다는 것을 의미한다고 생각했습니다.

이 프로젝트가 React Native API를 통한 다중 플랫폼 지원에 관심이 없고 그 노력을 https://github.com/xotahal/react-native-material-ui 로 옮겨야 한다는 TL;DR

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 = 반응 네이티브
B=웹

1. 가장 제약이 많은 플랫폼

가능한 접근 방식은 가장 제한된 플랫폼을 대상으로 하여 react-native 에서 시작하는 것입니다. 그런 다음 기능을 웹으로 확장합니다. 기능을 웹으로 확장하기 위해 다음을 사용할 수 있습니다.

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

그러나 그것은 절충점과 함께 제공되며, 우리는 코드 공유에서 승리할 것입니다. 그러나 나는 어떤 차원에서 잃을 것으로 예상하고 있습니다.

네이티브 API를 웹으로 가져오기

API는 브라우저에서 작동하도록 다시 구현해야 합니다. 오버 헤드는 무엇입니까?

네이티브에서 누락된 웹 API 처리

가장 제한된 플랫폼에서 시작할 때 웹에서 사용 가능한 일부 기능을 다시 구현해야 합니다. 미디어 쿼리는 어떻습니까? CSS 상속, CSS 애니메이션?
네이티브 버전을 부풀리지 않고 누가 접근성 및 키보드 이벤트를 구현할까요?

2. 제약이 덜한 플랫폼

또 다른 솔루션은 덜 제한된 플랫폼, 즉 웹에서 시작하는 것입니다. 그런 다음 누락된 기본 기능을 다시 구현합니다.

그러나 그것은 절충점과 함께 제공되며, 우리는 코드 공유에서 승리할 것입니다. 그러나 나는 어떤 차원에서 잃을 것으로 예상하고 있습니다.

웹 API를 네이티브로 가져오기

우리는 희생해야 합니다. 예를 들어 CSS 미디어 쿼리, CSS 애니메이션과 같은 일부 웹 기능은 네이티브에서 구현하기 정말 어려울 것으로 예상됩니다. (고급 CSS 규칙)

웹에서 누락된 네이티브 API 처리

누락된 웹 API 기능 중 일부는 터치 처리, 스크롤 및 무한 목록 보기, DatePicker 또는 Drawer와 같은 기본 구성 요소와 관련된 것입니다.

3. 계약 공유

세 번째 솔루션은 API 및 테스트를 공유하는 인프라를 설정한 다음 두 개의 기본 플랫폼에서 구성 요소를 다시 구현하는 것입니다. 내 인식에 따르면 반응 네이티브 가 iOS 및 Android에 접근하는 방식입니다.
그런 다음 이전 두 가지 방법을 혼합하여 사용하여 계약을 완전히 채웁니다. 의미가 있을 때 코드 분기를 사용하고 가능한 한 코드를 공유합니다.
예를 들어:

• CSS 전환을 사용할 수 있는데 왜 브라우저에서 animation.js 를 사용합니까?
• 네이티브 컴포넌트를 사용할 수 있는데 왜 react-native 에 Drawer 로직을 구현해야 할까요?

나는 그 옵션 3이 가장 유망하다고 생각합니다. 이것이 내가 react-swipeable-views 에서 문제를 해결하려고 시도한 방법입니다.

https://github.com/tuckerconnelly/uranium은 플랫폼 간 미디어 쿼리를 지원합니다. :)

RN의 장점은 추상 API 및 프리미티브의 간단한 라이브러리가 있고 저수준 구현이 처리된다는 것입니다. Animated는 동일합니다. 애니메이션을 위한 간단한 라이브러리, 저수준 구현(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의 스타일이 많은 구성 요소에서 CSS 모듈에서 RNW StyleSheet로 스타일을 변환하는 구성 요소 크기가 20-40% 감소하는 것을 보았습니다. 런타임 성능 측면에서 현재 css-modules 와 멀지 않습니다 .

미디어 쿼리는 어떻습니까?

matchMedia 를 사용하여 스타일과 구성 요소 구조를 변경할 수 있지만 미디어 쿼리를 사용하여 구성 요소를 변경하는 이점이 명확하지 않습니다.

CSS 상속, CSS 애니메이션?

RNW는 CSS 애니메이션을 지원합니다(키프레임을 정의하려면 API를 추가해야 함). CSS 상속과 관련된 질문은 무엇입니까?

네이티브 버전을 부풀리지 않고 접근성 및 키보드 이벤트를 구현하려면 어떻게 해야 합니까?

이것이 무엇을 의미하는지 확실하지 않습니다. 기본 앱의 "팽창" 임계값이 웹 앱보다 훨씬 높다고 생각합니다.

따라서 react-native-web이 스타일을 처리하여 CSS 성능을 CSS 모듈 성능으로 렌더링하는 방법을 비교하는 것은 이제 덜 적절할 것입니다.

왜 그럴까요?

aphrodite 또는 jss와 같은 것을 사용하는 일종의 react-native-web이 있으면 좋을 것입니다.

두 라이브러리 모두 느리고 크기가 크며 결정적 스타일을 제공하는 데 적합하지 않습니다.

@necolas material-ui 는 css-in-js 방식에서 스타일시트 방식(css in <style> )으로 전환하기 위해 많은 노력을 기울이고 있습니다. 그들은 구성 요소를 전환하기 위해 몇 달 동안 적극적인 노력을 기울였습니다. 이유가 여기에 있습니다 . 내가 읽은 바에 따르면 jss를 사용하는 것은 큰 이점이며 지금까지 스타일을 처리하는 가장 완벽한 솔루션인 것 같습니다.

그건 그렇고 Roadmap.md를 다시 읽으면 RN 지원이 로드맵에 있습니다.

반응 네이티브와 함께 Material-UI를 사용하는 데 매우 관심이 있습니다. 진행 상황에 대해 말씀해 주시겠습니까?

@wswoodruff 지금은 이것을 확인할 수 있습니다 - https://github.com/xotahal/react-native-material-ui

현재 이를 위한 세 가지 멋진 라이브러리가 있습니다.

• react-native-material-kit ★3110 - React Native에 머티리얼 디자인 가져오기 .

• react-native-material-design ★2447 - React Native Material 디자인 컴포넌트

• react-native-material-ui ★1040 - React Native를 위한 고도로 사용자 정의 가능한 머티리얼 디자인 구성 요소입니다.

즐기다!

보편적으로 가고 싶다면 덜 알려진 Carbon UI 도 있습니다. 그러나 내 시간 동안 나는 아마 이것들 중 하나를 고수할

이 스레드에서 몇 번 언급했지만 이 변경 사항에 대한 내 관심에 영향을 미치기 때문에 다시 언급하고 싶습니다. 내가 보고 있는 반응 네이티브 지원의 주요 이점은 실제로 반응 네이티브에 관한 것이 아닙니다. , 그러나 대신 동일한 구성 요소를 네이티브 및 웹 _모두_에서 사용할 수 있도록 하는 기본 요소를 기반으로 하는 것입니다.

해당 유형의 프리미티브가 사용된 경우 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를
• hacky wrapper 또는 babel 변환이 없다고 가정하면 classes 패턴을 보강해야 동일하게 작동하지만 RN에서 대신 style 배열을 전달해야 한다는 사실을 설명합니다. , 그리고 아마도 styles 로 이름을 지정해야 합니다. 아마도 이것은 classnames 를 삭제하고 무대 뒤에서 클래스/className 처리와 스타일/스타일 사이를 전환하는 확산 가능한 도우미를 추가하여 처리할 수 있습니다.
  아마도:
  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 Animations를 사용하고 React Native에서 Animated API를 사용하는 React에서 애니메이션을 처리하기 위한 새로운 라이브러리를 만들 여지가 있으며 MUI가 애니메이션을 처리하는 방식에 대한 일반적인 개선이라고 생각합니다.
• MUI는 계단식 동작을 사용할 수 있다는 기대를 버려야 합니다. 그리고 하위 트리 내에서 테마 수정 사항을 쉽게 적용할 수 있도록 테마 설정을 개선해야 합니다.
  현재 AppBar + 아이콘과 같은 기능은 텍스트 색상을 설정하고 명시적 color='inherit'를 사용하고 색상이 계단식으로 내려갈 것이라고 가정하여 작동합니다. 그리고 이것은 MUI의 다른 부분에서도 동일할 수 있습니다.
  React Native에는 이와 같은 캐스케이딩이 없습니다. 대신 각 보기에 대해 스타일을 명시적으로 선언해야 합니다. 이러한 유형의 경우 AppBar 및 기타 구성 요소는 해당 컨텍스트 내에서 테마를 dark 하여 아이콘이 올바른 대조 아이콘을 갖도록 수정된 테마의 수정된 버전을 쉽게 제공할 수 있어야 합니다. 색상(텍스트 색상 대신 실제 아이콘 색상 사양을 기반으로 할 수 있음). 이는 앱 바에 중첩된 메뉴와 같은 사항에 영향을 미칠 수 있습니다.
• 이 계단식 문제의 확장으로. MUI는 또한 <Button>Text</Button> 와 같은 것들을 중심으로 설계되었습니다. 여기서 MUI는 버튼 루트의 fontFace/color 등의 스타일을 지정할 수 있다고 가정합니다. 요소와 텍스트 노드의 혼합과 텍스트 노드는 올바른 스타일을 얻습니다.
  이것은 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의 경우 CallStack 팀에서 유지 관리 및 지원하는 React Native Paper 라는 아름다운 라이브러리가 있습니다.

하지만 Paper가 완벽하게 작동한다고 생각하기 때문에 이것을 React Native로 이식할 계획이 없습니다❓

그렇지 않은 경우 이 문제를 닫을 수 있습니다. :)

@deadcoder0904를 공유해 주셔서 감사합니다. Awesome React Components 에 Paper를 추가했습니다. CallStack에 대해 들어본 적이 없습니다. 처음에는 Call-Em-All로 읽었습니다. 같은 친구들이 아닌 것 같죠?

@jhabdas 아니 그들은 동일하지 않습니다

@dantman 다음은 기본 지원을 달성하는 가장 좋은 방법에 대한 제 생각입니다.

• jss를 고수하는 것이 절대적인 요구 사항이 아닌 경우 fela 가 실행 가능한 대안이라고 생각합니다.
  
  
  
  • fela-native는 미디어 쿼리를 지원하고 StyleSheet.create를 적절하게 사용합니다.
  
  
  • 그것은 엄청나게 확장 가능 합니다. 웹 속성에 대한 규칙을 반응 네이티브 프록시에 다시 작성하고 네이티브에서 :hover 규칙과 같은 것을 제거하고 jss에서 손실된 구문을 다시 얻을 수 있습니다.
  
  
• react-native-animable 은 키프레임을 지원하며 아마도 transition-group 대신 사용할 수 있습니다 .
• 나는 반응 네이티브에 대한 계단식 없는 관점을 뒤집는 데 동의합니다. cascade 및 inherit 소품으로 공급자와 소비자에게 옵트인할 수 있습니다.
  내가 작업하려고 시도한 모든 반응 네이티브 라이브러리는 재정의를 허용하기 위해 @shoutem/theme 를 사용하는 것을 제외하고 지나치게 엄격한 API와 재정의할 수 없는 스타일 때문에 고통스럽거나 사용할 수 없었습니다(예: 기본 기반) .

아직 이 지원을 기다리고 있습니다. 웹에서도 멋지게 사용하지만 모바일에서도 개발합니다!

네이티브 반응 지원에 대한 업데이트가 있습니까?

@oliviertassinari 위에서 설명한 구현 경로를 분기하고 탐색을 시작하려고 합니다. 내 우선 순위는 다른 프로젝트에 필요한 구성 요소를 작동시키는 것이므로 곧 강력한 React Native 지원을 PR하지 않을 것이지만 가능한 한 마스터와 "동기화"되도록 노력할 것입니다. 언젠가는 유용할 것입니다(또는 병합될 수 있음).

@micimize 알려 주셔서 감사합니다. 이 프로젝트에서 행운을 빕니다! :) 우리가 아직 반응 네이티브에 대해 작업하지 않은 이유에 대해. 다양한 맛으로 나오는 것 같아요. 가장 중요한 것은 그렇게 하는 데 관심이 있는 핵심 관리자가 없다는 것입니다. 나는 그것을 이해할 수 있습니다. react-dom 사용은 react-native보다 빠르게 성장하고 어렵습니다.

이에 대한 업데이트: 목록, 버튼, 카드, 아이콘, 선택 컨트롤, 텍스트 필드 및 배경을 포함하여 상당한 기능 덩어리를 다소 사용 가능한 상태로 마이그레이션했습니다. 불행히도, 우리가 마침내 반응 네이티브에서 앱 자체를 개발하게 되자 수많은 문제가 발생했고 우리는 Flutter로 옮겨야 했습니다.

언젠가는 돌아가서 우리가 한 작업 중 일부를 복구하고 싶습니다. 주로 css-shorthand-properties 및 기타 깔끔한 것들을 활용한 withStyles / classes 스타일링 솔루션의 포트지만 더 이상 우선 순위가 아닙니다. 나를위한.

@rogerstorm 은 200달러로 이 문제에 자금을 지원했습니다. IssueHunt에서 확인하세요.

문제를 해결하는 것은 우리에게 기회 비용이 될 것입니다. 닫고 있어요. 브라우저 사용 사례를 더 잘 지원하기 위해 노력할 것입니다.

@oliviertassinari , 반응 네이티브 지원이 범위를 벗어났고 가까운 미래(예: 1년)에 레이더에

네

https://github.com/lightningtgc/react-native-material-ui 또 다른 사기 npm 패키지에 불과합니다