-
-
Save javisperez/b13d02042620ae663f0a1f81b050ca69 to your computer and use it in GitHub Desktop.
import { createStore } from 'vuex'; | |
// The modules to import | |
import auth, { Store as AuthStore, State as AuthState } from './auth'; | |
import counter, { Store as CounterStore, State as CounterState } from './counter'; | |
// A State type with all the submodules | |
type State = { | |
auth: AuthState; | |
counter: CounterState; | |
} | |
// And the store is an extension of all the stores but each store receives its own state | |
export type Store = AuthStore<Pick<State, 'auth'>> & CounterStore<Pick<State, 'counter'>>; | |
const store = createStore({ | |
modules: { | |
auth, | |
counter, | |
}, | |
}); | |
export function useStore() { | |
// This made the trick to me, i dont love it, but i dont know other way to do it. | |
// The compiler kept complaining about it not being compatible with Vuex' store so i casted it to uknnown | |
// and after that re-casted as the Store we just defined. | |
return store as unknown as Store; | |
} | |
export default store; |
@javisperez that RootState type seems to be needed to be imported in modules index, getters, and actions files. @soerenmartius had used this syntax also.
However, it's resulting in cyclical dependency linting error, so there is some quirk about it. But somehow it works 🤸♀️ ...
If using <GetterTree<State, State> & Getters
, I'm getting this type error:
Conversion of type 'Store<State>' to type 'DocumentsStore<Pick<RootState, "documents">>' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
On this return statement:
export function useStore(): Store {
return store as Store;
}
@ux-engineer ahh, in my case I solved that conversion error with this return store as unknown as Store
instead of return store as Store
, based on what the same error says "If this was intentional, convert the expression to 'unknown' first
" and that worked for me.
oh and also, about the RootState
that's fine, I just wouldn't do it if I won't be accessing cross-modules states, if everything in my actions is going to belong to my module's state I'd just use the State
but that's just me, I don't think its a bad thing.
@javisperez its true that this typing problem could be circumvented with type-casting to unknown
first.
However, this double assertion casting via unknown is a way of forcefully casting any type to any other type. After doing so, as far as I understand (and am not a deep expert in TS), there could be something wrong with our store or with the library, which TypeScript might not be recognizing as an error.
So it doesn't seem a correct solution because there seems to be something wrong with typings in the first place.
@ux-engineer yeah, i think you're right, but sadly i don't really have the TS experience to make a proper fix without including the whole RootState there. I mean, I'm really a TS noob 😬
No worries, we are using community effort here...if this remains to be unresolved, I will open up an issue to Vuex repository and/or write to core team members in Discord channel 😁
Vue 3 and Vue Router 4 (in beta) are written fully in TypeScript, however, Vuex 4 is not. It's TypeScript rewrite is coming up in Vuex 5 later on. But they have been working towards better TS support already with this version 4, which is still in beta.
Here's an issue thread in Vuex repo related to using modules in Vuex 4.0: vuejs/vuex#1833
I just realized VS Code intellisense is not showing type information for the store instance after passing it from useStore
function, when used inside component. Works if imported in .ts
file.
Sorry about the delay guys, its been crazy busy for me and I haven't got the time to make a full demo, sorry about that.
I'm glad that there's some solutions posted here though, thank you, I've had planned a codesandbox demo but i think @ux-engineer just covered it, that was basically the same idea i had. The only thing i didnt fully understood with your approach @ux-engineer was why are you passing the whole
RootState
to theAugmentedActionContext
in your actions, if you wont be using other module's states? like theFETCH_DOCUMENTS
action doesn't use the state you could just pass the DocumentsState and keep it contained in the module?Maybe I'm missing something but anyway, i think is a great job, thanks for doing it and thanks for sharing it!