FAQ
Why aren't actions included by default?
The decision to not include actions in the core package by default is to remain faithful to the philosophy of keeping Harlem lightweight, simple and unopinionated. Different projects have different needs for actions. Some larger projects may require nested actions and cancellation while smaller projects may not need all of those features but instead just need simple direct mutations.
To ship a full action implementation as part of the core package would force every project (especially the small projects) to incur that cost (size, performance etc.) even if not all of the action features are being used. For this reason Harlem provides a full-featured action implementation as an optional extension and leaves your action implementation up to you should you wish to keep things simple or get really complex.
Why does Harlem still have Mutations?
Mutations are a key concept of Harlem. They are foundational in providing functionality for triggers, devtools, tracing, and extension/plugin integration. That being said, although they are a core concept, they are not mandatory. With the action extension, you can author your stores entirely without explicitly defining mutations and still have all the benefits of triggers, devtools etc.
Can I share state between stores?
Certainly - just import the state or getter from one store into the getter you are authoring on another store. For example:
import {
state as otherState
} from '../other-store;
import {
getter
} from './store';
export const myNumberGetter = getter('myNumber', state => state.myNumber + otherState.otherNumber);
This also works for importing getters from other stores. Just remember that to access the value of a getter you will need to use the .value
property of the getter. For example, if I had a getter name myGetter
and I wanted to use it in another getter I would have to use myGetter.value
to access it's raw value.
See the Vue documentation on computeds for more information. Vue Computed.
Does Harlem have a file structure convention for stores?
Short answer, no. Because Harlem attempts to be as unonpinionated as possible that means it's up to you to structure your store how you see fit. That being said here are 2 examples that may give you a headstart:
Single file structure
- stores
- store1
state.js
getters.js
mutations.js
actions.js
store.js
index.js
- store2
state.js
getters.js
mutations.js
actions.js
store.js
index.js
Multi-file structure
- stores
- store1
- getters
getter-1.js
getter-2.js
- mutations
mutation-1.js
mutation-2.js
- actions
action-1.js
action-2.js
state.js
store.js
index.js
- store2
- getters
getter-1.js
getter-2.js
- mutations
mutation-1.js
mutation-2.js
- actions
action-1.js
action-2.js
state.js
store.js
index.js
In both cases the store.js
file and the index.js
files would look roughly the same.
// store.js
import STATE from './state';
import {
createStore
} from '@harlem/core';
export const {
state,
getter,
mutation,
...store
} = createStore('store1', STATE);
// index.js - single file structure
export { state } from './store';
export {
getter1,
getter2
} from './getters';
export {
mutation1,
mutation2
} from './mutations';
// index.js - multi-file structure
export { state } from './store';
export { default as getter1 } from './getters/getter-1';
export { default as getter2 } from './getters/getter-2';
export { default as mutation1 } from './mutations/mutation-1';
export { default as mutation2 } from './mutations/mutation-2';
Is Harlem suitable for large projects?
Absolutely! Harlem is currently being used by Fathom to power their extensive financial intelligence product. The Fathom implementation consists of several stores with hundreds of getters, mutations and actions.
If you are using Harlem in a large project and would be comfortable in sharing your experience, please let me know.