Closed iamnirav closed 9 years ago
import Alt from 'alt';
const alt = new Alt()
const MyActions = alt.generateActions('mySpecificAction')
alt.createStore(class MyStore {
constructor() {
this.bindActions(MyActions); // works fine
}
mySpecificAction() {
console.log(alt)
}
})
MyActions.mySpecificAction()
I get the console.log to output fine here
These are the basic snippets I did
// ServerActions.js
'use strict';
import alt from '../alt';
import debug from 'debug';
const debugServerActions = debug('messag:serverActions');
class ServerActions {
login() {
// some codes here ...
}
logout(){
// other codes
}
}
export default alt.createActions(ServerActions);
// AuthStore.js
'use strict';
import alt from '../alt';
import ServerActions from '../actions/ServerActions';
import debug from 'debug';
const debugAuthStore = debug('messag:AuthStore');
class AuthStore {
constructor() {
debugAuthStore('ServerActions', ServerActions); //undefined
this.bindActions(ServerActions);
this.state = {
};
}
login(){
}
logout(){
}
}
export default alt.createStore(AuthStore, 'AuthStore');
// and the same in ThreadStore.js
I found that actually debugger
doesn't always have access to all references in the current context. This is due to some browser implementation details—there are vague references to this around the internet (though I can't seem to find one right now :disappointed: ).
This is an issue with chrome's debugger and keeping closed over references in context when using things like eval or Promises. From what I understood, it's a wontfix on their end because resolving the scope every time is a massive perf hit and this was sort of edge case, now with promises being used more in the wild I'm not sure what they'll come up with.
@iamnirav I've run into that. I always assumed it to be the result of a runtime optimization off some sort. It's you assign out to a temporary variable in the scope you need to debug, you can access it.