Why not use componentHandler instead ? about react-mdl HOT 16 CLOSED

the code can then simply become

   componentDidMount(){
     let domNode = React.findDOMnode(this);
     let ch = componentHandler.upgradeElement(domNode);
   }
   componentWillUnmount(){
      ch.downgradeElement();
   }

Other benifits of this approach are

• DRY
• Code Stays in sync

Possible Issues

• Components with dynamic children components like the Tabs or Layouts but re-implementing them is easier than re-implementing the whole lib.

from react-mdl.

Good point. To be honest, I never thought about their upgradeComponent function...
Sure it will work and as you said, it will simplifies a lot the code and will make sure the code stays in sync. But I don't like the fact the entire JS file will be required to make that work. The current MDL implementation is not really module friendly. Maybe that will change in the future.

With your code sample, i'd need to reset (downgrade - upgrade) when the component receive new props as well, at least for the textfield since it'll receive the maxRows at an attribute.

For complex components like the layout, it won't be possible though since I'll probably split them in multiple components (Layout, Header, Navigation, Tabs, Drawer).

Also, using the original JS code to upgrade the elements makes the code less "react friendly" since it creates dom nodes on the fly. I don't think it's a major issue though but still...

But I'm open to discussion...

from react-mdl.

Not really when components are passed you can use the element.widget to update them :) using the api and selectively have it update and reMount on update that can be packed as a mixin or sebmecks higher order classes. Also about modularity that is indeed a. Bummer so far but as of now you need the file anyways and when modularity will come it should be a transparent update for the user ... Btw the credits to this idea goes to winjs team and also at the level of pure css and vanillajs enclosed high performance components the react magic is an overhead over extremely performant hand tweaked js code.

-----Original Message-----
From: "Tommy" [email protected]
Sent: ‎22-‎07-‎2015 07:48
To: "tleunen/react-mdl" [email protected]
Cc: "Abhishek Hingnikar" [email protected]
Subject: Re: [react-mdl] Why not use componentHandler instead ? (#1)

Good point. To be honest, I never thought about their upgradeComponent function...
Sure it will work and as you said, it will simplifies a lot the code and will make sure the code stays in sync. But I don't like the fact the entire JS file will be required to make that work. The current MDL implementation is not really module friendly. Maybe that will change in the future.
With your code sample, i'd need to reset (downgrade - upgrade) when the component receive new props as well, at least for the textfield since it'll receive the maxRows at an attribute.
For complex components like the layout, it won't be possible though since I'll probably split them in multiple components (Layout, Header, Navigation, Tabs, Drawer).
Also, using the original JS code to upgrade the elements makes the code less "react friendly" since it creates dom nodes on the fly. I don't think it's a major issue though but still...
But I'm open to discussion...
—
Reply to this email directly or view it on GitHub.

from react-mdl.

Currently, the master js file is not needed.

I'll investigate this path of including it and make the component just "container" calling the upgrade/downgrade function.
Not sure yet how to do for the Layout/Drawer though. Any idea?

from react-mdl.

@tleunen For layouts I'd say a mix of both, you can listen to events and call React.render on individual props when you wish to dynamically render them out of react context but that will not be justice. I'd say use react to create the html and then call .upgrade.

Have a look at http://darkyen.github.io/react-ui-components/

It is a hybrid method of doing what you did.

from react-mdl.

I'll make some tests this weekend using the component upgrade feature. I'll create a specific branch for that so you can see what I'm doing

from react-mdl.

I'd love to help :-) , If this gets done I can move basic components out of my ui-components and have only common app ones there. (making react-mdl a dependancy)

from react-mdl.

Tried something on this branch https://github.com/tleunen/react-mdl/tree/component-upgrade
What do you think?
The code is now on master.

from react-mdl.

:D :D thats awesome !

Much better than my small implementation :D +1 + 1

from react-mdl.

       var buttonClasses = classNames('mdl-button mdl-js-button', {
            'mdl-js-ripple-effect': ripple,
            'mdl-button--raised': raised,
            'mdl-button--colored': colored,
            'mdl-button--primary': primary,
            'mdl-button--accent': accent,
            'mdl-button--icon': !!icon
        }, className);

I'd like to reduce the recurring code there, wouldn't u (by a mixin or a lil bit of inhertiance maybe) ?

// a lil bit of inheritance won't hurt

class MaterialComponent extends React.Component{
    /* alternatively now the component handler can be injected here */
    getMaterialStateClasses(){
         let states = this.constructor.MDLStates;
         let props = this.props;
         let prefix = 'mdl-' + this.constuctor.MDLClassName;
         let reduceStateObj = (obj, state) => { 
                obj[prefix + '--' + state] = props[state];
                return obj;
         }
         return states.reduce(reduceStateObj, {});
    }
}


class Button extends MaterialComponent{
   render(){
          let states = this.getMaterialStateClasses();
          let buttonClasses = classNames('mdl-button', 'mdl-js-button', states); 
   }
}

Button.MDLClass =  'button';
Button.MDLStates = ['raised', 'colored', 'primary', 'accent', 'icon'];

// with es 7 the static keyword can be used.

from react-mdl.

I played a bit with my implementation and it had some issues. I cannot register the MDL components on the fly because the order of registered components inside MDL is important. I cannot register the Ripple Effect because Button (or Switch) for example.
So I'm removing that part, and until I find a better way (or MDL fixes this part), the MDL js file will be needed so we have the global componentHandler variable. I'll publish 0.5 with this change.

About inheritance vs helper class, I'll think about it. It won't make sense if it's not used a lot, so I'll wait to see how the other components will be built.

from react-mdl.

I'll close this issue..
I refactored a bit some of the current components (should push everything later tonight).
I'll work on adding the missing components as well before 1.0.

from react-mdl.

Awesome.

from react-mdl.

my latest commit just removed all of my custom code for your implementation 🎯 the latest build is incredible.

from react-mdl.

Thanks ;)
The only missing part is the tabs inside the header. I did something really quick but I'm not happy.
I'd like from the MDL team a way to use the styles for the tabs without the code (because it's based on a hash on a href elements + panels), but for now it's not possible without writing css myself, which I'd like to avoid.

from react-mdl.

Makes sense.

MDL's tabs are pretty limited, and honestly tabs are hard to implement in a framework agnostic way (I personally have my own version of swipe tabs for android built using their styles)

from react-mdl.