Skip to content
This repository has been archived by the owner on Apr 19, 2019. It is now read-only.

Thoughts on vuexfire for larger project #12

Closed
zoomclub opened this issue Nov 19, 2016 · 1 comment
Closed

Thoughts on vuexfire for larger project #12

zoomclub opened this issue Nov 19, 2016 · 1 comment

Comments

@zoomclub
Copy link

zoomclub commented Nov 19, 2016

Its finally a day off and I'm diving into vuexfire, awesome! Something that throws me off right away is this line in the readme, "Everything else works just as vuefire. Refer to its readme for more documentation."

Likely vuexfire is very well put together but I'm trying to comprehend it in terms of my real life project. It looks like the snippet examples are scattered around and assume a lot of knowledge of firebase and jumping around between multiple repos.

What would be most helpful is if what vuexfire does would be added to the nice diagram that vuex already provides and a comprehensive guide could be put together. I can definitely help with suggestions along with other vuexfire users.

Maybe some details on how the binding to firebase actually works behind the scenes can be provided? Then some more clarity on the firebase refs vs the store module state and why it is necessary to declare things twice to achieve the binding. Some more complete well commented examples would help.

In the end I will need a global store that has ten modules. The state for these modules is already defined as JSON documents on firebase. The documents are not just simple counter values and such, instead they are large nested trees of values expressed as objects and arrays. What is not clear to me is if I need to re-declare all that nested data on the vuex side of things again?

If I have so much data in each document how am I suppose to bind this to a vuex store? Can I bind the complete document or bind to any part of it or can I instead just grab the aspects of it I need further down the component flow?

Sorry for all the questions but between needing to get a project setup, various ways to define a global store of modules and unclear firebase binding details I'm feeling that my free day is slipping way :)

P.S. It would be great if the older Vue v1 stuff could be extracted into it's own readme.

@posva
Copy link
Owner

posva commented Nov 20, 2016

I'm glad you're giving vuexfire a try 😄

and assume a lot of knowledge of firebase

That's right, you need to know the basics of firebase because you're going to manipulate the database by using the firebase package

What would be most helpful is if what vuexfire does would be added to the nice diagram that vuex already provides and a comprehensive guide could be put together. I can definitely help with suggestions along with other vuexfire users.

I like that, I'll see what I can do by reusing the vuex diagram. I'm also open to suggestions if you want to give it a try

Maybe some details on how the binding to firebase actually works behind the scenes can be provided?

Yes, the diagram should solve that

why it is necessary to declare things twice to achieve the binding

IMO that's a suboptimal part of vuexfire I cannot get around with the current API. I have to rethink how to make binding easier. Suggestions are welcome

if I need to re-declare all that nested data on the vuex side of things again?

Unfortunately, it's better to do so. Arrays should be bound as arrays and not as an object containing the array. Explaining a bit more the internals or adding a more advanced tutorial would help. And I have plans to do so in the near future

If I have so much data in each document how am I suppose to bind this to a vuex store? Can I bind the complete document or bind to any part of it or can I instead just grab the aspects of it I need further down the component flow?

The more precise you are referencing an object, the better but don't get to extreme situations:

options: {
  a: ...,
  b: ...,
  c: ...
}

Just reference the option object

P.S. It would be great if the older Vue v1 stuff could be extracted into it's own readme

That'd make the readme more concise but I don't think it's an issue as long as the section are well delimited.
I'll at some point remove the compatibility with Vue 1

Thanks for the thoughts, I really appreciate it. I'll add the mentioned elements below to my roadmap

@posva posva closed this as completed Nov 20, 2016
This was referenced Nov 20, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants