Unable to use with large content

[mqtik]

Hi. Before we talk about what's the best way to implement an editor in RN, and if this way is the proper way.

It is the proper way; however, there's a big issue here, when the object is too big to the editor to handle.

I thought to split the content on the server side, and that's an option on my end, but as the user end goes, it's not the best solution. The user can write a long, long text and it will happen again.

What can we do about this?

[mqtik]

We might need to limit the .map of the TextInput

_.map(items, item => (
    <CNStyledText key={item.id} style={item.styleList} text={item.text} />
 ))

And load more as the scroll goes down

[mqtik]

@imnapo what you think we should do about this?

I'm thinking of adding a library like https://github.com/bolan9999/react-native-spring-scrollview And considering some other workarounds...

[mqtik]

Note: It works if I partially render the data. Like with lodash, I'd use some sort of _.take(items, 20)

But of course, the rest gets cut off. We would have to use the position of the scroll, but that leads us to a tricky problem, since the editor works with nested objects.

We would have to limit the components, and its contents, using the scroll as the parameter. (or maybe use FlatList instead of ScrollView, with a PureComponent) Since I'd like to pull request all the changes, I'm waiting for some feedback on how would you guys rather do something like this, since it's a MAJOR problem..

I'm also thinking that maybe it's not the editor's problem (or at least not directly). The data it's too big for anything to ble able to handle that amount of content.

But it might be nice to look out for some sort of performance boost.

[imnapo]

Hi @mqtik , First of all thanks for your active contribution. We also think rendering data partially and load more as the scroll goes down is not easy to implement as you mentioned. But dividing content into smaller parts and using FlatList may be the solution. as you may consider each item in array ( text component ) renders in a single Textinput. So dividing the content will generate multiple Textinputs. In this case we'll lose selecting all text feature. But It should solve performance problem. We will think about find another solutions. But you feel free to make pr for that.

[mqtik]

Right! We can't lose selecting text feature..

Hhmm, this might be hardere than I expected..

I think we'll have to put some thought into this and don't rush it so fast, since the whole point of the library is to be editable.

I'll put some time in the following weeks into thinking some method to solve performance problem without losing any features. I'll try the FlatList too, although I'm having problems getting my head around it (mostly where to place it — CNRichTextEditor / CNTextInput / Outside the library (when calling component CNRichTextEditor)

[mqtik]

Hi @mqtik , First of all thanks for your active contribution.

Thanks to all of you guys for all the hard work you continually put into the project!

[mqtik]

But dividing content into smaller parts and using FlatList may be the solution. as you may consider each item in array ( text component ) renders in a single Textinput. So dividing the content will generate multiple Textinputs. In this case we'll lose selecting all text feature. But It should solve performance problem. We will think about find another solutions. But you feel free to make pr for that.

Maybe we could use this in the RichTextView component. I'll definitely take a look at it. I have been playing around and with FlatList comes a weird behavior when selecting text, which's not cool.

I'll have to dive into it a bit more..

[mqtik]

@imnapo I'll implement the FlatList on the RichTextView (not editor), but I'm really concern about what we would have to do about the editor.. Any ideas are really appreciate.

[mqtik]

Note: The select is completely broken on FlatList (in rich editor and viewer)

[mqtik]

It's amazingly slow with large content. Damn!