-
Notifications
You must be signed in to change notification settings - Fork 77
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
Resource object name/class inconsistency #94
Comments
I didn't realize that resources without a methods object had a class... If they do, what you suggest makes sense... |
I might be mistaken there, will have to check maybe they didn't have a class. Though I still think it should be consistent, either a class or not |
I agree, though I'll take it a step further. I conditionally wrap injected items with a class because some developers don't use the |
Maybe add it to the global DS configuration as well to allow the default true to be changed to false, while supporting pr resource overrides? |
I would argue it should default to false. Shouldn't make people pay with performance loss on things they don't know that they're getting... |
Resource configurations inherit from the global configuration prototype, so if you set anything on @kentcdodds And I think you're right, it should default to false. When I have time in the next few days I will crank through a bunch of these issues, baby takes priority :) |
Fixed as of 0.10.1. |
When you create a definition for a resource that provides the method object the created instances of this resource will be of a class with the same name as the name attribute in that resources definition
instance.constructor.name === resourceDefinition.name
.But resources defined without the methods object will be of the class Object.
I feel this should be consistent across all instances of resources, and that they should all be of a class by the same name as the resource.
The text was updated successfully, but these errors were encountered: