Move all markdown parsing from /vue-strap to /markbind

[ang-zeyu]

Is your request related to a problem?
#889 - larger bundle size increases loading times, which can cause FOUC more frequently

Somewhat related:
#36 - would be a good time to tackle this, while still supporting deprecated attributes ( a quick script can also be written to convert old markbind documents to standardise all attributes )

Currently, the the client is responsible for rendering markdown provided as attributes in vue components ( e.g. modals, panels, popovers, tabs ).

Problems:

1. This may be bloating the resulting bundle size ( yet to test impact ), exacerbating FOUC
2. Impact on loading times due to more client side rendering, especially on large documents
3. ( opinion ) Cohesion & consistency
   3.1 Attribute rendering should be done only when building or purely in the client, not both. Currently, it is also done when building for panel headers for heading indexing. ( boxes if implemented similarly too - x of the dismissible boxes it not at the top-right corner #962 ) This can also make the code more difficult to understand for newer developers.
   3.2 Markdown headers inserted using vue's slots are parsed in /markbind, but those inserted with attributes are not.
4. ❔

Other positive side effects:

1. Easier to accomplish a rewrite for Migrate all MarkBind components from vue-strap to bootstrap-vue #814, with decoupling of /vue-strap from markdown-it.

Describe the solution you'd like
Move all markdown parsing in /vue-strap to /markbind, aiming to remove markdown-it as a dependency from /vue-strap altogether.

Cons if moved:

1. More per-component logic in parser.js ( though, it already has quite a bit )
2. Slightly harder to add new components with attributes requiring markdown parsing
3. Slight increase in build times ( though, it would likely be offsetted by the decrease in loading time due to lack of client-side rendering when using markbind serve )
4. Potentially high initial risk of regressions
5. ❔

[yamgent]

Would definitely be interested in the figures that you can give for this solution. If you are tackling this, go ahead and give this a try for a single component first to demonstrate its feasibility.

The consistency pro is always welcome as a design improvement. I suspect that the current nunjucks and markdown rendering order that we have may cause a bit of issues (since the current design means that the markdown is technically rendered twice), so that is one part that I will specifically look out for when implementing this idea (i.e. whether there are any "un-rendered" parts).

[ang-zeyu]

Will try it out for panels

Here's the result after removing markdown-it from vue-strap though:

Before:

After

[ang-zeyu]

Diff for /markbind (_parse function in parser.js) ( essentially just rendering the markdown and the parsed result into slots )
ang-zeyu@b76c015
Diff for /vue-strap ( just a rewrite of the parts for displaying header / alt content using slots )
ang-zeyu/vue-strap@7e263ea

It seems to be quite feasible so far, though, I'm still looking into whether it can be affected by any other things in the entire rendering process.

I neglected to take into account the impact of passing html instead of markdown ( which is 'lighter' ) on file sizes earlier as well, although it dosen't affect FOUC since it is the html file itself.
The impact should be minimal, and offsetted by not rendering in the client, but its still something to take into account.
( On the test_site which has quite a few panels, the size of index.html increased by roughly 2kb. )

[yamgent]

( On the test_site which has quite a few panels, the size of index.html increased by roughly 2kb. )

I think this tradeoff is reasonable since we can shave off 180kb of vue-strap.min.js and we can offload heavy processing for "low-end" devices (e.g. mobile). You can post a diff of the html for us to see how the 2kb increase is like, though my intuition says that this balance seems to be worth it.

[ang-zeyu]

You can post a diff of the html for us to see how the 2kb increase is like, though my intuition says that this balance seems to be worth it.

ang-zeyu@db2065c
Ignore the change in nav-links at the bottom though, I just realised the code for heading indexing isn't updated yet ( it should stay the same ) 😅
The other dom changes to the panels are as expected

The amount of panels should be rather representative of what a typical page would have, though there are still four other types of components using client md rendering to consider ( box, popovers, modals, tabs ).
Assuming there's the same number of each type, the overhead would roughly be ~10kb.
For reference, this page https://nus-cs2103-ay1920s1.github.io/website/schedule/week1/topics.html is roughly 330kb

[yamgent]

Thanks for your diff and further experiment.

The reason why I was concerned about the overhead is due to the bandwidth issue, as moving the parsing means we can no longer exploit browser caching of vue-strap. If the visitors of the website reads many different pages, and the website has bulky pages (e.g. uses a lot of panels), then we lose the advantage of browser caching, and websites incur more bandwidth in the long run.

However, a 2-10kb as the overhead for the different pages that you have tried seems to be reasonable, especially if it means that we can make the loading smoother (i.e. no FOUC). It is quite a small overhead considering that for GitHub pages, their soft limit is 100GB/month. Some webhosts also claim to provide "unlimited bandwidth", and this overhead is unlikely to be very massive to breach their actual hard limit.

[ang-zeyu]

Thanks for giving it a shot as well!

I'll start working on it then 😆