davestewart / vuex-pathify

Vue / Vuex plugin providing a unified path syntax to Vuex stores
https://davestewart.github.io/vuex-pathify
MIT License
1.37k stars 57 forks source link

call naming #39

Closed ozum closed 5 years ago

ozum commented 5 years ago

Hi,

When I use default makeActions(state), using call with name throws error, but with setName it works.

Please see, example below. I expected this.localeA("en") works, but it throws error.

store

const state = { locale: "en" };
const actions = makeActions(state);

component

methods: {
  localeA: call('locale'),  // unknown action type: locale
  localeB: call('setLocale') // sets locale
}

I assumed from documentation to be used like get("locale"), sync("locale"), call("locale").

Am I correct?

davestewart commented 5 years ago

So the make.* helpers are designed around setting / getting data; essentially, converting store property names to either commit or dispatch paths:

foo => setFoo()

See:

However, call() is designed to wrap a dispatch (any dispatch, not necessarily a makeed action) with a convenience wrapper:

foo -> foo()
setFoo -> setFoo()
loadFoo -> loadFoo()

So they are not connected.

If you think the docs are ambiguous, let me know and I will fix them!

Also, as I mentioned several times in the docs, I don't see the point of creating actions when you're just committing, especially as Pathify does all the work for you and makes it really clear what is it doing, so I don't and encourage the same.

I use actions for doing actionable things, not just 1:1 commits!

ozum commented 5 years ago

@davestewart

Docs are good, but I have two suggestions.

1. Additional fields and descriptions for Intro/Pathify 101 table

Operation       Member          Name            Component       Store               Make        Scheme

read            state           foo             get("foo")      store.get("foo")                // base name
read            getters         foo             get("foo")      store.get("foo")    foo         // no prefix, no case conversion
write           mutations       SET_FOO                         store.set("foo")    SET_FOO     // "set" prefix, constant case, 
write           actions         setFoo          call("setFoo")  store.set("foo")    setFoo      // "set" prefix, camel case, 

Name: Key name used in vuex store. Example: { state: { key: value }, getters: { key: value }, mutations: { key: value }, actions: { key: value } } Component: How this member is accessed in components with component helpers. Store: How this member is accessed in store using store accessors Make: What store helper functions make.mutations(), make.actions() and make.getters() generates as a key to be used in { state: { key: value }, getters: { key: value }, mutations: { key: value }, actions: { key: value } }.

2. Example in call

Example from https://davestewart.github.io/vuex-pathify/#/api/component?id=call

Use call() to create functions that dispatch actions to the store:

methods: {
  load: call('products/load')
}

The helper generates the following method:

methods: {
  load (payload) {
    return this.$store.dispatch('products/load', payload)
  }
}

Example is correct, but I intuitively thought that make.actions({ load: "someData" }) generated action with key products/load. Maybe it could be added an example with make.actions(), so relationship between make and call could be easily understood.

New User Struggle

As a new user of the library, I found call() really confusing. Whereas get and store.get() is nearly identical, call and store.set() is different.

  1. Their behaviour: call -> action but store.set -> action | mutation
  2. Their usage: call("setName") but store.set("name")

Please consider adding a new component helper completely in parity with store.set().

Thanks for your fast response and patience.

davestewart commented 5 years ago

OK, thanks for your thoughts.

I'm reluctant to expand on the table in the intro as I want to keep it as simple as I can to communicate the main concept...

...but I see your points in relating the functionality from a different part of the lib. I'll try to think how I can do it differently!

ozum commented 5 years ago

Maybe, you could add table in a subpage to keep intro simple and provide a full ref in a sub page.