I’m working on a Vue Mixin to manage Grapher queries.
It automatically subscribes to the queries when the Vue instance is created, and unsubscribes when it’s destroyed, and it updates them when Vue variables they depend on change.
I’ve updated my testing repo with a pretty cool infinite scroll feature, combining grapher-vue with Akryum’s vue-virtual-scroller!
It smoothly scrolls through a list of 50.000 items that are fetched on-demand from the server, only subscribing to those that are visible based on scroll position
For lazy people, the demo may or may not be available at https://dev.herte.by/ depending on what I’m doing at the moment
Yeah, @herteby you should probably publish a cordova version of that colored boxes section on the app store so I can take it everywhere I go, you know, to just pointlessly yet soothingly stare at it for copious amounts of time.
W20171009-18:35:20.687(7)? (STDERR) TypeError: query.subscribe is not a function
W20171009-18:35:20.687(7)? (STDERR) at run (packages/herteby:grapher-vue/grapher-vue.js:88:17)
W20171009-18:35:20.688(7)? (STDERR) at [object Object]._onTimeout (packages/herteby:grapher-vue/grapher-vue.js:148:10)
W20171009-18:35:20.689(7)? (STDERR) at Timer.listOnTimeout (timers.js:92:15)
Quick tip, you can also avoid specifying collection, if u use the collection’s name:
createQuery({
users: { ... }
})
If you want to avoid having both collection and query params specified. But I agree that this is cleaner version. The only reasoned I added the functionality above was easy testing with Grapher Live.
Usually I like keeping queries modularised in their own file. So having something like: users: getUsersQuery should also be an option. Because in time queries grow a lot in their vertical size, and you keep the code cleaner this way.
“collection” and “query” are not the only arguments though, there are 5 other optional ones too.
If you put the query in another file, you couldn’t use the reactive Vue component properties in it though. I guess you could export a function that returns the query, which you then call with function.call(this)
That still leaves you with the problem of being outside Vue component scope and not having access to the component data though.
Hmm, I guess I didn’t think of setParams and $filter when I made the package. That would be another way to do it, and would work better with named queries too I guess I’m not quite following the intended use.
Yes, you can can use import/export with Vue, and for a static query this would be fine.
How grapher-vue works though is that it takes the function you define and puts it in a Vue watcher, which reruns the function and updates the query whenever any reactive Vue variables (this.limit in the example) that you’ve used in it change. So if you have pagination or search for example, it automatically updates the query when you change the “search” or “page” variables on the Vue component. This requires that grapher-vue is given a function rather than an object.
I realize now that your intention was probably to use setParams and $filter for this type of functionality, though that way is still slightly less flexible than the way I’ve done it.
I should probably add a params argument though, so that you can use grapher-vue with named queries + dynamic params, which isn’t possible at the moment.