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

Remove "don't use direct commit's" trap #14

Open
davestewart opened this issue Dec 26, 2018 · 5 comments
Open

Remove "don't use direct commit's" trap #14

davestewart opened this issue Dec 26, 2018 · 5 comments

Comments

@davestewart
Copy link

Hi there,

Thanks for the lib. It seems from the source code there is a lot to do to get Vuex working nicely with Electron!

One thing I think is too much though, is the trap to prevent commits outside of stores:

https://github.com/vue-electron/vuex-electron/blob/master/src/shared-mutations.js#L54-L56

Surely it's not this library's place to decide on individual developer preference. Committing outside of actions is perfectly valid, especially for those who choose not to tightly couple their API to Vuex (like me!).

Can this be removed please?

@gabrielstuff
Copy link

Hello,
Yes, indeed it cause some incompatibility with plugin like this one for instance: https://github.com/spacebro/spacebro-client

Or maybe do you have a proposal @MrEmelianenko ?

@gabrielstuff
Copy link

Hello @MrEmelianenko any thought about this issue ? Why not a warning and let the default behaviour happen.

@akodkod
Copy link
Contributor

akodkod commented Aug 29, 2019

#44

@ferm10n
Copy link

ferm10n commented Jun 20, 2021

Based on my understanding of vuex-electron, the single source of truth should be based in the main node process. This is accomplished right now by having the renderer dispatch actions, and the main process performing the commits...

I think mutations could be triggered on the renderer too, using ipcRenderer.sendSync but that would obviously be blocking. IMO that's a fair trade for not dispatching actions which are async by design. I think it's actually the only way to consistently maintain keep the main state and renderer state(s) in sync.

@ferm10n
Copy link

ferm10n commented Jun 20, 2021

@gabrielstuff @davestewart what do you think about that option? I'm working on a fork of this project and will be trying it out.

(forgot to tag in original comment, not sure if github will notify if I add it in an edit)

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

No branches or pull requests

4 participants