Make page headings available as a global variable + component-ify the pagenav/toc

[ang-zeyu]

Please confirm that you have searched existing issues in the repo

Yes, I have searched the existing issues

Any related issues?

https://github.com/MarkBind/markbind/pull/2069 (ToC PR discussed below)

What is the area that this feature belongs to?

No response

Is your feature request related to a problem? Please describe.

Page headings are currently used in the page nav.

There is also one use case for ToC's here https://github.com/MarkBind/markbind/pull/2069.

Describe the solution you'd like

Consider making the page headings vailable as an internal MarkBind global variable instead. And/or, provide/inject this. (no strong preference)

This allows separating the data and presentation for reuse more easily.

The page nav is currently used in 3 areas:

• <page-nav>'s underlying implementation, which can be made a vue component (currently not very readable)
• toc (<page-nav-print>) which can be probably be collapsed feature wise into the same component (breaking change)
• mobile page nav button (may or may not benefit from further simplification)

Describe alternatives you've considered

No response

Additional context

No response

[ang-zeyu]

Hi @tlylt, I haven't taken a look but this could be helpful for your ToC PR.

[tlylt]

Hi @tlylt, I haven't taken a look but this could be helpful for your ToC PR.

Hi @ang-zeyu, could be useful to TOC but since I am currently not touching the pagenav implementation in my PR, may not be very relevant for that.

Some clarifications to scope out this issue:

• the global variables are global per page, or per site?
• the global variable is just for internal use? could it be useful for site creator, or both?
  • could this be implementation details that subject to further experimentation? or what's the advantage of having them when implementing?
• besides toc, what problem/use case is there for page headings as variable?

[ang-zeyu]

• per page
• just for internal use, i think for the pagenav and your toc work. Disregarding toc, the motivation would be to refactor pagenav into a vue component to make things easier. But it could be useful for toc too. Let me know if i didnt get the sub question here correctly.
• The motivation here is just for pagenavs currently (and toc), but if you come up with anything please file a follow up 💯

global variable

i prefer vue's provide inject if possible, this would make it semantically accessible to vue components and make it internal naturally. But its not a strong preference.

[SPWwj]

Could you illustrate how you utilize "page headings" as a global variable? This will help us comprehend the problem more effectively.

I believe global variables are server-side components that require server processing. In the Vue.js context, I can only think of Axios, though that seems a very bad idea.

However, if the variable's scope is limited to the page, Vue.js does offers some advantages, but it wouldn't qualify as a global variable.

[ang-zeyu]

Something like this https://github.com/MarkBind/markbind/blob/master/packages/core/src/Page/page.njk#L38. Just a browser global variable, without anything to do with Vue.

You may have to use provide/inject as well to ensure the data is available during SSR.

Feel free to explore any other ideas to improve the code quality too! The general idea would just be to separate the data and presentation layers more cleanly for reuse.

I've also updated the issue description to include the mobile page nav button. https://github.com/MarkBind/markbind/blob/master/packages/vue-components/src/PageNavButton.vue. You can try tackling them (main page nav, mobile page nav, ToC) in separate PRs as well if possible, if it is too much for one.

[SPWwj]

Something like this https://github.com/MarkBind/markbind/blob/master/packages/core/src/Page/page.njk#L38. Just a browser global variable, without anything to do with Vue.

You may check out for pr #2315

This issue seems somewhat related. Importing an extra Vue framework is unnecessary for our purpose. It would lengthen initial loading times due to additional client-side library downloads. Although Vue components simplify code base identification, combining CSS, HTML, and code in a single file can lead to confusion.

Furthermore, allowing users to use pure markdown syntax eliminates the need for them to learn the Nunjucks syntax or use the HTML tag .

[ang-zeyu]

This issue seems somewhat related.

Not sure how it is. 👀

{{ pageNav }} variable, which can be made a vue component (currently not very readable)

Sorry as I may have confused you with this part in the issue description.

It should be <page-nav> element (it was once a variable, but has been changed). The change here would just be in the form of the underlying implementation for code quality.

There should be no extra Vue frameworks necessary either, let me know if anything in the issue is unclear.