I’m studying the directory structure for Quasar projects at https://quasar.dev/quasar-cli/cli-documentation/directory-structure .

I’m wondering about the following simple question: As part of my app, I have developed quite a few commonly used .js files, which contain things like constant definitions, helper functions, data structures to be loaded, etc…

Almost all of these files are Node modules, exporting stuff. Those are imported both by my Quasar components in \src\pages and by MyLayout.vue in \src\layouts.

What is the recommended way where to put those files in the directory structure? I’m aware I can always add new sub-folders under \src, but is there a convention/best practice to follow for such sources?

Ok, the header (in MyLayout.vue) explains the offset when scrolling. Do you have an idea how to achieve a scroll within the page that compensates for that offset? Could I embed a special scroll function into the markdown part for that, like the code snippet you mentioned in an earlier post above?

I have tried anchor links without path in front. For some reason, with my “named route with prop” setup,for Help.vue a local link without path, like

[Test link to scroll to #anchor1](#anchor1)

reloads the app to a default state outside of the help component, without scrolling to anywhere (FAIL).

Even with the “named route with prop” setup for my help component temporarily disabled, the same local link to #anchor1 reloads the app as well (FAIL)!

Also with the “named route with prop” route setup disabled,

[Test link to scroll to /help#anchor1](/help#anchor1)

performs the desired scrolling (PASS - with the mentioned offset though).

Small update: I did a sniff test in which I temporarily disabled the mentioned named route for my help component, both in its definition in Vue routes, and in the surrounding <q-route-tab> of MyLayout.vue:

With this modified setup, the anchor links within the markdown, if specified as “/help#anchor1”, scroll to the anchor destination. This proves that in my case there is some conflict between the use of named routes and those anchors.

But I cannot easily get rid of the named routes in general, as I have a table of content in the left drawer that depends on it. I would have to convert that to anchor links somehow as well, but I’m neither sure whether that is possible nor how to do that.

There is an additional glitch, that the scrolling to an anchor link (with named route disabled) always scrolls a few lines too far, not sure what is causing that additional small problem.

@Hawkeye64 - I still can’t get it working. A small, but probably important difference:

When I test the example anchor link in the new doc you provided, your examples page scrolls to: https://quasarframework.github.io/quasar-ui-qmarkdown/docs#Installation-Types - note the format “/docs#id”, not “/docs/id”.

While in my tests, clicking on the above anchor link

[Test link to scroll to #anchor1](#anchor1)

loads http://localhost:4200/#anchor1 (which, because it is an invalid URL, leads to the mentioned reloading of my Quasar app).

I’m testing on a local setup. Another difference is the special Vue routing logic I described in the first append above. From my existing, “pure” Quasar based version of my help component, prior to introducing QMarkdown, all my scroll destinations have the format: localhost:4200/help/id - note the “/” between"help" and “id”. As far as I remember, this is called a “named route” with the (DOM element) id as a parameter, based on a suggestion from @metalsadman. In routes.js it is specified as:

      {
        path: "/help/:helpTopicElementIdToScrollTo",
        name: "Help",
        props: true, // Vue Router "boolean mode", allows passing of helpTopicElementIdToScrollTo to the component, which has that id defined as a prop
        component: () => import("pages/Help.vue")
      },

So one possible solution would be to change my routing setup to accomodate this “/help#id” rather than"/help/id" - but I don’t know how to do that.

@Hawkeye64 - thanks for your support. I upgraded QMarkdown to the newest level 1.0.11, but have some troubles how to use the newly added anchor link support.

I included the above code snippet as <script> … </script> within the markdown. But so far, I think it is not getting called through my tests.

My “anchor link test” (not sure I use the anchor links in the right way though):

1. Anchor destination within my markdown:

<a name="anchor1">This is my anchor destination</a>

2. Local anchor link within my markdown:

[Test link to scroll to #anchor1](#anchor1)

However, when clicking on that link, my whole Quasar app gets reloaded to its initial default state (which is not the help component loaded prior to clicking the link).

This test result is worse than what I had tried before - let me call it my “local link test”:

1. Link destination within my markdown:

<div id="link1">This is my link destination</div>

2. Local link within my markdown:

[Test link to scroll to /help/link1](/help/link1)

In this case, clicking on the link reloads the app with the help page loaded. After that, scrolling to the link1 destination happens through Quasar code in my help component. In this case, the reloading is undesired, but at least the end result is the desired one.

So I’m not sure how to make use of the new anchor support.

@Hawkeye64 - I’m using QMarkdown as a <q-markdown :src=“markdown”> component with the markdown source imported from a .md file. No use of vmd so far.

I’m trying to use the QMarkdown extension from https://quasarframework.github.io/quasar-ui-qmarkdown/docs to display user help information within a Quasar based help component named help.vue, which has the following characteristics:

• Prior to introducing QMarkdown, the help information in Help.vue has been made up from HTML with embedded divs (e.g. <div id=domIdXyz>) where the ids represent scroll targets for specific help topics.

• Help.vue uses named routes and has a property domId. In routes.js, it is declared as path: “/help/:domId”.

• mounted: code of help.vue scrolls to the help topic in property domId using a Quasar based scroll function (which is able to do what I call “smooth” scrolling).

• If a route change happen (e.g. to “/help/domIdXyz”), a watcher on $route(to, from) scrolls to the DOM element named “domIdXyz” to display the corresponding help topic, using the same Quasar based scroll function.

• Within the existing template of help.vue (a mix of html for the help information and a few Quasar components), Quasar buttons (type=“to”) are used to initiate the same “smooth scrolling” within the help information through the Quasar based scroll function.

That existing implementation works and achieves “smooth scrolling” from one element to another within the overall help information.

Now, with having most of the help information converted to markdown content controlled by (so far one) QMarkdown component in my (changed) help template, I’m having some troubles with how to do scrolling within that markdown:

• As far as I understand QMarkdown, I cannot embed the above Quasar buttons (type=“to” - which would be able to initiate the above “smooth scrolling”) directly into the markdown (.md file).

• So I tried to use links <a href="/help/domIdXyz"> within the markdown to scroll to domIdXyz, but that unfortunately reloads the whole app (which after reloading the help component, scrolls to domIdXyz through the mounted: code). But reloading is not the user experience I want.

• The same undesired reloading happens with local links in the markdown, like

[local link](/help/domIdXYz)

So I would appreciate some advise about how to get links from one topic to another topic within the markdown that scroll within the markdown without reloading the page:

• Use links different to the above <a href=…> links/local links in the markdown?

• Change the described routing logic to deal with it? (however, there is other code depending on it)

• Split the markdown into many markdown files, with Quasar based buttons in between to do the linking? (seems ugly)

Thanks for some hints.

I get the same error message when using type=“html5” and Chrome, newest Quasar and QpdfViewer levels.

Apart from these error messages, QpdfViewer works without issues.

There is a checkbox in the upper left corner of the q-table that is generated by Quasar if you specify selection=“multiple” for the q-table. That checkbox selects/deselects the rows on the current page of the q-table (10 rows in your case).

If you want to select/de-select all rows of the whole q-table (500 in your case), you could add a button which triggers a method that assigns all table rows (from your table data array) to the array of selected rows (specified like in :selected.sync=“selectedRows”). Note that such array operations should always use proper array methods to make Vue aware of the change in the array, e.g. use push in case of adding single rows to the array, or do an assign to the whole array in case you replace all rows, like in this case.

I have not tested it, but believe that Vue and Quasar will get notified of that programmatic change of the selected rows, and will update the checkboxes accordingly to reflect that all rows are selected (across multiple pages). Try it out whether it works.

@metalsadman - well, this is maybe more complicated than I thought. Are you saying:

• if the method/function called does not expect parameters, we can safely use “functionX()” or “functionX”, like in most of my @click=“functionX()” examples.

• if the method/function called requires parameters, using “functionX()” is dangerous (as in my case above), and “functionX” should be used to ensure that the native event’s parameters are used. Alternatively, “functionX(paramA, paramB, …)” can be used? Do you have an example for this last case?