Hello everyone.
I have encountered a problem applying fontSize style on FontIcon. FontIcon is inside a IconButton.
The icon size is still the default size (24).
import React, { Component } from 'react';
import IconButton from 'material-ui/IconButton';
import FontIcon from 'material-ui/FontIcon';
export default class Test extends Component {
getStyles() {
const styles = {
iconStyles: {
fontSize: 16,
},
};
return styles;
}
render() {
const styles = this.getStyles();
return (
<IconButton tooltip="Add">
<FontIcon className="material-icons" style={styles.iconStyles}>add_box</FontIcon>
</IconButton>
);
}
}
I found this looking for something else but I think I can answer your question. If you take a look at the docs for <IconButton />
it looks like you can change the size using the iconStyle
property in addition to the style
property. Like so.
const styles = {
smallIcon: {
width: 36,
height: 36,
},
small: {
width: 72,
height: 72,
padding: 16,
},
};
const IconButtonExampleSize = () => (
<div>
<IconButton
iconStyle={styles.smallIcon}
style={styles.small}>
<ActionHome />
</IconButton>
</div>
);
@caseychoiniere This will works only for SVG icons but not for Font icons. FontIcon
has a fontSize
attribute but this attribute is ignored when FontIcon
is a child of IconButton
. Anyway the workaround is to use SVG icons like y've described.
+1, this is quite frustrating! Thanks tho' for the amazing job.
Looks like we can close this issue
Has it been fixed?
I am still having the issue with react 15.3.0
and material-ui 0.15.4
@aahan96 Please re-open this issue since it's not already fixed.
The docs themselves at http://www.material-ui.com/#/components/raised-button list the following code:
import FontIcon from 'material-ui/FontIcon';
<RaisedButton
href="https://github.com/callemall/material-ui"
target="_blank"
secondary={true}
icon={<FontIcon className="muidocs-icon-custom-github" />}
style={style}
/>
And yet it doesn't work and there's nothing explaining how to get it to work. The <FontIcon>
element seems to not even add the required font-family attribute for icons to work if manually adding them to the head, either.
Including the font css then makes it work with icon={<i className="material-icons">edit</i>}
, however it doesn't inherit the same colour as the text along with it, which is problematic with theming. Adding it directly into the label is not very accessible and causing styling issues.
Basically, the way the docs describe it, this should be super easy and require no extra work, yet there are several threads about this spanning years that have people in it who are completely lost!
@aahan96 not fixed. Reopen issues, plz.
Also voting to reopen the issue. For now I copied the FontIcon component and referenced it in my own project rather than material-ui
, and I've just passed getStyles
a fontSize
prop that it puts in its root styling if it exists, else use the default.
function getStyles(props, context, state) {
const {color, hoverColor, fontSize} = props;
const {baseTheme} = context.muiTheme;
const offColor = color || baseTheme.palette.textColor;
const onColor = hoverColor || offColor;
return {
root: {
color: state.hovered
? onColor
: offColor,
position: 'relative',
fontSize: fontSize || baseTheme.spacing.iconSize,
display: 'inline-block',
userSelect: 'none',
transition: transitions.easeOut()
}
};
}
Not sure why this was ever closed. @aahan96?
Preaching to the choir, but - the best way to get an issue fixed is (after discussing your approach) to submit a PR.
I still agree that FontIcon's style prop should still be the ideal way to set the FontIcon's style inside of a IconButton, however we were able to get the FontIcon size working properly on our project like this:
<IconButton
onTouchTap={this.handleTouchTap}
iconStyle={{fontSize: '18px'}}>
<FontIcon className="fa fa-filter" color={accentBlue}/>
</IconButton>
Material-UI v0.18.0
Thank you @jgreubel! That workaround is rather simple and gets the job done.
We have been porting the component on the v1-beta branch. We reimplemented it from the ground-up. While we haven't tested it, I think that the issue is most likely fixed on that branch. Hence, I'm closing it.
Still, we will accept PR fixes until v1-beta takes over the master branch.
Most helpful comment
@aahan96 Please re-open this issue since it's not already fixed.