sharedCtor not working - examples borked

[fabien]

It seems that the sharedCtor implementation has changed, causing the current examples (in /example) to fail without any output (HTTP: 204). SharedMethod.toResult returns undefined, causing subsequent instance method calls to fail.

Run: /example/shared-class.js and visit http://localhost:3000/dog/fido/speak

Shared class \"dog\" has no method handling GET /fido

[bajtos]

I am able to reproduce the issue as well. We should add a test running this example to make sure it won't get broken again.

[bajtos]

FWIW, the 2.0 branch crashes the app:

strong-remoting/node_modules/express/lib/router/index.js:140
    old(err);
    ^
TypeError: undefined is not a function
    at strong-remoting/node_modules/express/lib/router/index.js:140:5
    at strong-remoting/node_modules/express/lib/router/index.js:265:10
    (etc.)

[fabien]

I was under the impression that sharedCtor will be deprecated with 2.x, since exposing instance methods would be deprecated too. Is this the case?

PS as a newcomer to Loopback, I have to say I was put off quite a bit when such a basic example seized to work from the get go.

[ritch]

@fabien thanks for the feedback.

I am able to reproduce the issue as well. We should add a test running this example to make sure it won't get broken again.

Good call. Will update this issue once that has landed.

[fabien]

@ritch will sharedCtor be preserved in 2.0? In other words, can API calls still call instance methods (as being used by Loopback internals/relations)? I highly depend on that behavior for my apps. Could you please confirm that this won't break in the future?

[fabien]

@bajtos @ritch see the inquiry above - my app heavily depends on instance methods to be exposed over REST/remoting, so I'm concerned about this being preserved in 2.0 and onward. Would there ever be a valid reason for dropping this functionality at all? I don't think there is.

[raymondfeng]

We'll keep the functionality, not necessarily the same implementation.

For the record, sharedCtor is a special case of 'ResourceLocator' which locate sub-resources by id, name or other properties. One potential solution is to allow SharedClass to have both SharedMethods and Locators which pulls in other SharedClasses. It will build the hierarchy of resources that map to REST endpoints.

[ritch]

my app heavily depends on instance methods to be exposed over REST/remoting

This is good to hear. I was under the impression that instance methods were not being used or were not really that useful. If it is a useful feature I am fine with keeping it.

The reason why I wanted to get rid of the support is that sharedCtor makes strong-remoting dependent on JavaScript constructors / prototypes. It would simplify the API, internal implementation, and integrations with strong-remoting quite a bit if we only supported functions.

Maybe we should just add better support for plain JS functions and maintain support for sharedCtor. Anyways thanks for bringing this up.

[fabien]

@ritch thanks for your input! Instance methods are vital to many of the things I'm doing in my app(s), and that would be impossible or at least very cumbersome otherwise. The elegance of how strong-remoting exposes instance methods was one of the main things I considered when evaluating Loopback as a step up from my own framework.

Mind you, I was able to transfer a lot of the functionality I had developed in my own Loopback-like framework because of this; the current implementation is a lot cleaner and better in many ways.

[raymondfeng]

@ritch Did we fix the issue?

[fabien]

@raymondfeng @ritch examples still borked, I can't get examples/shared-class.js to work at all (and it crashes). Please fix.

[raymondfeng]

Fixed now.