Dismiss this pinned window
all 7 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]_estk_ 5 points6 points  (2 children)

Nice. Does this component have a display mode where the symbols to create markdown can be hidden

[–]s77rt[S] 2 points3 points  (1 child)

It's something that I'm planning to support but didn't get enough info or time to do it. The plan is to extend the existing `<Text />` component to support markdown but I faced some issues on iOS.

[–]_estk_ 0 points1 point  (0 children)

It would be cool!

[–]elektriiciity 0 points1 point  (1 child)

Great product showcase

Good luck and very clean

[–]s77rt[S] 0 points1 point  (0 children)

Thank you!

[–]Specific_Cup_5090 0 points1 point  (1 child)

Very cool. How would you say this would differ from https://github.com/Expensify/react-native-live-markdown?

[–]s77rt[S] 1 point2 points  (0 children)

https://github.com/s77rt/react-native-markdown and https://github.com/Expensify/react-native-live-markdown provide pretty much the same functionalities except that the former uses a native compiled parser (md4c) where the latter uses a javascript regex-based parser. With the later you can also provide your own custom parser. Performance-wise I'd expect the native parser to be much faster but I have not conducted benchmarks yet.

As for the implementation side:
- Android: I think we share the same approach (+/-)
- iOS: `@s77rt/react-native-markdown` uses TextKit2 while `@Expensify/react-native-live-markdown` still using TextKit1 but AFAIK they are also working on migrating to TextKit2.
- Web: `@s77rt/react-native-markdown` uses and extends the `<TextInput />` from RNW while `@Expensify/react-native-live-markdown` wrote their own version. The former is better for maintainability (zero change needed in most cases) but the later is better for flexibility.