react-native-simple-markdown
react-native-simple-markdown copied to clipboard
CharlesMangwa
Single line break breaks layout
A single line break \n somehow breaks the layout leading to very strange spaces. Expected behavior would be that it is just ignored.
Interesting!… Did you dive a little bit into the code to see what could possibly be the root caus of this behavior?
@CharlesMangwa I have the same problem! But not with '\n', it actually has an ALT-ENTER there (most likely same behavior as '\n')
The rendered markdown is the following:
**Spa Mud in Rasul 30’** The Rasul Spa Treatment which is an ancient Arabic bathing ritual offers you a great relaxation. The treatment uses mineral-rich mud along with heat and steam. It targets all five senses by using light and sound effects. **Indian scalp massage 45’** A form of relaxation massage that focuses on face, head, neck, shoulders, upper back and upper arms, which are important energy centers within the body.
These are the styles of the markdown element:
styles={{
resizeMode: 'contain',
listItemBullet: {
fontSize: 16,
// lineHeight: 20,
marginTop: 0,
...this.props.styles.listItemBullet,
},
text: {
fontSize: 16,
color: 'gray',
fontFamily: 'Roboto-Light',
...this.props.styles.text,
},
paragraph: {
flexWrap: 'wrap',
flexDirection: 'row',
alignItems: 'flex-start',
justifyContent: 'flex-start',
marginBottom: 10,
...this.props.styles.paragraph,
},
}}
I’m not sure anymore we were looking at several issues and tracked them down to simple-markdown, which (surprisingly) seems quite buggy and unstandard so we decided everything based on it doesn’t make sense found a custom marked based markdown parser that returned an AST and then build the markdown rendering ourselves. The markdown rendering is the easy part anyways.
Maybe @devey has some more insights where he tracked down the issue but it was just one of several issues of simple-markdown we found.
@CharlesMangwa Do you happen to know what causes it? It is there and we cannot change the content... Thanks!
Simple markdown the underlying markdown parser from khan academy caused it because it doesn’t properly work. So there’s little to do about it apart from finding a better markdown parser.
@MrLoh As mentioned in #75, I’m planning to change the parser for all the reasons you’ve mentioned. Do you remember the parser you used or do you recommend any of them for this library?
I used this parser which is based on marked. https://github.com/tradle/rn-markdown-parser. But there were some issues with that even which I just solved through post processing. It’s all not very ideal.
Remark (which is also extensible) looked most promising but I couldn’t get it to work on React native and it seems quite heavy. Writing a custom transformer to turn the output from marked into an AST or getting remark to work are the best option in my opinion.
I created this issue on remark but the author didn’t understand the issue, he probably never worked with RN https://github.com/remarkjs/remark/issues/310
I created a gist with my markdown code:
https://gist.github.com/MrLoh/b6142cde26d49d8f080a37f59fa22b06
The markdown-parser generates the AST based on rn-markdown-parser. It’s a little customized for my needs with thinks like an image block.
The Article is how I render it (pretty straight forward similar to this library)
Ideally the post processing of the tree from rn-markdown-parser would just be a modification to that library. But that was beyond the time frame of about a day since the library code was hard to understand.
Hello,
Is anybody trying to add a solution in the current code for this issue? Unfortunately, we get the following result which is very problematic for users:
Thank you for any feedback!
@afilp I just manually added a method to convert single \n to double like this.
addLineBreak(content) {
const newContent = content.replace(/\n/g, (m) => {
return m + m;
});
return newContent;
}
<Markdown blacklist={['list']}>
{this.addLineBreak(content)}
</Markdown>
I guess It is the easiest way to handle this problem for now.
@sibelius We get this data from a server fetch, so we cannot write them differently. We can only do a post-fetch replace, as @khsily proposed.
But, couldn't this problem be solved in the library level instead? So that end users like us do not have to think about it? Unfortunately, I cannot contribute to that because I do not know the internals well.
Thanks anyway!
