vincerubinetti
commented
5 months ago For the 3 options listed above...
- This is probably the easiest. Minimal setup, and blog post authors get a WYSIWYG editor, no coding or git or repo required.
- A completely separate site and repo, e.g. Jekyll site hosted via GitHub Pages. Very easy to do and set up. This would require people to write the blog posts in markdown. The look and feel of the website would look much different from the main monarch site, unless someone took the time to make whatever template you use look similar.
- This would be the most effort of these options, but would also be really slick. I actually think it's easy enough for it to be worth the effort.
Here's some ideas of how to to implement the 3rd option.
First, have a new repo like monarch-initiative/blog with some .md blog post files, a single .txt file listing all the.mdfilenames, and a readme explaining how to author posts. Having it be a separate repo is essential. If it were baked into themonarch-app` repo, you'd have to wait for PR reviews and the production release cycle. Keeping it separate also reduces the chance of a post author messing something up with the app.
Then, in the app, you'll have two new routes: /blog and /blog/:id.
On the /blog page, you'll have a full listing of posts. To get this, first create a new function in /api like getBlogPostList. In the function, you need to first request the raw text content of the .txt listing file in the blog repo. We need this listing file because we can't look up all the .md filenames automatically with the GitHub API, because it requires an authentication token, which cannot be safely stored in the bundled webapp. Each line of the .txt file will have a filename like some-post, which gives you a corresponding raw GitHub file like https://raw.githubusercontent.com/org/repo/main/some-post.md.
For each post, get its raw text content (using request again) and parse its frontmatter with micromark-extension-frontmatter (needs to be installed and hooked up). Each post can have
a front matter with whatever metadata the author wants to add. I'd recommend making authors provide: title, author, description/excerpt, date (date first published), updated (date last updated), tags (topics), thumbnail (url/filename to thumbnail image in the blog repo).
After all that, you'll use useQuery to run getBlogPostList on the /blog page (in the same way that the home page is currently doing it for the Medium articles). Now we we have everything we need to make a nice top-level list of posts in the main Monarch app, which is retrieved live/fresh every time someone visits the /blog page (but automatically cached thanks to request if the user to another page within the app and back to /blog). The list could look similar to how the Medium article list on the homepage looks like right now: just displaying the high-level metadata in a nice way. You could put a search box above the list with AppTextbox that filters the list reactively/in realtime. You may want to have aforementioned getBlogPostList parse the body/content of each .md post too, so that can be searchable here. You could also display a list of de-duped tags in pill buttons like this.
Then, on the /blog/:id page, you'll look up and display the data of one specific blog post. First get the :id from the url with useRoute and params in the same way we do it on the node page. Then pass the id to another new /api function getBlogPost which looks up that specific file in the blog repo, and both parses its frontmatter and converts its body/content from markdown to html (with the already installed micromark package). Now you have everything you need to display a nice blog post page like this. You can display things like the title, author, updated date, etc. at the top. And then you can display the content of the post simply like <div v-html="post.html"/>.
A side note, you can probably delete the AppMarkdown component. Currently, if you follow the trail, this component is only being used to display publication.journal and publication.issue on the publications page, and I don't even see any markdown in publications.json at all, so this is unnecessary.
A caveat of this is that you'd only be able to use markdown and thus regular html elements. Couldn't use our custom components like AppAlert or AppAccordion or AppSection without a much bigger lift to integrate something like mdx-js/vue. But, I think I've already written global styling for most general HTML elements that you'd use in frontend/src/global/styles.scss, so markdown will still look like it blends in with the rest of the app.
I'd recommend copying over everything you've already posted on Medium to this new blog, and get rid of the api code currently in the app for looking up the Medium articles
You also might want to generate an RSS feed somehow, if people still want that.
It has been agreed upon that we will be moving away from an externally hosted blogging site for our Monarch Blogging needs. Details of what that will look like are currently being investigated. Options that have been presented are:
The lead option at this moment is GH pages with potentially having someone set up a streamlined G-docs to md workflow that only requires quick, manual checks.