Schema for Content

[NathanBland]

I need a model for the content of a post.

This will be useful for several reasons. The primary one being creating rich text content off of it.

My initial thought is to use an array of content...

So content would end up looking like:

{
content: [content],
contentType: String
}

This way, we can say I have a post with a video, and a title, and a link.

So in this example, my content would end up being:

{
content: [{
  content: 'http://youtube.com/<something>,
  contentType: 'webremix'
},
{
  content: 'The video title, also check out',
  contentType: 'text'
},
{
  content: 'http://google.com',
  contentType: 'link'
}],
contentType: 'post'
}

This gives us the ability to just submit a single bit of content, as before, and have it work OK, but create more dynamic content if we wish...

Thoughts?

[keawade]

I don't think we should bother. I think a post should just be a string. We can then parse that string on render to look for urls, determine the content type, and potentially display a preview.

Multiple urls would result in the first one being parsed and the others being ignored.

[NathanBland]

What about handling things like "@keawade" or #uselessPost?

[keawade]

I'm not sure. Maybe we could just assume a local link and add it? I'm not convinced that the intial spec proposed here solves this problem either.

[NathanBland]

how would you determine what to link?

It has the potential to do so... take the example with the @keawade

{
"content": [{
  "content": "@keawade",
  "contentType": "userTag"
},
{
  "content": ", I think this is really interesting. But it probably isn't ",
  "contentType": "text"
},
{
  "content": "#uselessPost",
  "contentType": "contentTag"
}],
"contentType": "post"
}

Then, if you have a component architecture, you just look through the content array injecting your components. If you don't have that structure, you just concatenate the content array back into your string.

It seems overly complex, I know, but I haven't thought of a better parsing strategy.

[crodeheaver]

I don't think we should bother. I think a post should just be a string. We can then parse that string on render to look for urls, determine the content type, and potentially display a preview.

The advantage of this is that we won't have to worry about it server side. The downside is that we now have to have a parsing implementation on each client.

Either way, parsing can be a real nightmare. haha. I'm not sure there's going to be a simple implementation. I'm not against either of the current ideas.

If we define a list of accepted contentType, create a standard for parsing them (regex?), a standard for handling them, then I think that covers our bases.

The question is client side or server side?

Edit: I'd also like to point out, doing it on server will decrease likely hood of differences in client side interpretation.

Edit: Looking back I realize I misinterpreted what you were going for. Now that I see the error of my ways, I'm gonna say it has to be server side. Because you're right, how else do you handle @NathanBland and notifications for that sort of thing?

[NathanBland]

I'm suggesting that clients parse the data to an extent, aka to determine the type of each of the chunks. Then send those chunks to the server. In this way, the server can then determine if things like notifications need to be created.

I'm open to other ideas for doing this, but at this point, I'm not sure another solution exists.

[keawade]

I think Twitter's API could be a helpful reference here: https://dev.twitter.com/overview/api/tweets

EDIT: Also the Twitter API's entities: https://dev.twitter.com/overview/api/entities

[NathanBland]

Indeed, however, their solution looks even more complex to me... They parse the tweet, and create things they call entities for things like hashtags and user-mentions: https://dev.twitter.com/overview/api/entities

If you thought what I was suggesting was overly complicated... this is on another level...

[keawade]

It may be complicated, but this is a pretty complicated problem we're trying to solve. I think a similar system with a short list of entities would likely be our best option to get the functionality we need.

[NathanBland]

I'm suggesting we basically compose our messages of a schema similar to this, so that we don't have to mess with a sub-object type like entities creates.

If you have the message Hey @keawade, check out this video: https://www.youtube.com/watch?v=s6MwGeOm8iI

In what I am proposing, your schema would look pretty simply, assuming you follow the schema I'll list:

postSchema = mongoose.Schema({
  contentType: String,
  content: [contentSchema],
  author_id: {
    type: mongoose.Schema.Types.ObjectId,
    ref: 'user',
    required: true,
    index: true
  }
}, {
  timestamps: true
})

contentSchema = mongoose.Schema({
  content: String,
  contentType: String
})

Given this schema, the post would look like:

Hey @keawade, check out this video: https://www.youtube.com/watch?v=s6MwGeOm8iI

{
contentType: 'post',
content: [
  {
    contentType: 'text',
    content: 'Hey '
  },
  {
    contentType: 'userTag',
    content: '@keawade'
  },
  {
    contentType: 'text'
    content: ', check out this video: ',
  },
  {
    contentType: 'video',
    content: 'https://www.youtube.com/watch?v=s6MwGeOm8iI'
  }
]
}

To me, this seems easier, on all sides, rather than having even more fields and schema that must be populated... I don't really want to mess with storing indices for each rich content portion of a message, especially when i don't think we need to.

[keawade]

Alright. I think we may want to limit to contentTypes of text, userTag, hashTag(?), and url. Urls could then be parsed in special ways depending on source (YouTube, Vimeo, Imgur, etc).

[NathanBland]

I am ok with this ^^

@crodeheaver ?