React-native: lineHeight doesn't work in TextInput

[mikollo]

For example when I set lineHeight style for TextInput it has no effect on app (and no warning is being shown aswell).

[facebook-github-bot]

Hey mikollo, thanks for reporting this issue!

React Native, as you've probably heard, is getting really popular and truth is we're getting a bit overwhelmed by the activity surrounding it. There are just too many issues for us to manage properly.

• If you don't know how to do something or something is not working as you expect but not sure it's a bug, please ask on StackOverflow with the tag react-native or for more real time interactions, ask on Discord in the #react-native channel.
• If this is a feature request or a bug that you would like to be fixed, please report it on Product Pains. It has a ranking feature that lets us focus on the most important issues the community is experiencing.
• We welcome clear issues and PRs that are ready for in-depth discussion. Please provide screenshots where appropriate and always mention the version of React Native you're using. Thank you for your contributions!

[geirman]

To add to @mikollo's issue, I've created an example on RNP
https://rnplay.org/apps/F75ppA

Here's the code...

var SampleApp = React.createClass({

  render: function() {
    var loremText = "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque quis lacinia sapien, in bibendum est. "

    return (
      <View style={styles.container}>
        <Text style={styles.lorem}>
          {loremText}
        </Text>

        <TextInput style={[styles.lorem,styles.input]} multiline="true" value={loremText} />
      </View>
    );
  }
});

var styles = StyleSheet.create({
  container: {
    flex: 1,
    paddingTop: 30,
    alignItems: 'center',
    backgroundColor: '#d3c012',
  },
  lorem: {
    textAlign: 'left',
    color: '#000',
    fontSize: 19,
    marginBottom: 5,
    lineHeight: 50,
  },
  input: {
   marginTop: 50,
   padding: 5,
   height: 150, 
   borderColor: 'purple', 
   borderWidth: 2,
  }
});

AppRegistry.registerComponent('SampleApp', () => SampleApp);

And here's a screenshot...

[katrinanova]

Some other styling doesn't work for TextInput, so far I encountered:
fontStyle: 'italic' - doesn't do anything,
textAlign: 'center' - shifts it to the right side

[arasmussen]

Me too, made a post on Product Pains. https://productpains.com/post/react-native/textinput-lineheight-not-respected/

[grabbou]

@katrinanova that is being fixed in https://github.com/facebook/react-native/issues/2140 (related PR: https://github.com/facebook/react-native/pull/7186)

I can't reproduce the lineHeight issue on current master, here's the UIExplorer picture:

If OP or @arasmussen could check if it's been solved, it would be great

[geirman]

Awesome if that this is fixed on master. FYI: It's not working on v0.24.1

[roman01la]

I can confirm that this issue is still present in RN 0.30. Setting lineHeight on multiline TextInput changes height of the element itself but doesn't change spacing between lines of text.

[geirman]

@grabbou Your screenshot from April 24th only confirms what @roman01la verified, that lineHeight affects the height of the element, but not the spacing between the lines. Were you able to verify with multiple lines of text as well?

[grabbou]

Nope, I've never had such need unfortunately. If you could try adding a broken multi-line demo to UIExplorer inside a PR, that could help fixing it?

[geirman]

@grabbou is that really necessary? I provided a copy/pastable example above with a linked example https://rnplay.org/apps/F75ppA

[lacker]

That rnplay link does not work for me, and the issue is old, and some of these issues appear to be resolved, so I am going to close this. I think folks should feel free to open a new issue if we have a working repro link for a specific still-existent problem.

[geirman]

The rnplay link uses the require method of including dependencies. I've created a fresh example here https://rnplay.org/apps/TYBoBw

That said, I'm disappointed by the trend to close issues that aren't actually fixed, moving some to product pains. Just because they're old doesn't mean they're no longer a problem. I get that it's tough to keep up with so many issues. Many very useful PRs have gone stale for the same reason. But closing them without actually fixing them or merely moving them to product pains essentially just "sweeps them under the carpet". out of sight, out of mind. They still exist, so someone else will be forced to file a "fresh" issue at some point.

I'd love to see a better effort to actually fix issues. This would probably have to start with a strategy which tackles PRs more aggressively. I believe the community would be more likely to fix the issues if they were confident their fixes would land. Furthermore, I believe the community is more than willing to jump in and help, but someone has to organize the masses so that we're all working in concert with one another. I don't know how to go about this, but I'm confident we have more than enough manpower...which means we're severely lacking in leadership.

[lacker]

I totally agree.

For issues - we closed about 400 issues over the past week and a half, so I think it's inevitable that some will be mistakes and should actually be open. Some kind of get "stuck", like this one is marked as needing a response from the author. In this case it is great that you have an updated repro. Would you mind just filing that as a new issue? - I think it will just be very hard to take action based on anything buried this deeply in this issue.

But overall pull requests should be the highest priority. The lost value from a good pull request going stale is much higher than the lost value from a good issue going stale. From Oct 19 - Oct 28 we've gotten from 210 open PRs to 157, which I would still describe as "not good" but it's a decent step in the right direction. Part of that has been closing stale pull requests but another part has been pinging the right code reviewer, or making sure we provide the simple feedback quickly like getting through CLA and continuous integration problems.

Are you interested in helping out here, perhaps in some community-organizey way? If yes, feel free to email me at lacker at fb dot com.

[geirman]

I'd be happy to open a new issue. That makes sense.

And yes, I'd be happy to help out in anyway I can. I've signed up at codetriage.com, but that only has limited impact. I'd love to be part of something more organized, a united front... rather than a bunch of us running around and independently trying to do something, and oftentimes doing it differently. Much like rowing a boat, we will go farther faster if we all stroke in unison together.

Regarding the PRs, I'd focus on incoming PRs. We should land any new PRs as quickly as humanly possible. It will take much longer to land older PRs since they'll likely require rebasing, which may not be that simple. By landing new PRs quickly, we set ourselves up for success going forward. We'll lose a lot of great work, but overall this should work in our collective favor.

Just my 2 cents. I'll send you an email, and if you agree... I'd be happy to help.

[arasmussen]

Hey guys, just noticed this thread. I'd love to at least subscribe to any thread regarding React Native and feature requests / bug reports. I don't want Product Pains to be a place where ideas go to die... Agree the issue experience could be better, let's figure out something that works.

(I made Product Pains)

[dmr07]

Issue present in 0.45.0

[cjcheshire]

So for those still having this problem - @dmr07, I found this solution worked for me - https://stackoverflow.com/a/37882782/4392314. Ensure you set paddingVertical: 0

[luco]

@cjcheshire Thanks a lot. Combining this with lineHeight got me the desired result.

[SeanChenU]

For temp solution, I wrap <Text/> in <TextInput/>. Make sure the <TextInput/> doesn't specify value props.

<TextInput
  onChangeText={(text) => {this.setState({content: text});}} 
  style={{lineHeight: 28}}>
  <Text>{this.state.text}</Text>
</TextInput>

[fighting300]

preset in 0.48.0