-
Notifications
You must be signed in to change notification settings - Fork 72
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
Usage without mixins #139
Comments
Any other ideas for how to track |
Great discussion about a similar subject on Ember Simple Auth: mainmatter/ember-simple-auth#1619 |
Looking at the mixins in question, it doesn't seem all that difficult for those who want a more explicit "composition instead of inheritance" option. Example:99% of the complexity in this addon lives on the service, which is excellent. It's very much true that a Router/Component/Object has an object that provides apollo support rather than being an object that includes apollo support. If you don't want to use the For a first-class TS/ES6 approach, looks like the work would be:
|
Since we're discussing a major version bump due to #145, it'd be great for that new version to also include a non-mixin / more typescript-compatible (#140) way of using this addon. In fact if we can introduce such an option even sooner, then we potentially deprecate the mixins and drop them from the new major version. That being said, I read through the ember-simple-auth issue again and I have some concerns about whether it'd be just as easy to drop the mixins from ember-apollo-client. The main distinction I see is that ember-simple-auth typically has very few integration points within a user's app, so the amount of code duplication from dropping mixins is low. ember-apollo-client, however, is commonly used by injecting the mixin all over the place: routes (just a base route in my case), components, etc. I'm less excited about dropping the mixins if it means I have to either a) write my own mixin, or b) duplicate code within my many components that use |
To be clear, we're not aiming to drop mixins from ember-simple-auth -- just to move most of the complexity away from the mixins (as you already have done) so that the project can be consumed in a mixin-free way without a lot of copy/pasting from source |
I've never worked with ember-apollo-client before, but am currently evaluating it. This was one of the first problems that sprung to mind for me and I am happy to see, that this is already being discussed. I couldn't put it better as mainmatter/ember-simple-auth#1619 (comment):
Using a class decorator like import Component from '@ember/component';
import { withApollo, QueryManager } from 'ember-apollo-client';
@withApollo
export default class ExampleComponent extends Component {
apollo!: QueryManager;
} One current drawback of decorators in TypeScript is that they cannot yet mutate the type signature (microsoft/TypeScript#4881), which forces the user to manually type the Instead of making this a class decorator, we could also use a class property decorator, like: import Component from '@ember/component';
import { queryManager, QueryManager } from 'ember-apollo-client';
export default class ExampleComponent extends Component {
@queryManager apollo!: QueryManager;
} This would be similar to how service injections work: import Component from '@ember/component';
import RouterService from '@ember/routing/router-service';
import { service } from '@ember-decorators/service';
export default class ExampleComponent extends Component {
@service router!: RouterService;
} This would also logically couple the import Component from '@ember/component';
import { queryManager, QueryManager } from 'ember-apollo-client';
export default class ExampleComponent extends Component {
@queryManager store!: QueryManager;
} I don't know, if this is a good thing, but I like the symmetry with Anyhow, another advantage is that we can use the same decorator for all types of objects, since the decorator can query the type of the decorated class. |
I implemented https://github.com/tchak/ember-apollo-client/tree/drop-mixins |
@tchak That approach seems very interesting. I will give it a try this week and see how it goes. |
When using ES Classes and/or TypeScript, it is not the best approach to use mixins. I know is possible, using
class XYZ extends Component.extend(Mixin) { ...
but it would be nice to not have an alternative to using mixins.The text was updated successfully, but these errors were encountered: