Render markdown text on client-side instead of with github API

[durden]

Benefits

• Reduce amount of data stored in redis cache since storing markdown text is alot smaller than html text.
• Guaranteed consistency with the view of our preview page in the editor view and the rendered markdown view on main guide page because we'd be using the same rendering code.

Downsides

• Our article view page is larger because we need to include highlightjs and marked.

[durden]

@paulocheque What are your thoughts on this? Am I missing any benefits or downsides? See the small changes in the above-referenced commit. I'm not sure my JS approach is very good at all, just trying something out. Let me know if you have any suggestions on the 'proper' way to do something like this rendering on the front-end with marked and highlightjs.

We'd also want to somehow add back the 'octicon-links' to the headers of the page. It's important that users can link others to sections of the guide.

[paulocheque]

Yeah, the rendering responsibility should be in the frontend. Also, it is healthier to put only data in the cache.

Storing html in the cache, changes in the frontend would not reflect immediately in the page.

In summary, all the downsides are not very critical for me and all the benefits are great.

[durden]

@paulocheque and I talked a lot of this over and wanted to note all the good ideas here. First, we should make a new endpoint like the following:

GET /api/article/:id
returns: json with article content

The id would probably be stack/title. This endpoint can then return a JSON response and we fill out the article details with jQuery and something like this:

$('#title').html(data.title)
$('#content').html(marked(data.markdown))
$('#stack').html(data.stack[0]); // only one stack for now

[durden]

We should also consider putting this new endpoint along with the api_save endpoint in views.py into a new file called api.py or something similar so we can have regular views and api 'views' separated. Thoughts on that?

[paulocheque]

Good call to have this api.py file.

[durden]

I rebased the this branch and looked it over. This is a decent start. @paulocheque, you can probably get all the front-end work done with these minimal server-side changes. A few things to note with this change though (as mention in the commit message):

• The automatic headers are removed and we'll want those back.
• We need to heavily test that the look of the rendered articles doesn't change once we render it on the front-end. We might have some CSS, etc. depending on the html that github returns to us. If so, we need to remove that and make sure the article looks the same before and after this change is integrated.
• One thing I've noticed that's different from the JS markdown rendering is it requires a blank space after a header but the github rendering doesn't.
  • For example, ##Test and ## Test render differently between our front-end markdown rendering and the html github returns.
  • This is already an issue on the editor preview, but it's pretty minor.
• I'm guessing there will be more quirks like this which we need to watch out for.