How to set nodes of q-tree with vuex?



  • To avoid this error : Error: [vuex] Do not mutate vuex store state outside mutation handlers.
    I use some like this:

    <q-tree
            ref="qtree"
            :nodes="nodes"
    />
    
      computed: {
        nodes: {
          get () { return JSON.parse(JSON.stringify(this.$store.state.nodes)) },
          set (val) { this.$store.commit('setNodes', JSON.parse(JSON.stringify(val))) }
        }
      },
    

    But I am not sure is is the best method,is there another more choice?



  • Hi @weide
    I am assuming that you started correctly the State on Quasar.

    According to the error, you have not created the mutate state…

    You must import the mapGetters and mapActions of the vuex directly and simply

    Try this:
    ``
    <script>
    import { mapActions, mapGetters } from ‘vuex’;

    // … you code

    computed: {
    …mapGetters(’[Module]’, [‘getterName’]),
    nodes: {
    get() { return this.[getterName] }
    set (val) { this.actionName }
    }
    },
    methods: {
    …mapActions(’[ModuleName]’, [‘ActionName’]),
    … you code…
    ``



  • @eurus-pro

    Thank you reply

    For some reason, I didn’t use vuex’ action,more code like down.

    done(data) ---- will added to q-tree’s nodes,will cause the error if not use deep clone for nodes…

    I’ll try your code later。And have you test your code or give an complete example?

    <q-tree
           :nodes="nodes"
           @lazy-load="onLazyLoad"
         />
    
       onLazyLoad ({ node, key, done, fail }) {
         let params = { parentId: node.id, userId: this.UserInfo.userId, type: 1 }
         findFilesByPid(params).then(res => {
           if (res.code === 200) {
             let data = res.data
             if (data instanceof Array) {
               done(data) // will throw error here.....................................
             } else {
               done([])
             }
           } else {
             done([])
           }
         })
       },
    


  • @weide this is somewhat interesting in the context of q-tree and nested data structures:

    https://vuex-orm.github.io/vuex-orm/guide/prologue/what-is-vuex-orm.html

    This technology uses “normalized” data structs and allows querying (nested). It is useful in q-tree applications.



  • I’m also wondering whether it makes sense at all to use Vuex in between a QTree in the frontend and the database in the backend.

    Currently my QTree works directly against the database through CRUD like REST APIs on nodes in the tree, or paths (children etc.) in the tree, those APIs are similar to what this “Vuex ORM” provides. My code does not use Vuex currently.

    I’m now considering to add Vuex to my code, but I’m very concerned that putting Vuex in the middle of such a scenario complicates things more than it helps. Especially when I read that Vuex alone won’t do it, and you need an additional “Vuex ORM” to do it properly.

    I would be very interested about @weide 's experiences with QTree and Vuex.



  • You dont need vuex orm, wat you should know is its not that simple to use mutator on elements inside states that are deep nested objects or arrays.



  • @metalsadman - I agree. But still I wonder whether Vuex makes it easier or complicates the synchronization of the tree state betwen QTree and the persistent representation of the tree in the database (Mongoose/MongoDB in my case, connected with QTree through REST APIs).

    I understand that the main purpose of Vuex is to have one common state/store among multiple components (e.g. in my case the one for the QTree and other components managing other data in the app), with the need to sometimes use common data between those components.

    But the advantages of that common store across components need to be balanced with the potential drawbacks/complications that Vuex introduces to sync the store (and especially the nested objects like trees in the store) with the backend. Haven’t seen a good pattern for that yet. Vuex ORM maybe is such a pattern, but not directly applicable for me, since my backend is Mongoose ODM - which happens to do at the backend what Vuex ORM does at the frontend…amazing how many patterns are put together in such fullstack apps 😉



  • @metalsadman said in How to set nodes of q-tree with vuex?:

    You dont need vuex orm, wat you should know is its not that simple to use mutator on elements inside states that are deep nested objects or arrays.

    Hi, just for clarification: vuex-orm is using “normalized” data inside, not deep nested objects or arrays. That is what convinced me to use it. Why? Because I was writing my own, exactly same procedures, so why not to use something already built? More about normalization from docs:

    https://vuex-orm.github.io/vuex-orm/
    Vuex ORM is heavily inspired by Redux recipe of “Normalizing State Shape”
    and “Updating Normalized Data” . Learn more about the concept and motivation of Vuex ORM at What is Vuex ORM?

    Yes, I totally agree, that vuex and this “normalized” ORM has a merit only if you need to share state between components. But I learned, (quite painfully btw), that almost anything what not comes from transactional backend should be treated as an application state. So it is easier for me to just put that in vuex than think “should this belong to vuex or not?”.

    There is another quirk with such ORMs - it is something what @Mickey58 wrote, that he already has an ORM on the backend. For me, this concept of ORM at the frontend is quite useful, because I tend to have a relational database on the backed. But the real question is “do you think (in this particular project) in relations or in the objects/documents/services/etc.?”. If it is relations, then of course, this particular ORM could be nice. If it is not relations, then maybe, any of the plugins would be useful:
    https://vuex-orm.github.io/vuex-orm/guide/digging-deeper/plugins.html

    Nevertheless, the “normalization” is the key concept to sell. If you want to have flat structures, with potential to store them locally (indexedDB) or synchronize them between peers, then this ORM could be interesting (IMHO).

    Acha, I’m not in any case involved with development of this library 🙂 I can see some drawbacks with it (quite many even). It just is something helpful in the context of backend->frontend->quasar components.



  • Yeah i know what it does, but for the task as per the op, a tree node is an array of objects having to use an orm is overkill for this (if not just adds more complexity).


Log in to reply