Closed chadobado closed 5 years ago
Just discovered this repo: https://github.com/lightningtgc/react-native-material-ui Don't know whether it's any good, though.
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.
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.
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?
@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,
}
})
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
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?)
@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.
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.
@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.
@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.
@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 :)
@lenaten is material-ui-native compatible with tcomb-form-native, or if not, how big a project would that be?
@mvayngrib I stopped to work on this project for a while..
@lenaten that's a shame, thanks for responding
Alright, I have started working in this #2611. That's going to take some time!
@oliviertassinari awesome! very very excited
so is the port endeavor still open? If so what was the settled on process to implementing components?
@dorthwein It's still open.
From my point of view, the process is the following:
muiTheme
that is coming from the context. https://github.com/callemall/material-ui/pull/3829@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?
@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.
@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.
@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.
@oliviertassinari The component.native.js, component.android.js, component.ios.js file structure also seems to make the most sense to me.
@oliviertassinari I tried getting the docs up and running no luck. Few issues:
@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
.
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.
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,
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?
Also found this resource - trying it out now. Seems pretty straight forward and maybe worth a gander
@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.
@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.
@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.
@oliviertassinari is using react-native-web something that the maintainers on this project can get behind if it works out as expected?
@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
?
@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.
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.
@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.
@wordyallen : looks good 👍
@pgangwani I just started messing with it... Its not ready yet.
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
I would donate financially to this endeavor, if I could.
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 ;)
@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.
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...
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.
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.
@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.
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
@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 ;)
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.
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.
Absolutely beautiful library. Any plans to port it to React-Native in the future?
Benchmarks