Support React Native

[chadobado]

Absolutely beautiful library. Any plans to port it to React-Native in the future?

Benchmarks

• https://github.com/callstack/react-native-paper
• https://github.com/xinthink/react-native-material-kit
• https://github.com/xotahal/react-native-material-ui
• https://github.com/binggg/mrn
• https://github.com/lightningtgc/react-native-material-ui
• https://github.com/invertase/react-native-material-design

[bparadie]

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

[hai-cea]

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 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]

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]

@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]

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]

@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]

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]

@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]

@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

• https://github.com/binggg/mrn
• or https://github.com/xinthink/react-native-material-kit

components.

[lenaten]

@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 :)

[mvayngrib]

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

[lenaten]

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

[mvayngrib]

@lenaten that's a shame, thanks for responding

[oliviertassinari]

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

[mvayngrib]

@oliviertassinari awesome! very very excited

[dorthwein]

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

[oliviertassinari]

@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. [ReactNative] Add support for the Subheader component #3829
• Play with react-look and see how well we can use it for the muiTheme that is coming from the context. [ReactNative] Add support for the Subheader component #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]

@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]

@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]

@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]

@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]

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

[dorthwein]

@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]

@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]

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.

[ghost]

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]

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]

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

[ghost]

@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]

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 [react-native] React Native Support 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]

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 :)

[ghost]

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]

@JHabdas Nope they're not same

[micimize]

@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:
  • fela-native supports media queries and uses StyleSheet.create properly
  • It is insanely extensible. We could have rewrite rules for web properties to their react-native proxies, strip things like :hover rules on native, and probably regain whatever syntax is lost from jss.
• 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).

[micimize]

@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]

@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]

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]

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

[oliviertassinari]

Working on the problem would be an opportunity cost for us. So far, we are spread too thin. I'm closing.

We will double down on better supporting the browser use cases. Once we nail this, then we can expand our focus.

[RohovDmytro]

@oliviertassinari , does it mean that react native support is out of scope and in near future (e.g. 1 year) it won't be on radar?

[oliviertassinari]

does it mean that react native support is out of scope and in near future (e.g. 1 year) it won't be on radar?

Correct. We don't have a funding model that can currently sustain it, e.g. https://npm-stat.com/charts.html?package=react-dom,react-native.