Merging material designed elements.

despairblue commented 9 years ago

It seems that over the last week a lot of material designed components appeared.

What about merging those into one library, so that styles and components can be shared and so there is a coherent API?

/cc @aakashns @mastermoo @eyaleizenberg

eyaleizenberg commented 9 years ago

Sure, I can do something. What did you have in mind?

aakashns commented 9 years ago

I'd be happy to help out too.

xinthink commented 9 years ago

You guys are awesome! Thanks a lot! :beers:

Crash-- commented 9 years ago

I think it's a pretty good idea!

What we miss in the react-native world, is a good "design" lib that we can start using without to much pain. Merging several libs can be a really good solution to provide a full framework!

But it's also a lot of work to do. Do we need to reimplement all the stuff? Or can we share code between external material ui lib for react-dom?

A first start could be to be agreed on the API we should have, how to style our components and some basics rules like (we should target iOS and Android).

As react's community is on reactiflux, maybe we can ask to create #react-native-material-kit chan to discuss these topics?

despairblue commented 9 years ago

Sure thing, I can make a channel request.

I haven't found the time to think about how to do it exactly yet. It will probably take a some talking to find a good consensus.

Are you talking about a specific existing material-ui lib? One problem would be that react-native does not use react 0.14 as of yet. So using something that depends on react-dom is probably not possible.

Crash-- commented 9 years ago

I made the request to have the channel. I think it will be a good place to discuss about this project.

One of the maintainers (cc @oliviertassinari) of material-ui opened an issue ( #51 ) yesterday to see if we can share some code. I don't know exactly what we can do or can't do between react-dom & react-native, but maybe we can have a common project with "two outputs". One specific to react-dom and one for react-native.

oliviertassinari commented 9 years ago

@Crash-- Thanks for introducing me here. As I already presented, I think that it would be awesome if we could use react material components no matter what the rendering platform is. In order to do so, we could create a new repository using what we learned to do something better. We could ask to use react-material repository name.

One problem would be that react-native does not use react 0.14 as of yet

but maybe we can have a common project with "two outputs"

I fully agree, to begin with, we could create on folder for each component for the material spec, with two implementations. One for react-dom and one for react-native. They would have the same API. Then, the second step would be to share more an more code between the two versions.

Maybe what I'm proposing is utopic. Let me know what you think.

xinthink commented 9 years ago

Maybe a Slack channel is suitable for the discussion. I don't have enough knowledge about react-dom yet. But I think it's difficult to make it working on both web and native, you can see MDL is implemented mostly using CSS, which is not fully available in RN. In contrast, we may have to consider making the most out of the native side, which is purpose of RN.

xinthink commented 9 years ago

reactiflux is OK, sorry for missing this part

aakashns commented 9 years ago

I recently wrote an article about sharing components and business logic between React and React Native: https://medium.com/@aakashns/sharing-components-between-react-and-react-native-f6ce3713658a

The gist of the article is that you can wrap the platform-independent stuff in a function takes React as an argument :

export default function (React) {
  var Name = React.createClass({
    getInitialState: function() { /* Some common code */ },
    validate: function(value) { /* Some common code */ },
    syncToServer: function() { /* Some common code */ },
    onValueChange: function(value) { /* Some common code */ },

    render: function() {
      var { value, errors, sync } = this.state
      var RenderView = this.props.view;  // This will be different for Web and Native

      return <RenderView value={value} 
        errors={errors} 
        sync={sync}
        onValueChange={this.onValueChange} />;
    }
  });
  return Name;
};

Inside you have a normal react component class, except that it doesn't render the DOM/Native nodes. It passes the data required for rendering to another component class RenderView which is passed in through either props or context, and takes care of the rendering specific to a platform, and renders the DOM/Native nodes. Then you can render it like so:

import NameBase from '../shared/Name';

var Name = NameBase(React);

var NameViewWeb = React.createClass({
    render: function () {
      var { value, errors, sync, onValueChange } = this.props;
      var errorNodes = errors.map((err, i) => <div key={i}>{err}</div>);
      var syncNode = value && <div>{ sync ? "Synced!" : "Syncing..." }</div>;

      return (<div>
        <label>Name : </label>
        <input type="text" value={value} onChange={e => onValueChange(e.target.value)} />
        {errorNodes}
        {syncNode}
      </div>);    
    }
});

ReactDOM.render(
  <Name view={NameViewWeb} />,
  document.getElementById('app'));

If the above explanation is unclear, please see the article.

While we wait for React and React Native to converge, we can possibly use this pattern to share components.

-- Aakash

xinthink commented 9 years ago

Cool, thanks @aakashns

Crash-- commented 9 years ago

I think, as @aakashns mentioned, we can share common code. We just need to think about how dealing with RMNK's native code.

The channel #react-native-material-kit has been created on reactiflux. To join : http://www.reactiflux.com/

despairblue commented 8 years ago

Sorry, for the silence, I've a lot to do right now.

Going @aakashns' direction, we would wrap the react-native and react-dom code in a component that requires the respective code based on React.Platform:

let RenderView
if (React.Platform) {
  if (React.Platform.iOS)
    RenderView = require('./FAB.ios.js')
  } else if (React.Platform.Android) {
    RenderView = require('./FAB.android.js
  } else {
    throw new Error(`${Platform} not supported yet`)
  }
// I don't know if react-dom has it's own platform string, If not they might just accept a PR for that
} else {
  RenderView = require('./FAB.web.js')
}

Props would be passed straight to the underlying component. And while the APIs converge, more and more code could be pulled into the wrapper. Also probably all style options that are part of flexbox-css should be in the style argument and not props itself. That should still leave selector-based CSS styling intact (for the web).

I'm not so sure about the requires, since React 0.14 is still distributed via bower (though it sounds like npm is the preferred way to get it)

We should probably choose a repo for that and work on a branch there, or should we make a complete new one?

xinthink commented 8 years ago

Hi all, I'm going to write a demo works on all three platforms, to figure out how to organize the code, and dive a bit into react-dom. If there already has one, please let me know.

and I think if we can finally achieve a platform-independent lib, the name 'react-native-xxx' will not be proper anymore, so we'd better give it a new name.

oliviertassinari commented 8 years ago

I'm looking forward to see the demo!

hendrikswan commented 8 years ago

Maybe this repo? https://github.com/benoitvallon/react-native-nw-react-calculator

xinthink commented 8 years ago

Thanks @hendrikswan, it's very helpful!

oliviertassinari commented 8 years ago

There is another popular react-native implementation https://github.com/binggg/mrn.

xinthink commented 8 years ago

oh, it looks very good

alexprice1 commented 8 years ago

Bringing this conversation back. Would love to get a cross-platform solution working. Wondering if material-ui is still a bit too unstable and has too many features to really implement. If they archive more stability we could look at matching their API. One huge benefit of working with them is the number of contributors they have.

oliviertassinari commented 8 years ago

Wondering if material-ui is still a bit too unstable and has too many features to really implement.

One of the Material-UI maintainers speaking. I have done a POC with React Native. I have learned various things in the process. Let's list how we could interconnect.

sharing the same code? The react ecosystem seems far from this ideal world. E.g. The POC I have done two months ago was broken with the React v15 release. Basically, React Native wasn't working with the new release. I should check again with the latest releases. But the most concerning point for me is styling. Yes, we could share some of the code, but not 100%. E.g. High Order Components are often good candidates. This is what I'm doing in one of my cross platform project, the autoPlay is working great. Hence, I believe we should aim for stateless components.
sharing the same API? That sounds far more realistic. As you point out, we have pretty large and evolving API. I don't think that we can achieve a 100 % matching API. However, there are many intermediary steps that we can benefit from. E.g. we could have the same component spliting / responsibility / name.

I'm just giving my point of view. I won't be a driving force. But I would be glad to help.

alexprice1 commented 8 years ago

@oliviertassinari this is great. I think long term #2 would be the way to go.

I wonder if on RNMK's side we can start using MU as a baseline of which features to support.

On MU's side, if they started using Higher Order Components to define a declarative API, then we could work off of these for new components.

xinthink / react-native-material-kit

Merging material designed elements. #50