You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A Vue instance is like a backend inside the frontend. The store represents the DOM of the Vue Single Page Application. The SPA practices CORS (Cross Origin Resource Sharing) with a true backend on whatever domain. The http service responds with a json:api document representing generic information to be rendered in the browser or for other purpose. In both cases it is an anti-pattern to put the json:api document from the http service in the Vue store because the store represents the DOM of the SPA. Instead of that implement a plain Node.js module outside Vue Components and the store to place the json:api response and implement CRUD AJAX procedures. I see the json:api document similar to html labels but representing information for whatever purpose. That document is loaded asynchronously by the SPA but: why to load the document in the store? The store is the DOM (Document Object Model) of the SPA. Components in the SPA may have a detailed DOM through computed properties and getters implemented in the store.
Using a json:api document as the data structure of a Single Page Application is, in itself, an anti-pattern as well.
The programmer of each SPA should chose the data structure that best fit in the Application. When the SPA make an asynchronous http request to a remote http service, the service will respond with an json:api document. But the http service doesn't know the data structure of the consumer Single Page Application. So, to provide a standard data-structure-agnostic response, the Content-Type json:api has been specified. The http service responds with a json:api document that is data-structure-agnostic (unopinionated) regarding data structure of the consuming Single Page Application. So the Content-Type json:api is just a standard agnostic response that every http service should implement.
The text was updated successfully, but these errors were encountered:
A Vue instance is like a backend inside the frontend. The store represents the DOM of the Vue Single Page Application. The SPA practices CORS (Cross Origin Resource Sharing) with a true backend on whatever domain. The http service responds with a json:api document representing generic information to be rendered in the browser or for other purpose. In both cases it is an anti-pattern to put the json:api document from the http service in the Vue store because the store represents the DOM of the SPA. Instead of that implement a plain Node.js module outside Vue Components and the store to place the json:api response and implement CRUD AJAX procedures. I see the json:api document similar to html labels but representing information for whatever purpose. That document is loaded asynchronously by the SPA but: why to load the document in the store? The store is the DOM (Document Object Model) of the SPA. Components in the SPA may have a detailed DOM through computed properties and getters implemented in the store.
Using a json:api document as the data structure of a Single Page Application is, in itself, an anti-pattern as well.
The programmer of each SPA should chose the data structure that best fit in the Application. When the SPA make an asynchronous http request to a remote http service, the service will respond with an json:api document. But the http service doesn't know the data structure of the consumer Single Page Application. So, to provide a standard data-structure-agnostic response, the Content-Type json:api has been specified. The http service responds with a json:api document that is data-structure-agnostic (unopinionated) regarding data structure of the consuming Single Page Application. So the Content-Type json:api is just a standard agnostic response that every http service should implement.
The text was updated successfully, but these errors were encountered: