Nice! @rstoenescu

@tim
hmm: British, small team, public-funded, 30 years of “service” - definitely looks to me like a front for secret operations

But honestly, I’m very glad that you chose quasar. GPLv3 or not, it seems that IT is your way of life. Life as a whole. Greets!

Hmm ViewScript looks quite promising, but this license - GPLv3… why?

web worker? something like:

https://github.com/hbi99/defiant.js

it gives at least x10 speedup in json search.

(I assume you have 23K rows in memory not on the server)

@rstoenescu

Sure, had a little time, so I created PR for you:

https://github.com/quasarframework/quasar-framework.org/pull/579

anyway, I’m quite afraid that documentation and code in quasar may be a little off-sync. I wonder what procedure would guarantee that when there is a code commit or feature request, there is also a documentation update? (and unit test?) (and example?)

@rstoenescu

great update! wow!

little info - in uploader documentation marked as “docs for 0.17.9”:
https://quasar-framework.org/components/uploader.html

there’s no mention about new filter property from #1458:
filter (files) {
…
return filteredFiles
}

@rstoenescu
hi,

I think you’re right that it is not a QToolTip. I created a jsfiddle

https://jsfiddle.net/unLms60y/59/

with this html:

<link rel="stylesheet" type="text/css" href="https://unpkg.com/quasar-framework@^0.17.0/dist/umd/quasar.mat.min.css">
<script src="https://unpkg.com/quasar-framework@^0.17.0/dist/umd/quasar.mat.umd.min.js"></script>

<div id="q-app">
<q-btn @click="fetchData">first load</q-btn>
        <q-table
          title=""
          :data="produkty"
          :columns="columns"
          row-key="id"
          :pagination.sync="pagination"
          :rows-per-page-options="rowsPerPage"
          separator="horizontal"
          dense
          @request="requestDataTable"
        >
          <q-tr slot="header" slot-scope="props">
            <q-th v-for="col in props.cols" :key="col.name" :props="props">
              <strong>{{col.label}}</strong>
            </q-th>
          </q-tr>
          <template slot="body" slot-scope="props">
            <q-tr :props="props">
              <q-td key="id" :props="props">
                {{props.row.id}}
                &nbsp;<q-btn round dense icon="add_shopping_cart" color="primary" small @click="cartAdd(props.row)"><q-tooltip>add to cart</q-tooltip></q-btn>
              </q-td>
              <q-td key="title" :props="props">{{ props.row.title }}<br><small class="text-dark">({{ props.row.url }})</small>
                &nbsp;<q-btn round dense icon="add_shopping_cart" color="primary" small @click="cartAdd(props.row)"><q-tooltip>add to cart</q-tooltip></q-btn>
              </q-td>
              <q-td key="url" :props="props">{{ props.row.url }}
                &nbsp;<q-btn round dense icon="add_shopping_cart" color="primary" small @click="cartAdd(props.row)"><q-tooltip>add to cart</q-tooltip></q-btn>
              </q-td>
              <q-td key="albumId" :props="props">
                {{ props.row.albumId }}
                &nbsp;<q-btn round dense icon="add_shopping_cart" color="primary" small @click="cartAdd(props.row)"><q-tooltip>add to cart</q-tooltip></q-btn>
              </q-td>
              <q-td key="thumbnailUrl" :props="props">{{ props.row.thumbnailUrl }}
                &nbsp;<q-btn round dense icon="add_shopping_cart" color="primary" small @click="cartAdd(props.row)"><q-tooltip>add to cart</q-tooltip></q-btn>
              </q-td>
            </q-tr>
          </template>
        </q-table>
</div>

and this javascript:

new Vue({
  el: '#q-app',
  data: function () {
    return {
      produkty: [],
      pagination: {page: 1, rowsPerPage: 5, _sortBy: null, descending: false, rowsNumber: 1000},
      rowsPerPage: [0, 5, 10, 15, 25, 50, 100],
      columns: [
        {name: 'albumId', field: 'albumId', label: 'albumId', required: false, align: 'left', sortable: false},
        {name: 'id', field: 'id', label: 'id', required: false, align: 'left', sortable: false},
        {name: 'title', field: 'title', label: 'title', required: true, align: 'left', sortable: false},
        {name: 'url', field: 'url', label: 'url', required: true, align: 'left', sortable: false},
        {name: 'thumbnailUrl', field: 'thumbnailUrl', label: 'thumbnailUrl', required: true, align: 'right', sortable: false}
      ]
    }
  },
  mounted () {
    // this.fetchData()
  },
  methods: {
    async requestDataTable ({pagination}) {
      this.pagination.page = pagination.page
      this.pagination.rowsPerPage = pagination.rowsPerPage
      await this.fetchData()
    },
    async fetchData () {
      this.produkty = []
      // (this.pagination.page - 1) * this.pagination.rowsPerPage, this.pagination.rowsPerPage
			response = await fetch('https://jsonplaceholder.typicode.com/photos/')
      json = await response.json()
      this.produkty = json.slice(0,this.pagination.rowsPerPage)
    },
    cartAdd (item) {
      this.$q.notify('add: ' + item.title)    
    }
	}
})

the profiling session:
click first load button
click next page
change records per page to 100
click next page
click some qtooltips
click next page
click next page
change records per page to 5
click next page
click next page

…and it seems OK:

I was curious if changing records per page from 100 to 5 will release memory and it released as you said - which you can see on the chart.

So, in my application the memory leak still exists. It needs further investigation. As for now I’m assuming that it is some combination of vue, vuex, router, i18n, quasar interaction (ha ha).

BTW debugging such leaks is extremely hard. I really would like to have some “developer mode” where quasar would scream to me (in console log) - “hey - you’re leaking those objects and it’s not my fault, you should check this and that”. Oh, sweet dreams

@rstoenescu
Hi, thanks for reply. Let me clarify:

1. the problem is observable with only 100 rows per page in QDataTable case. It is a show stopper for SPA apps on older mobile devices.

2. as you could see on the attached screenshot, both handlers and references were not GC collected when they were no longer displayed. The listeners, nodes and js heap only grows after clicking next page in QDataTable with custom QTooltips. It seems, that the problem may be not with the adding new tooltips, popovers and modals but with disposing those no longer needed. I do not know if rows (ie dom nodes and events) in paginated table are reused but tooltips and their handlers obviously are not.

OK, I’m not arguing anything specific, just making an observation. I’m sure that it will somehow feed your (profiling/speed/memory consumption) curiosity anyway

Hi, I know, that quasar is not in performance/optimisation/efficiency mode (yet) but maybe it would be interesting for someone. In one of my apps I noticed a large raise of non referenced DOM nodes (removed from DOM but stored in process memory) and attached corresponding javascript event handlers (stored in javascript heap memory). Those nodes and events are not garbage collected - looks like memory leak. Even after pressing F5 they are not gc processed. They are removed only after pressing Ctrl+F5, so it is rather a problem for a typical user.

After little tinkering, I isolated the most leaking code - it was placed in QTooltip. Maybe someone wiser/more experienced could confirm/reject my observation:

Here is the code:

And here are example memory spikes (paging through QDataTable) and DOM Nodes count. This $nexttick handler is present in many groups (recalculate style, layout etc.):

Well, I would love to see an organized page with many such lightweight quasar components. Similar to:

https://bootsnipp.com/

Bootsnipp had a tremendous impact on bootstrap popularity. I think almost everybody here has some interesting “components” or snippets of quasar code worth sharing.