export function UnwrappedActions() {
if (!(this instanceof UnwrappedActions)) return new UnwrappedActions();
this.actionXXX = function(arg1, arg2) {
};
}
export default Alt.createActions(UnwrappedActions());
But usually for async requests, I create a Data Source that I would bind to MyStore
so that my action function would look like this:
updateParticipants() {
this.dispatch();
MyStore.fetchParticipants();
}
The source file would be named something like MySource
and it would dispatch an action like updatedParticipants(response)
which the store would listen to for updated data.
Subject: NPM vs github and cyclical dependencies?
I'm trying to build them from source and completely remove any reference to the FB flux dispatcher entirely. The "BSD+Patents" has not been changed for flux at all (and by holding to the older version, it means holding to an older version of fbjs which also has not been re-licensed the way 0.8.16 has). This is a blocker for my project; I'm only allowed MIT items.
And in trying to run the tests of the other items (utils, container), I'm finding dependency issues.
The npm package of 0.18.6 seems to include some of alt-utils and AltContainer in it. This allows the github drop of the separate alt-utils to have access to AltContainer. However, if I instead point my alt-utils to my local copy of alt (necessary because again I don't want that flux to ever be downloaded), those files are missing. They're in npm but not github for plain 'alt'.
This means I can't fully run the unit tests of alt-utils to be sure I've not broken anything with my alternate dispatcher. It is also worrysome in that by installing both alt and alt-container from npm, I'm getting two copies of alt-container and not sure if I'm actually running the most stable version.
Any comments on how I could deal with this?
class CredentialsActions {
constructor() {
this.generateActions('saveCredentials', 'doLogin');
}
}
export default alt.createActions(CredentialsActions);
those two together produce alt.actions.CredentialsActions.saveCredentials and doLogin for me. that wraps all the picky details about SAVE_CREDENTIALS so i don't have to deal with it.