Following #82
Currently, whenever you $bind an array over an existing key, let's say because you updated the query (eg pagination), the array is emptied and then filled again: https://jsfiddle.net/obg46axu/
It'd be great if:
unbind is called automaticallyvalue event to actually set the arrayvalue event is emittedThis is only possible if the value event is always called once after the other events (child_added). Otherwise, it'll require doing more complicated checks that'll have an impact on larger datasets.
Hey @jwngr, can you tell me if I can rely on that supposition, please ๐ ?
Not sure, but maybe this is what you are looking for:
https://www.firebase.com/docs/web/guide/retrieving-data.html#section-event-guarantees
Value events are always triggered last and are guaranteed to contain updates from any other events which occurred before that snapshot was taken.
hey, thanks. Yes, I wonder if it's true with v3. I suppose it is ๐
Yup, that condition is true with the 3.x.x SDKs as well. The value event will always fire after all the initial child_added events have fired.
I'm curious on any updates on this. I've been trying to bind array, and update the array in firebase based on user interaction with a list. right now it just clears each time (I opted for the way to create an empty array in data to double my firebaseref) I appreciate any help on making the updates modular (only updating the changed parts of the array)
Just for curiosity, any idea when this feature will be available? Any help needed?
Ditto. Think we'll see this soon? Would be super useful.
maybe in a month or two. I'll like to refactor the code of vuefire before adding new features
If I understand correctly, this will allow pre-loaded lists to be updated with firebase? If so: +1 from me! We load quite some data from Firebase and pre-render our list on the server side. After binding to Firebase in the mounted event, the current list is emptied, downloaded from Firebase and re-drawn. We'd like to prevent that. If it's already possible, can you steer me in the right direction?
here is a temporary workaround to prevent re-drawing rendered elements in v-for loop
<template>
<ul>
<li v-for="item in (shadowItems || items)" :key="item['.key']">{{item.foobar}}</li>
</ul>
</template>
export default {
data: {
shadowItems: null,
page: 1
},
methods: {
loadMore () {
this.shadowItems = this.items
this.$bindAsArray(
'items',
firebase.database.ref('items').limitToLast((this.page + 1) * 2),
null,
() => {
this.shadowItems = null
this.page += 1
}
)
}
}
}
Thanks! Content doesn't flash anymore, a big improvement to what we had.
Regarding this, two months passed and I still haven't done it. I was focusing more on firestore. Right now i'm out for a bit of time but if anybody is interested in implementing the feature. It's something that exists on vuexfire as the wait option: https://github.com/posva/vuexfire#api
@daan944 @alekbarszczewski @hemache
I've implemented a plugin for vuefire that adds the wait feature and the automatic rebind feature.
Here's the source: https://github.com/vuejs/vuefire/issues/208
You use many helpers ๐
but still a helper until I get some time to implement this! Thanks for sharing @wujekbogdan
@posva any updates on this?
I did move forward on this in a branch but had to pause for other things
Eduardo San Martin Morote
On 14 Aug 2019, at 22:58, Patrick Schaub notifications@github.com wrote:
@posva any updates on this?
โ
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Have tried to address this in PR https://github.com/vuejs/vuefire/pull/336... I have tested locally (not strenuous) and have found it to be working well. One downside is the inability to pass through a reset function if wait is set to true.
Happy to take on any suggestions in a better way to implement this.
Edit: Note to self: read the discussion in the issue, don't just gaze over it!
Didn't realise you had made a branch. The implementations were quite similar, however I've updated my PR and matched it up with your code styling.
Should be pretty similar minus the tests, but it works. Will implement tests into that branch if you're interested in possibly merging this opposed to finishing off your own branch.
Cheers.
Anybody needing this feature, could you test it by following the instructions at #361 ? That would help us to release it
@scottgearyau @pschaub @wujekbogdan @daan944 @hemache @jamesxv7 @humanismusic You seem to be interested in this feature, it's released under the next npm tag, could you give it a try (more info at #361), it will help to release for everyone and move forward with other SSR improvements
I have tested using vuefire (not vuexfire), with the global wait option on SSR, and everything is working as expected for me.
Thanks for adding the wait option!
I see, that shouldn't be related to the wait option. You must call the initializeApp only once, and you should be able to do so by doing
export const db = !firebase.apps.length ? firebase.initializeApp(config).firestore() : firebase.app().firestore()
or something similar
That could be added to the Cookbook page for SSR
@posva Got it! Thanks for the fast feedback.
This was released in [email protected] and [email protected]
Most helpful comment
here is a temporary workaround to prevent re-drawing rendered elements in
v-forloop