New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support React Native #593

Open
chadobado opened this Issue Apr 28, 2015 · 115 comments

Comments

@chadobado

chadobado commented Apr 28, 2015

Absolutely beautiful library.

Any plans to port it to React-Native in the future?

@bparadie

This comment has been minimized.

bparadie commented May 26, 2015

Just discovered this repo: https://github.com/lightningtgc/react-native-material-ui
Don't know whether it's any good, though.

@hai-cea hai-cea changed the title from React-native? to Create material-ui React-native Jun 19, 2015

@hai-cea

This comment has been minimized.

Member

hai-cea commented Jun 19, 2015

Thanks @chadobado - We've talked about it for sure and it would be a fun project to start. However, we've got our hands full with this project at the moment. I'll keep this issue open and update if we ever create a native library.

@quanglam2807

This comment has been minimized.

Contributor

quanglam2807 commented Oct 23, 2015

This is actually a great idea. I have tried to test porting material-ui to React-Native. We only need to stylesheets a little bit, change all div to View, change all h1, h2, etc to Text and it'll work great. The only problem I've found is that React Native doesn't fully support boxShadow so it's hard to implement Paper component at the moment. Also, it would be great if we can great a script to auto-port the code to React-Native as it's not very different.

@oliviertassinari

This comment has been minimized.

Member

oliviertassinari commented Oct 23, 2015

change all div to View, change all h1, h2, etc to Text and it'll work great

Couldn't we use a babel-plugin-transformer to do it?

This is actually a great idea

Do you have a demo project?

@quanglam2807

This comment has been minimized.

Contributor

quanglam2807 commented Oct 23, 2015

@oliviertassinari

Couldn't we use a babel-plugin-transformer to do it?

I'm not sure as the stylesheet of React Native is quite different from CSS so it'll be quite complicated to make the transformer.

Do you have a demo project?

Not yet cause' I'm quite busy but I'll try to show you a small demo soon.
But here is what we need to do

Stylesheets

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

to

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 solution

JSX

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

to

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

We also need to modify styles/transition.jsx (React Native use object instead of string), mixins/style-propable.jsx as we don't need to deal with multiple browsers, etc

@lenaten

This comment has been minimized.

lenaten commented Dec 4, 2015

I just publish a WIP forking to react-native in https://github.com/lenaten/material-ui-native.
Currently only Card and RaiseButton is working, but without style (WIP remember?)

@oliviertassinari

This comment has been minimized.

Member

oliviertassinari commented Dec 4, 2015

@lenaten Interesting!
I also wanted to start working on a wrapper between this project and mrn (https://github.com/oliviertassinari/react-material).
It seems that your fork is only working with react-native, how would you make it work with the browser too?
I think that it's the most difficult point and should be addressed now, since you say that you have two working component. I can help if you want.
As said before, I also wanted to investigate https://github.com/binggg/mrn for our native implementation.

When it's answered, I think that we could merge your fork back here.

@lenaten

This comment has been minimized.

lenaten commented Dec 4, 2015

Material-UI is mature project against mrn project that misses a lot of material components. If my POC will work as excepted, merge it to cross platform file structure should be easy. I have no time to reinvent the wheel and start from scratch project.

Anyway, your help in thoughts and code is very welcome.

@quanglam2807

This comment has been minimized.

Contributor

quanglam2807 commented Dec 4, 2015

@oliviertassinari Me, too.

My idea to make material-ui works with both browser and native is to use filename structure, similar to the way react-active handles iOS and Android at the same time.

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

or we can still use the same components for both browser and native and then write a wrapper to handle them. For example, react-native uses View, browser use div then do it like this:

div.browser.jsx

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

div.native.jsx

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

app-bar.jsx

import {div} from "div"

We can actually create a separated project for this wrapper.

@oliviertassinari

This comment has been minimized.

Member

oliviertassinari commented Dec 4, 2015

@quanglam2807 I'm glad to hear it.

Regarding the code organisation, I like the idea of having separate file extensions.
I would take https://github.com/benoitvallon/react-native-nw-react-calculator/tree/master/src/common/components example as the way to do it.

Regarding the project organisation, I may have changed my mind.
I think that it's better to follow Google approach and work on a big single repository. Hence working on a fork sync with material-ui or here could be good way to do it.

To begin with our .native files, we could depend on

components.

@lenaten

This comment has been minimized.

lenaten commented Dec 4, 2015

@oliviertassinari I also love the idea of "file extension" model. The most important to me now, is working native components. If you want to help with code abstraction you welcome. I commits to remove the "native" suffix from the repo name :)

@alitaheri alitaheri added the Deployment label Dec 8, 2015

@mvayngrib

This comment has been minimized.

mvayngrib commented Dec 15, 2015

@lenaten is material-ui-native compatible with tcomb-form-native, or if not, how big a project would that be?

@lenaten

This comment has been minimized.

lenaten commented Dec 15, 2015

@mvayngrib I stopped to work on this project for a while..

@mvayngrib

This comment has been minimized.

mvayngrib commented Dec 15, 2015

@lenaten that's a shame, thanks for responding

@oliviertassinari

This comment has been minimized.

Member

oliviertassinari commented Dec 21, 2015

Alright, I have started working in this #2611.
That's going to take some time!

@mvayngrib

This comment has been minimized.

mvayngrib commented Dec 21, 2015

@oliviertassinari awesome! very very excited

@dorthwein

This comment has been minimized.

dorthwein commented Mar 20, 2016

so is the port endeavor still open? If so what was the settled on process to implementing components?

@oliviertassinari

This comment has been minimized.

Member

oliviertassinari commented Mar 20, 2016

@dorthwein It's still open.

From my point of view, the process is the following:

  • Upgrade to the latest version of react-native and remove react-native-webpack-server. I have already done it on this project. #3829
  • Play with react-look and see how well we can use it for the muiTheme that is coming from the context. #3829
  • Wait on the folder reorganisation so we have somewhere to put the new components
  • Start working on the documentation app that we will use to showcase new component.
  • Start working on the native version of components.
@dorthwein

This comment has been minimized.

dorthwein commented Apr 1, 2016

@oliviertassinari - I can contribute a little bit of time porting some of the components over once the way forward is set. Looking at your list the only unknown right now is the react-look stuff right?

@oliviertassinari

This comment has been minimized.

Member

oliviertassinari commented Apr 2, 2016

@dorthwein we are happy to hear it.
I'm using react-look here #3829. The only issue I have is a minor one. React Native is displaying some warning regarding wrong usage of the StyleSheet API. I haven't looked a it in detail but I believe that it can be solved.

@PublicParadise

This comment has been minimized.

PublicParadise commented Apr 2, 2016

@oliviertassinari @dorthwein I am happy that this effort (that is, bringing material-ui to react-native) is not dead. I just wanted to point out that there is also another new material-ui to react-native project that hasn't been mentioned in this thread: https://github.com/react-native-material-design/react-native-material-design . That project seems to be based on https://github.com/binggg/mrn.

@dorthwein

This comment has been minimized.

dorthwein commented Apr 6, 2016

@oliviertassinari I saw in another thread if supporting iOS made sense for this port - I think it absolutely does especially when you look at how Google Maps & other Google Material + iOS apps are out there. Where it makes sense and there is a strong pre existing iOS component (e.g. switches) it should use to the iOS switch on iOS. Implementing Android & iOS isn't much of a burden as well.

@dorthwein

This comment has been minimized.

dorthwein commented Apr 6, 2016

@oliviertassinari The component.native.js, component.android.js, component.ios.js file structure also seems to make the most sense to me.

@dorthwein

This comment has been minimized.

dorthwein commented Apr 6, 2016

@oliviertassinari I tried getting the docs up and running no luck. Few issues:

  • package.json: react-native does not like the package name material-ui - changing to materialUI resolved the issue
  • The current material-ui/react-native branch is having an issue with the react-native packager and not creating the mainjs.bundle file. I haven't been able to figure out what was going on here.
  • I can't seem to get a working react-native app going on top of the existing material-ui repo. If any one has had any luck on this front lets get a stable heres how to contribute/develop native components set.
@oliviertassinari

This comment has been minimized.

Member

oliviertassinari commented Apr 6, 2016

@dorthwein Thanks for the feedback. The react-native branch is highly experimental. We need to solve this.
On the other hand, I haven't any issue on my side (#3829).
I should try to start from a fresh git clone.

@dorthwein

This comment has been minimized.

dorthwein commented Apr 6, 2016

Yeah so the next stage of my current project is working on a mobile app using material design - I'd like to use this as all our web stuff is in this as well. If we can get a working environment going I'll start knocking it out along with our project.

@necolas

This comment has been minimized.

necolas commented Mar 15, 2017

@quanglam2807 that thread is very long, what should I be looked at?

In order to extend the features to the web, we could be using: https://github.com/necolas/react-native-web, https://github.com/taobaofed/react-web

react-web is pretty far from being performant or functionally correct IMO.

The API has to be reimplemented to work with the browser. What's the overhead?

Overhead in what dimensions? Hard to determine in terms of bundle-size. You'd probably be able to drop some of your existing code; but if you were to depend on anything beyond the RNW core exports, it will add up quickly. In style-heavy components for mobile.twitter.com, I've been seeing 20-40% reduction in component size converting styles from css-modules to RNW StyleSheet. In terms of runtime performance, it's currently not far off css-modules.

What about media queries?

You can use matchMedia to change styles and component structure, although the benefits of using media queries to alter components aren't clear to me.

CSS inheritance, CSS animations?

RNW supports CSS animations (although I need to add an API to define keyframes). What's the question related to CSS inheritance?

How would we implement accessibility and keyboard events without bloating the native version?

Not sure what this means. I suspect the threshold for "bloat" in a native app is far higher than for a web app.

@necolas

This comment has been minimized.

necolas commented Mar 16, 2017

so maybe comparing how react-native-web handles styles to render css performances to css-modules performances is less pertinent now

Why would that be?

It'd be great to have a kind of react-native-web who use something like aphrodite or jss

Both of those libraries are slower, larger, and not well suited to providing deterministic styles

@NitroBAY

This comment has been minimized.

NitroBAY commented Mar 17, 2017

@necolas material-ui is providing a great effort to switch from a css-in-js method to a stylesheet method (css in <style>). They have been active efforts for months to switch the components. Reasons are here. From what I read using jss is an huge advantage and seem to be the most perfect solution to handle style so far.

@NitroBAY

This comment has been minimized.

NitroBAY commented Mar 17, 2017

By the way by reading the Roadmap.md again the RN support is on the Roadmap.

@wswoodruff

This comment has been minimized.

wswoodruff commented Sep 4, 2017

I'm very interested in using Material-UI with react-native, any word on progress?

@xotahal

This comment has been minimized.

xotahal commented Sep 5, 2017

@wswoodruff You can check this one for now - https://github.com/xotahal/react-native-material-ui

@abdennour

This comment has been minimized.

abdennour commented Sep 10, 2017

Currently, we have three awesome libraries for that:

Enjoy!

@jhabdas

This comment has been minimized.

jhabdas commented Sep 10, 2017

There's also the lesser known Carbon UI if you're going universal. But for my time I'd probably stick to one of these.

@travi

This comment has been minimized.

travi commented Sep 12, 2017

its been touched on a couple of times in this thread, but i want to call it out again because of how it impacts my interest in this change: the main benefit of react-native support that i see isn't actually about react-native, but instead about being built on the primitives that enable the same components to be used on both native and web.

if that type of primitive were used, other tools like react-sketchup and react-pdf could also be enabled.

personally, those are more interesting to me than native, but would be enabled by the same changes.

@deadcoder0904

This comment has been minimized.

deadcoder0904 commented Sep 29, 2017

@jhabdas How is ur experience using Carbon UI ? Bcz to me it looks pretty good but didn't use it yet.

@jhabdas

This comment has been minimized.

jhabdas commented Sep 29, 2017

@deadcoder0904 haven't used it yet personally. probably try reaching out to one of the guys at infinite red. they run the RN newsletter and should be the subject-matter experts. if and when I do build another RN app (okay, when...) I won't be clobbering things together this time or building another boilerplate—IMHO the space is solved by existing boilerplates and components.

@dantman

This comment has been minimized.

dantman commented Mar 28, 2018

Here are some of the hurdles that I can think of that would need to be overcome to make MUI available in React Native. Assuming v1 MUI and we keep JSS, the classes pattern, and other things that are at this point key parts of MUI's api design.

  • JSS needs to support RN, namely making style objects in such a way that withStyles just works. More on this in cssinjs/jss#368 (comment).
  • Assuming there is no hacky wrapper or babel transform, we'll need to augment the classes pattern so it works the same but accounts for the fact that on RN it should instead pass an array to style, and probably should be named styles. Perhaps this could be handled by dropping classnames and adding spreadable helpers that behind the scenes switch between classes/className handling and styles/styles.
    Maybe:
    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 would accept a list of style names (and ignore falsy values). On web it would look in props.classes and output {classNames}. On native it would look in props.styles and output a {style}.
    Originally I thought of this.composeStyles with a decorator, but instead of that withStyles could just pass a style composition helper in as part of props.
  • As others mentioned after all this to make basic styled components work, we'll need extra work to make animations, touchables, etc... work.
  • However for animations I don't consider this a bad thing. It is a small loss for simple transitions, where you're just automatically transitioning opacity, backgroundColor, etc we may want helpers that keep those simple. But from what I've seen, the actual material transition implementations other than those look overly complicated/cryptic and won't scale up well. react-transition-group has some nice ideals for handling the low level portion of things (entry/exit handling, etc), but is problematic / in the way in others. Also instead of the css transitions based design I think the forward thinking way to go would be to use the new Web Animations API and require the polyfill for it.
    In other words, I think there is room for the creation of a new library to handle animations in React that uses Web Animations in the browser and the Animated API in React Native and is a general improvement over how MUI handles animation.
  • MUI needs to ditch the expectation that cascading behaviour is available. And the theme setup needs to be enhanced to support easily applying modifications to the theme within a subtree.
    Right now things like AppBar + Icons work by setting text color, using an explicit color='inherit' and assuming the color will cascade down. And it's possible that this is the same in other parts of MUI.
    There is no cascading like this in React Native. Instead you must declare your styles explicitly for each View. For these types of things AppBar and other components will need to be able to easily provide a modified version of the theme they are provided with a modification like changing the theme within that context to dark so icons get the correct contrasting icon colors (and can be based on the actual icon colors spec instead of text color). Note that this may have implications on things like menus nested in app bars.
  • As an extension of this cascading issue. MUI is also designed around things like <Button>Text</Button>, where it's assumed that MUI can just style the fontFace/color, etc... of the button's root, let you insert anything in the children, and just let React DOM insert a mix of elements and text nodes and the text nodes get the right styling.
    This falls apart in React Native. All text must be part of a <Text>, all text styles must be on that component's styles, and a text element cannot contain non-text children (i.e. ).
    There are a few options:
    • The <Button text='Text' /> pattern works much better in React Native. Unfortunately that's fundamentally different from MUI's ethos, so it's not an option.
    • We could map the children and replace strings with styled Text elements. However this is brittle, the moment you wrap the string in anything it falls apart (even react-intl would make it fall apart). Ugh.
    • It's not the prettiest way to do it, we'd have to wait, and I do not 100% understand the performance implications. But we could use React 16.3's new context api, and expose a <MuiText>Text</MuiText>. Basically MUI components like Button would have providers that would provide information about the current context's styles (font, text color, etc...) and MuiText would just consume that data and apply it to a Text element.
@deadcoder0904

This comment has been minimized.

deadcoder0904 commented May 18, 2018

Today v1 released so what are the plans of React Native

For React Native Material Support, there is a beautiful library called React Native Paper which will be maintained & supported by CallStack team.

But are there any plans to port this to React Native because I think Paper works perfectly fine

If not, then you can probably close this issue :)

@jhabdas

This comment has been minimized.

jhabdas commented May 19, 2018

Thanks for sharing @deadcoder0904. I've added Paper to Awesome React Components. Haven't heard of CallStack. At first I read it as Call-Em-All. Guessing they're not the same peeps, ya?

@deadcoder0904

This comment has been minimized.

deadcoder0904 commented May 19, 2018

@jhabdas Nope they're not same

@micimize

This comment has been minimized.

micimize commented Jun 1, 2018

@dantman Here are my thoughts on the best way to go about achieving native support

  • if sticking to jss isn't an absolute requirement, I think fela is a viable alternative:
  • react-native-animatable has keyframe support, and could probably be used instead of transition-group as well, which may or may not work with native.
  • I agree with subverting the no-cascading view of react-native. It could be opt-in at provider and consumer with cascade and inherit props.
    Every react-native library I've tried working with has been painful or unusable because of overly-rigid apis and un-overridable styles, with the exception of ones that use @shoutem/theme to allow overrides (like native-base).
@vietvudanh

This comment was marked as off-topic.

vietvudanh commented Jun 11, 2018

Still waiting for this support. Using beautifully on Web but I develop on mobile too!

@victorhugoweb

This comment was marked as off-topic.

victorhugoweb commented Jul 10, 2018

any update about support react native?

@micimize

This comment has been minimized.

micimize commented Jul 30, 2018

@oliviertassinari I intend to fork and start exploring the implementation path I outlined above. My priority is going to be getting the components I need for another project working, so I probably won't be PRing robust React Native support anytime soon, but I'll try to keep it "in sync" with master as much as I can in hopes it'll one day be useful (or possibly merged)

@oliviertassinari

This comment has been minimized.

Member

oliviertassinari commented Jul 30, 2018

@micimize Thanks for letting me know. I wish you good luck in this project! :) Regarding why we haven't been working on react-native yet. I think that it comes in different flavors. Most importantly, we have no core maintainer interested in doing such. I can understand it, react-dom usage grows faster than react-native and it's hard.

@micimize

This comment has been minimized.

micimize commented Sep 19, 2018

Update on this: We migrated a substantial chunk of functionality to a somewhat-usable state, including lists, buttons, cards, icons, selection controls, text fields, and backdrop. Unfortunately, once we were finally developing our app itself on react-native, a multitude of issues cropped up and compelled us to move to Flutter.

At some point I would like to go back and salvage some of the work we did, chiefly the port of withStyles / classes styling solution which leveraged css-shorthand-properties and some other neat stuff, however it is no longer a priority for me.

@IssuehuntBot

This comment has been minimized.

IssuehuntBot commented Nov 19, 2018

@rogerstorm funded this issue with $200. See it on IssueHunt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment