biril / backbone-faux-server

A framework for mocking up server-side persistence / processing for Backbone.js
MIT License
54 stars 11 forks source link

Make it so that you don't have to manually create fully-qualified models... #10

Closed nthsense closed 1 month ago

nthsense commented 10 years ago

... in the result handler. Instead, the result handler can return pure JSON and Backbone & Backbone.Relational will handle turning the result into Backbone Model instances. This also helps for cases where you're just using the Backbone Model to make the request and you're doing something unusual with the result in your model's success handler. Specifically, if the server returns an array in response to a GET call, we want faux-server to return that same array, and we want to do something with it in our success handler - but with faux-server calling resolve(result), we got a Backbone error that parse() was undefined.

biril commented 10 years ago

Hey, thanks for the input. I will have to look further into what you're proposing / want to do later on, but until then a couple clarifications:

"Make it so that you don't have to manually create fully-qualified models in the result handler. Instead, the result handler can return pure JSON and Backbone & Backbone.Relational will handle turning the result into Backbone Model instances."

I assume that in this context you're referring to route-handlers? If so, then what you're suggesting is how it currently works. Taken from the readme:

On success, the handler should return created Model attributes after handling a POST and updated Model attributes after handling a PUT or PATCH. Return Model attributes after handling a GET or an array of Model attributes after handling a GET that refers to a collection. Note that only attributes that have been changed on the server (and should be updated on the client) need to be included in returned hashes. Return nothing after handling a DELETE. On failure, the handler should return a string (presumably a custom error messsage, an HTTP status code that indicates failure, etc).

In the above, 'attributes' or 'hash' refer to plain objects which can be indeed represented as 'pure JSON'. Not models. It seems to me that this is basically what you want to be doing.

Regarding the undefined parse() that you mention, I'm guessing you're returning an array in response to a GET request for a model resource? If so, it's normal that this would produce an error as there's no defined way of converting an array into a model - and Backbone will try to do that. In absence of a custom parse() defined for exactly this purpose it will fail. You would get the same error returning an array from your server.

Let me know if this covers you or you want some other clarification or I'm missing your point, etc .. :)

nthsense commented 10 years ago

Thanks for the response. You're correct that I am returning an array in response to a GET on a plain vanilla Backbone Model - I agree it's a bad way to use Backbone, but this is legacy code I'm dealing with. We use the success handler to get the response and do stuff with it, and Backbone never complains. It seems to me that faux-server should be a drop-in replacement for a real server, and our Backbone code - good or bad - shouldn't have to be changed. That's what I've attempted to do with this pull request.

Regarding the "create fully-qualified models in the result handler" - really, this is another symptom of the same problem which is that Backbone's success and error handlers expect certain arguments to be passed to them, and as far as I can see, faux-server doesn't honor that contract in all cases. From the Backbone documentation:

save accepts success and error callbacks in the options hash, which are passed (model, response, options) and (model, xhr, options) as arguments

The way it was before, I was getting whatever was returned from the route-handler in the first argument of the Backbone success handler, and my code depended on that being the actual Backbone model, not some JSON.

Hopefully, that's clearer. :) I really like this library, it's helping a lot with unit testing.

biril commented 10 years ago

You're right, the primary goal here is uniform behaviour - no code changes should be necessary when switching between faux / actual server.

I'm writing some extra tests to clarify behaviour regarding success & error callbacks (they will be added to the test suite in due time) and for now I'm not observing anything unexpected. That is to say, success callbacks are indeed passed model, response, options.

For the case of returning an array, it works as you describe (although, admittedly I wasn't expecting that). Backbone won't complain and the array-response is available in success callbacks. (As a side-effect, array elements are converted to attributes with array-index names ('0', '1', ..) but that's not relevant to the issue.)

So, thus far, I haven't been able to figure out what causes the behaviour you're describing.

Which BB version are you using? Is it by any chance < 1.0.x?

sonarcloud[bot] commented 1 month ago

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud