Resource object name/class inconsistency

[kenjiqq]

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.

[kentcdodds]

I didn't realize that resources without a methods object had a class... If they do, what you suggest makes sense...

[kenjiqq]

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

[jmdobry]

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 methods configuration wouldn't want to added overhead of every single item being wrapped by a constructor function. I'll add a configuration variable per resource definition that enables/disables wrapping items in the constructor. I think it should default to true.

[kenjiqq]

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?

[kentcdodds]

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...

[jmdobry]

Resource configurations inherit from the global configuration prototype, so if you set anything on DS.defaults it will propagate to the resources.

@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 :)

[jmdobry]

Fixed as of 0.10.1.