New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minimal loader example #23
Comments
My current plan:
|
This is taken care of by PR #27 Refactoring the discourse loaders will be done when everything is ready. |
Reopening this issue because I'm not quite happy with the current implementation. I just tried imagining how I would explain to people that connectors get attached to the context and realized that this will be really confusing for almost everyone. PS: I'm calling them connectors now, I think it fits better, because they're at a higher level of abstraction than the loaders. |
The main reason I did it this way was because the loaders are a pet-request thing:
If you just import them then you don't get the per-request state which I think is pretty crucial. I don't think it had anything to do with a service. |
Yeah, I get that, but I think we can achieve the same with a singleton and it will be less verbose. What do you think? |
If you can, then great! As long as it's also easy to understand. I find Meteor's per-request singletons that switch out using bindEnvironment pretty hard to work with, personally. |
I just want to avoid having too much magic on day 1, because I think it will give people the impression that our thing is very different from plain graphql-js. For the shorthand schema, that's a good thing because our solution feels much better. For the loaders it seems like an unnecessary complication. |
Accomplished this a while ago for the discourse loaders and it looks quite neat, so I'm closing this issue. |
We want to have a minimal example of how loaders would work. What I still have to do for this is:
The text was updated successfully, but these errors were encountered: