mui / material-ui

MaterialĀ UI: Ready-to-use foundational React components, free forever. It includes Material UI, which implements Google's Material Design.
https://mui.com/material-ui/
MIT License
91.86k stars 31.57k forks source link

Support React Native #593

Closed chadobado closed 5 years ago

chadobado commented 9 years ago

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

Benchmarks

bparadie commented 8 years ago

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

hai-cea commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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

lenaten commented 8 years ago

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

mvayngrib commented 8 years ago

@lenaten that's a shame, thanks for responding

oliviertassinari commented 8 years ago

Alright, I have started working in this https://github.com/callemall/material-ui/pull/2611. That's going to take some time!

mvayngrib commented 8 years ago

@oliviertassinari awesome! very very excited

dorthwein commented 8 years ago

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

oliviertassinari commented 8 years ago

@dorthwein It's still open.

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

dorthwein commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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

dorthwein commented 8 years ago

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

oliviertassinari commented 8 years ago

@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 (https://github.com/callemall/material-ui/pull/3829). I should try to start from a fresh git clone.

dorthwein commented 8 years ago

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.

dorthwein commented 8 years ago

Was reading up on some stuff and noticed this tidbit from the FB React Native Page.

"The most fundamental component for building UI, View is a container that supports layout with flexbox, style, some touch handling, and accessibility controls, and is designed to be nested inside other views and to have 0 to many children of any type. View maps directly to the native view equivalent on whatever platform React is running on, whether that is a UIView,

, android.view, etc. This example creates a View that wraps two colored boxes and custom component in a row with padding."

Source: https://facebook.github.io/react-native/docs/view.html

In light of this I think our current approach maybe a bit off given that a huge portion of the generic work can be done by switching divs to Views. Headers and other related tags would also have to be mapped in a more universal way as well.

Thoughts?

dorthwein commented 8 years ago

Also found this resource - trying it out now. Seems pretty straight forward and maybe worth a gander

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

quanglam2807 commented 8 years ago

@dorthwein Great idea! But if we follow this path, I think developing a version for React Native only would be better.

We can rewrite the whole project under React Native APIs instead of separate codes for Native and DOMs. Amazing! I have never thought about this.

dorthwein commented 8 years ago

@quanglam2807 yeah - that way new features etc... Stay in line with each other. Biggest challenge I think is then having the styles and animations working. Also other big plus is that we can gradually add support for different components.

Down side is everything will need to be using flex boxes.

Given that this is a major refactoring of the code base - who all needs to sign off on this to go forward? I still need to play around and see how robust the react-native-web stuff is also.

dorthwein commented 8 years ago

@quanglam2807 @oliviertassinari another advantage with this approach is that material-ui will easily port over to https://github.com/ptmt/react-native-desktop as well.

dorthwein commented 8 years ago

@oliviertassinari is using react-native-web something that the maintainers on this project can get behind if it works out as expected?

oliviertassinari commented 8 years ago

@dorthwein I love the idea behind this project. But I don't think that it would help in the near future. Don't we first need to write a native version of our components before we can use react-native-web?

dorthwein commented 8 years ago

@oliviertassinari no, what react-native-web does is use the most "native" component depending on the platform. So for example given a View tag, it'd use a div in the browser, a UIView in iOS and what ever the equivalent to UIView is Android.

The process would then be instead of writing native versions of each component, that we'd just have to convert the existing ones to use View instead of div and style Text instead of using things like h1 and label.

Definitely not a small undertaking but the process would then be updating the existing components instead of trying to create & maintain multiple versions.

oliviertassinari commented 8 years ago

The process would then be instead of writing native versions of each component, that we'd just have to convert the existing ones to use View instead of div and style Text instead of using things like h1 and label.

That sounds exactly like writing a native version that hopefully, work in the browser too. As far as I know react-native-web is bringing react native to the web and not the otherway around. Still, that can be really handy to share the same code :+1:. I have seen one small issue with this lib so far. Their StyleSheet.create implementation doesn't support dynamic values (needed for the muiTheme). We could use react look for this use case.

dorthwein commented 8 years ago

@oliviertassinari your right - I was understanding it backwards. Step 1 it seems is still building react-native versions of the components. Step 2 would be potentially merging them into a single code base using something like react-native web.

pgangwani commented 7 years ago

@wordyallen : looks good šŸ‘

wordyallen commented 7 years ago

@pgangwani I just started messing with it... Its not ready yet.

joncursi commented 7 years ago

Ive been using https://github.com/react-native-material-design/react-native-material-design to fill the gap but it's very rough around the edges as well and no active development

wordyallen commented 7 years ago

I would donate financially to this endeavor, if I could.

xotahal commented 7 years ago

Hi guys,

I work on react-native-material-ui, that is inspired by this library. Feel free to try - I would like to hear any feedback ;)

ghost commented 7 years ago

@xotahal et. al, Instead of creating from scratch what we should be doing IMHO is forking this library and porting existing components rather than recreating them. The need for the material style inputs is sorely needed in the RN space, if you ask me. Thanks to all for your OSS efforts.

antoinerousseau commented 7 years ago

I don't think there is much common code, I think creating from scratch makes sense. Styling in RN will be 90% different than this one. And there is quite some platform specific mechanic like animations...

ghost commented 7 years ago

It seems adopting the component structure, props (and docs) and having a clear upstream, even if a lot changes, would be beneficial long-term for those shifting back and forth from web to native and is of most importance. The rest becomes an implementation detail.

joncursi commented 7 years ago

I agree with @jhabdas ; the more similar the APIs can look for each component, the less jarring it will be for developers to switch out of web projects and native projects. The less jarring the experience, the more productive they can be. I'd expect the platform-specific details to be abstracted behind the scenes of the component.

ghost commented 7 years ago

@chadobado or maintainer, would you kindly rename this issue to "Support React Native" to raise visibility when searching this repo? Currently searching "React Native" buries this in the list because the term is hyphenated in the title.

ghost commented 7 years ago

FWIW, this caught my eye.

@necolas on Web support for react-native-material-kit:

You're unlikely to need to port much if any Stylesheet as compatibility is provided by the web implementation of React Native

antoinerousseau commented 7 years ago

@jhabdas if you play a bit with react native you'll see that it's not that straightforward. The StyleSheet API is awesome but you do have to rewrite quite some stuff ;)

ghost commented 7 years ago

Fair point @antoinerousseau. I keep thinking back to a quote from James Long on RN:

Think of it as a prototype for a different direction for the web

If I'm understanding the purpose of the library @necolas is working it seems a sane approach would be to inverse the problem: rather than porting the CSS to RN just rebuild the whole thing in RN and back port for web using a shim. React Native Material Kit already has a good jump on the problem.

mattferrin commented 7 years ago

Since react-native-web appears awesome, I'm just going to create material-ui.android.js, material-ios.ios.js, and material-ui.web.js files in my own personal project and calling it good. If I follow the material-ui API by wrapping everything else, it will eventually work out. If material-ui surprises me and just works, I'll only need to remove the .web from the .web.js and delete the other files. This way I can selectively transition to material-ui per component.