spa-starter-kit: Error Handling, Validators, the Interceptor and Response Formats

Just a few thoughts, suggestions and observations here…

There are a few strategies in Laravel/Eloquent for creating and saving models. We typically test for…

// We have static event rules on the model. This will return a 422 invalid entity response
$this->validate($request, Product::getCreateValidationRules($id), Product::getCreateValidationMessages());
$attributes = $request->all();
$event = new Product($attributes);
if($event->save())  {
    ...
   // Send success response - 200
} else {
  // Send failed response - or exception 
}

Or for updates…

$this->validate($request, Product::getUpdateValidationRules($id), Product::getUpdateValidationMessages());
// This will automatically send a 404 not found response - although probably not what you 
// want if you are going to transform the output - see below...
$event = Product::findOrFail($id);
$attributes = $request->all();
if($event->update($attributes)) {
   // Send success response - 200
} else {
  // Send failed response - or exception
}

Sending a response of return $this->response([ 'result' => 'success',]); is okay, but slightly RPC-ish in so far as the result status is duplicated by the http status - 200 is okay, 422 validation failure, 400 invalid client data, 500 server error etc.

Also I see you’ve included league/fractal package for response transforms which is excellent. The maintainers of the package refer to HAL, and JSON-API as possible output formats. A complete API design might be outside the scope of your starter pack - but there are some great pointers in http://stateless.co/hal_specification.html, http://jsonapi.org/format/ (albeit a bit 'rails-ish) , and even https://github.com/argo-rest/spec Here’s an example format for an in-house API we created. Error, and Errors are first class - https://gist.github.com/58bits/aa14c7a8f525a074f7a6aaf5b9dd60b6

It might be nice if you created a simplified version of any of the above, using league/fractal transformer to create an API response format to abstract away from Laravel’s default Json response - which would nicely decouple your starter-pack from Laravel itself.

Also in terms of handling errors in the http plugin (Axios) - you’ve got a great global error handler in the interceptor, but sniffing for the return type (array or object) to determine the error type is a little brittle. With a standard response format, and errors, response codes, all first class, you can make the switch based on the response code and data itself (e.g… 422 for invalid entities etc. - and then check for the error or errors properties.)

In the http client for the entities/forms, I also think you still need a catch handler (even if it’s empty), for example…

update () {
        this.$http.put(`events/${this.event.id}`, this.event).then(() => {
          /**
          * This event will notify the world about
          * the event creation. In this case
          * the Event main component will intercept
          * the event and refresh the list.
          */
          this.$bus.$emit('event.updated')

          /**
          * Hides the global spinner
          */
          this.setFetching({ fetching: false })

          /**
          * Sets the global feedback message
          */
          this.setMessage({ type: 'success', message: 'Event was updated' })
        }).catch((error) => {
          console.log('our own error handler.')
          console.log(error)
        })
      },

… Otherwise axios will generate an uncaught in Promise exception, and dump this to the console as…

Uncaught (in promise) Error: Request failed with status code 422
    at createError (eval at <anonymous> (app.js:876), <anonymous>:15:15)
    at settle (eval at <anonymous> (app.js:1104), <anonymous>:18:12)
    at XMLHttpRequest.handleLoad (eval at <anonymous> (app.js:858), <anonymous>:77:7)

Very lastly, just in case you or anyone else is using Xdebug to debug your PHP API server (Laravel in this case), here’s an updated interceptors.js file, which will add the XDEBUG_SESSION_START parameter to the query string (or post values) for all requests, to tell XDEBUG to debug the request. This is a a little hacky, and I’m using PHPStorm as my debugger client. The session identifier is generated by PHPStorm (which is listening for incoming Xdebugger requests). XDEBUG_SESSION_START can be used for the same session repeatedly, and it’s a better method than trying to set the XDEBUG_SESSION session cookie, as cookies will fail to be set if you’re making a CORS request to the API server.

https://gist.github.com/58bits/c7b7dccf3f922fde13275d1a54990838

And the PHPStorm docs for setting up Xdebug here… https://www.jetbrains.com/help/phpstorm/2016.2/configuring-xdebug.html

Hope some of this helps, and thanks for the great starter kit. It’s helping us a lot in getting started with Vuejs.org.