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

collision between object path and serialization #138

Open
Heziode opened this issue Aug 9, 2021 · 8 comments · May be fixed by #140
Open

collision between object path and serialization #138

Heziode opened this issue Aug 9, 2021 · 8 comments · May be fixed by #140

Comments

@Heziode
Copy link
Contributor

Heziode commented Aug 9, 2021

const payload = action.objPath
? new Payload(path, action.objPath, value)
: value

The above code create non Payload object for "root path", like the following example:

// global.js Vuex module
import { make } from "vuex-pathify";

export const state = () => ({
  something: true,
});

export const mutations = {
  ...make.mutations(state),
};

export const getters = {
  ...make.getters(state),
};

If I call $store.set("global/something", false), the Payload will be a simple object (like serialized object) and not a Payload instance.

Is there anything in particular to avoid using a Payload for the root path?


nb @davestewart : you did not push tags not the repo, and you did not release 1.5.1 on NPM.
I know that you are very busy, so, stay in shape 💪

@davestewart
Copy link
Owner

davestewart commented Aug 10, 2021

Hey @Heziode,

Thanks for digging in and going over the code :)

The objPath property is essentially the @path.to.item part of the expression:

const [statePath, objPath] = path.split('@')

The Payload class is used only so we can do target instanceof Payload and then use its update() method to deep-set the value:

https://github.com/davestewart/vuex-pathify/blob/master/src/classes/Payload.js#L25

So generally, unless your paths have a @ in them, data will remain as POJOs.

Does that answer your question?

Re. 1.5.1, yes, I need to publish 1.5.1! Thanks for spotting. Will do that now.

@Heziode
Copy link
Contributor Author

Heziode commented Aug 10, 2021

The Payload class is used only so we can do target instanceof Payload and then use its update() method to deep-set the value:

So generally, unless your paths have a @ in them, data will remain as POJOs.

The problem with POJO is that it becomes impossible to distinguish between a call to set of pathify and a mutation done by a serialized payload, since they are both POJOs.

@davestewart
Copy link
Owner

OK. Not 100% sure what the problem is, as I haven't tested a serialisation.

If you want to create and post a sample repo, that would be useful.

@Heziode
Copy link
Contributor Author

Heziode commented Aug 10, 2021

@davestewart take a look at the following repository: https://github.com/Heziode/vuex-pathify-serialization-multi-tab

The main reason in my case to be able to distinguish POJO of vuex-pathify and POJO of serialization is to be able to do some work if the orchestrator is Vuex-Pathify (sync the store with a backend)

@davestewart
Copy link
Owner

Thanks! I can't promise to look at it today, but let me try in the next couple of days.

Do you have any ideas to solve the problem (which I don't understand yet!) ?

@Heziode
Copy link
Contributor Author

Heziode commented Aug 10, 2021

The solution would be to use the Payload class in any cases.

Like this it will be very trivial to detect if the change is orchestrated by vuex-pathify or something else (including serialization).

I do not analyzed the whole code of the lib, so I don’t know if it can be convenient to do this.

@davestewart
Copy link
Owner

So if we took that approach, you're basically saying:

  • if it's a POJO, it would have been deserialized
  • if it's a Payload, it would have been created internally by Pathify

?

I can't remember how everything is put together TBH but I'll dig in again in the next few days.

Do the changes you pushed for solve the serialisation aim, or is this additional work needed to completely solve it?

@Heziode
Copy link
Contributor Author

Heziode commented Aug 10, 2021

So if we took that approach, you're basically saying:

  • if it's a POJO, it would have been deserialized
  • if it's a Payload, it would have been created internally by Pathify

?

Right, this is what I mean.

Do the changes you pushed for solve the serialisation aim, or is this additional work needed to completely solve it?

#125 cover a big part of the serialisation problem but not the not the problem raised here. So additional work is needed to cover this case.

@Heziode Heziode linked a pull request Aug 10, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants