Querying HTML strings w/white space in Mini-Mongo

help
1

I have this issue with querying a string with spaces in it.

With a Editor input like this (with white spaces):

And code that looks likes:

// inside template event

var editorContent = instance.find('[id^=ql-editor-]').innerHTML;
var filteredMsg = UniHTML.purify(editorContent);

…
// now I save this off to Mongo…

// have a tracker on the publish so after the insert the subscription gets refreshed and the helper is called again
// inside template helper

  user_messages: function() {
    var user_id = Template.instance().user_id;
    var records = messages_detail.find({
      user_id: user_id
    }, {
      sort: {
        created: -1
      }
    });
    // here records.fetch()[some_index].message won't have the extra spacing.
    return records;
  }

…

// template html

{{#each user_messages}}
   <div class="contents regular">
      {{{message}}}
   </div>
{{/each}}

The results look like this:

Where their should be more than one space between wow and very.

The strange thing is that the Purifier IS keeping the whitespace!

If I go to the Browser console, using Mini Mongo, typing in:

messages_detail.find().fetch()[the_proper_index]

I get a record like so:

<div class="ql-multi-cursor"/>
<span class="cursor hidden"><span class="cursor-flag"><span class="cursor-name" style="background-color: rgba(255, 153, 51, 0.901961);">Gandalf</span></span></span>
<div class="ql-editor authorship ql-content"/>
<span class="author-test">wow very cool!</span>
<div class="ql-paste-manager"/>
<br/>

A string without the spaces.

But if I go into meter shell (the server side) and type in the same thing:

messages_detail.find().fetch()[the_proper_index]

I get a record like so:

<div class="ql-multi-cursor"/>
<span class="cursor hidden"><span class="cursor-flag"><span class="cursor-name" style="background-color: rgba(255, 153, 51, 0.901961);">Gandalf</span></span></span>
<div class="ql-editor authorship ql-content"/>
<span class="author-test">wow   very cool!</span>
<div class="ql-paste-manager"/>
<br/>

A string with the spaces.

Why would the white space in the HTML string be remove inside Mini-Mongo?

3

This has been bugging me for a while and I finally decided to have a bit of a play.

Visually, my results were the same as yours. However, I took a look at the rendered element in the web inspector and lo and behold the multiple spaces were there. It appears that the fault lies not with minimongo doing weird stuff, but with the web inspector “tidying up the output”.

I did discover that if I reference the specific field it will show the multiple space, so while

 messages_detail.findOne()

collapses the spaces,

messages_detail.findOne().content

shows them (I used “content” as the property name of the HTML).

4

So base on your analysis, what is your conclusion? That I should reference the field explicitly in order to preserve the white space?

If that’s the case it will make my life hard because I have a cursor with many records that contain this HTML content. And I use a Blaze #each to iterate over the cursor and display the HTML message like so:

{{#each user_messages}}
   <div class="contents regular">
      {{{message}}}
   </div>
{{/each}}

The messages above is the HTML content that sometimes contains white spaces. But what I removed from the code above is that there are other fields in the record that I use within the #each. It would be hard to single out the field in the cursor is my point I guess.

5

No, I don’t think so. As far as I can see, the spaces are present in the data as you expect them to be. If you use Chrome’s web inspector to see them you will have to reference the field explicitly. Otherwise, as far as Meteor is concerned they are there and will be written to the template as expected.

I copied your example text and inserted it on the server into a collection.

On the client I used a template helper to render the data from the (now in minimongo) collection.

Here’s what I see on the browser:

No spaces - right? But here’s what the web inspector shows:

And there are the spaces as expected.

6

That’s great, so how do you think I should go about actually getting the spaces to appear when rendered?