store: The connectTo decorator doesn't work when using canActivate
One of my use cases is needing to check if a view-model can instantiate by checking if a project exists. Basically, I have a bunch of projects and you can view a singular project.
This is what it looks like.
async canActivate(params) {
await this.store.dispatch(getCategories);
await this.store.dispatch(loadProjects);
const project: any = this.state.projects.reduce((project, currentItem) => {
if (currentItem.slug === params.slug) {
project = currentItem;
}
return project;
}, {});
if (!project.slug) {
return new Redirect('');
}
this.project = project;
this.projectAdded = new Date(project.added).toDateString();
}
If I use connectTo
on the class, it applies the state too late to the view-model. However, if I manually add the subscriber from inside of the constructor
it allows me to do this check.
this.store.state.subscribe(
(state: State) => this.state = state
);
The question here is: am I doing something wrong in my workflow or is the connectTo
decorator the incorrect thing to use in this situation?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 17 (11 by maintainers)
Commits related to this issue
- feat(connecTo): setup and teardown functions ability to define custom setup and teardown functions instead of using the default bind/unbind. related issue: https://github.com/zewa666/aurelia-store/i... — committed to aurelia/store by zewa666 6 years ago
- feat(connectTo): onChanged callback provide a string of a function to be called when the state changes related issue https://github.com/zewa666/aurelia-store/issues/20 — committed to aurelia/store by zewa666 6 years ago
- docs(connectTo): info for the additional props more info about the new decorator properties setup, teardown and onChanged related issue: https://github.com/zewa666/aurelia-store/issues/20 — committed to aurelia/store by zewa666 6 years ago
- fix(connectTo): call handler before state assignment first call the onChanged handler and then assign the state, so that the handler has access to both the previous and current state related issue: ... — committed to aurelia/store by zewa666 6 years ago
- chore(merge): merging setup-teardown-decorator feature Related issue: https://github.com/zewa666/aurelia-store/issues/20 — committed to aurelia/store by zewa666 6 years ago
Right that was my thinking as well, the only generic part would be bind/unbind for all of them. Given that canActivate is likely either Router or Dialog related I think in that case one should prefer a normal subscription.
What would be possible is to let the user define the hooks for setup and teardown, but honestly this way the complexity of connectTo increases so much, that it’s really not worth anymore to cary that cognitive load.