0

I'm coding a chat application, and it's gotten a bit more complex, since I want it to have features such as delivery confirmation, message caching and so on.

Right now, the way I'm handling message caching is:

  1. User clicks conversation

  2. First batch of messages fetched from the server is stored in a "chunk", inside of an array.

  3. Each chunk is a document fragment with n number of messages (DOM elements) appended to it.
  4. When the user scrolls up, more chunks (fragments) are added to the array, as they are fetched from the server.
  5. When the user goes to another conversation, but then decides to load a previously loaded conversation, the script appends all fragments into a single one, and the big fragment is appended into the messages window.

This is how an array with message "chunks" would look like if the user has already fetched plenty of messages:

conversation[2].chunks = [
    #document-fragment,
    #document-fragment,
    #document-fragment
];

Each fragment has about 10 messages appended inside.

Before using fragments, I was using strings, by getting the HTML representation of each message. Something like this:

conversation[2].chunks = [
    '<span class="msg">Hey</span><span class="msg">Hey</span>...',
    '<span class="msg">Bla</span><span class="msg">bla</span>...'
];

I decided to use fragments since I found manipulating each message easier (by doing stuff like fragment.getElementById), versus having to use innerHTML to parse the strings and manipulate the elements.

However, I'm now questioning whether it was the right choice, since I don't know if keeping fragments inside of an array is actually memory-intensive, or at least more memory-intensive than strings. The other downside is that now, if I want to store the fragments in localStorage, I'd have to convert each fragment's content to HTML strings, and when I want to use localStorage along with my fragment system, I'd have to convert each HTML string back to document fragments.

Using fragments seemed more natural, but now I'm thinking of going back to keeping the HTML strings. It's a bit of work, though, since I don't have the old code anymore.

Is there any advantage of using fragments over HTML strings in this case?

Thank you.

J. Doe
  • 3
  • 2
  • 1
    Did you try with JSON? JSON is better, because you could handle data structure with less length in the data transfer in a network. – Danny Fardy Jhonston Bermúdez Sep 05 '15 at 18:04
  • Hmm, well, all of the data is transferred in JSON. I could store the JSON strings client-side as well, but then I'd have to build the messages' HTML every time I wanted to display them in the UI. What I'm doing right now is building the HTML from the JSON once, and then deciding whether to store that HTML in fragments or in strings. Or maybe I am getting the suggestion wrong? Thanks. – J. Doe Sep 05 '15 at 21:42

1 Answers1

0
  1. Saving batches of messages as chunks of HTML strings is faster than saving chunks of document fragments (see jsperf), but
  2. Reading chunks of Document Fragments for displaying the messages is much faster than reading (and parsing) HTML strings for displaying (see jsperf)

It can be suggested that:

For faster caching of messages as they are received from the server, messages should be cached as HTML strings.

For much faster displaying of the messages after they are cached, messages should be cached as document fragments.

jczimm
  • 360
  • 3
  • 11
  • Thanks for the tests. I guess I'm going to mix both ways, I hope it doesn't get too messy. – J. Doe Sep 05 '15 at 21:44
  • Because fragments can not have innerHTML the html must be converted back to objects in document fragment! Why not just innerHTML once for all instead of appendChild the fragment? –  May 29 '19 at 17:12