Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

updated_at en updated_by guards, only in some cases #305

Open
Fulbert opened this issue Mar 21, 2020 · 8 comments
Open

updated_at en updated_by guards, only in some cases #305

Fulbert opened this issue Mar 21, 2020 · 8 comments
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@Fulbert
Copy link

Fulbert commented Mar 21, 2020

Hello,

Thanks for this awesome tool!

I have a guarded property on my store, selected, which is used only by the UI, and I don't want to sync on Firestore.
If the guards works well, the document is still synced everytime I change the selected value, because of the updated_at and updated_by value.
Of course, I can add the two properties to the guards too, and it works, but I actually still want to use them for some other cases.

Did I miss something that could help, or would I need to use other property name and add logic to save updates when needed?

Thanks!

@mesqueeb
Copy link
Owner

Hello. Thanks for your issue!
This is indeed an issue. In version 2.0 this issue is already non-existent, but in v1.0 we'd need to make some modifications for this edge case.

If you're interested in contributing, I can point you to the area that needs to be updated. 😉

Otherwise, you can work around it by writing a custom wrapper function for the patch action, that checks if only the selected prop is edited or not, and if only selected was changed not to dispatch the patch action.

@mesqueeb mesqueeb added good first issue Good for newcomers help wanted Extra attention is needed labels Mar 21, 2020
@Fulbert
Copy link
Author

Fulbert commented Mar 22, 2020

Well, I guess this is somewhere there :

prepareForPropDeletion: (state, getters, rootState, rootGetters) => (

I need to know if this prop delete is because of a guard... I'll take a look.

@Fulbert
Copy link
Author

Fulbert commented Mar 31, 2020

@mesqueeb I just come back to this one, because it actually cause bug in my app... Because even with guards on updated and created, it still try to patch (nothing)... Unfortunately because of firestore rules, some users can't update...

Because my app is not yet in prod, I can open the rules a little bit to fix it. However if you can tell where to fix this, I would love to.

Thanks 👍

@mesqueeb
Copy link
Owner

mesqueeb commented Apr 2, 2020

@Fulbert there is actually an easy workaround I want to suggest you use instead:

https://mesqueeb.github.io/vuex-easy-firestore/hooks.html#hooks-after-local-changes-before-sync

{
  // in your module config
  sync: {
    patchHookBeforeSync: function (updateFirestore, doc, store) {
      // check if you are only trying to update the "selected" prop or not, if so, return early
      if (selected in doc && Object.keys(doc) === 1) return
      // else, continue:
      updateFirestore(doc)
    },
  }
}

Can you try this out and let me know how it goes?
The exact if sentence you write might need some tweaking depending on your setup.

@Fulbert
Copy link
Author

Fulbert commented Apr 2, 2020

I actually fixed it like this yesterday, few minutes before I thought that I can mutate my selected prop with my own mutation... Since the beginning.

Sorry for that 😳

@louisameline louisameline added the enhancement New feature or request label May 13, 2020
@louisameline
Copy link
Collaborator

louisameline commented May 15, 2020

We'll definitely make requests to Firestore only if they are non-empty in the future, so this will be solved.

In the meantime, I have a question for you @Fulbert : is there a reason why your guarded property is within state.data (if data is the prefix you chose) instead of at the root of state, in which case it would not be synced anyway (no need for a guard)? I'm trying to get a glimpse of the use cases where people use guarded properties. Thank you

@Fulbert
Copy link
Author

Fulbert commented May 15, 2020 via email

@louisameline
Copy link
Collaborator

Oh great thank you, I understand now.

It's ok to use a non-vef action or mutation to mutate your property until we fix. I'll check tomorrow if a quick patch can be done for this issue.

But in all cases, there will be another preferred way to handle your local properties of documents loaded by a collection in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants