Specific mutations that correspond to semantic user actions are more powerful than general mutations. If you start with a general “catch-all” mutation, adding extra inputs is much more difficult.ĭon’t be afraid of super specific mutations that correspond exactly to an update that your UI can make. For example, in the future you might want to send a new input argument with one of your emails. This is not a good design because it will be much more difficult to enforce the correct input in the GraphQL type system and understand what operations are available in GraphiQL. You may be tempted to create a mutation like sendEmail(type: PASSWORD_RESET) and call this mutation with all the different email types you may have. The password reset email case is also a good use case for illustrating why you want specific mutations over general mutations. This mutation is more like an RPC call then a simple CRUD action on a data type. To actually send that email you may have a mutation named: sendPasswordResetEmail.
For instance, say you were building a password reset feature into your app. However, many applications have mutations that do not map directly to actions that can be performed on objects in your data model. When all your mutations are centered around a handful of object types this convention makes sense.
This is useful for schemas where you want to order the mutations alphabetically (the Ruby GraphQL gem always orders fields alphabetically) and your data model is mostly object-oriented with CRUD methods (create, read, update, and delete). Some teams, like the GraphQL team at Shopify, prefer to write names the other way around - userCreate over createUser. Names like createUser, likePost, updateComment, and reloadUserFeed are preferable to names like userCreate, postLike, commentUpdate, and userFeedReload. Your mutation represents an action so start with an action word that best describes what the mutation does. In short, try to name your mutation verb first. This article will explain the rationale behind each of these points and equip you to design an effective GraphQL mutation system for your API. Nesting. Use nesting to your advantage wherever it makes sense.Unique payload type. Use a unique payload type for each mutation and add the mutation’s output as a field to that payload type.Input object. Use a single, required, unique, input object type as an argument for easier mutation execution on the client.Mutations should represent semantic actions that might be taken by the user whenever possible. Specificity. Make mutations as specific as possible.Then the object, or “noun,” if applicable. Naming. Name your mutations verb first.The main points to consider when designing your GraphQL mutations are: Makes two files along with index.html of a prerendered page: payload.js for initial page load and payload.Designing a good GraphQL API is tricky, because you always want to balance utility and convenience with a consideration around how the API may evolve in the future.
Use NuxtServerInit action for global vuex data or return your vuex data from asyncData to make it work. Are you filling your vuex store with page-specific data? It will break on client-side navigation.Add asyncData custom logic with $payloadURL helperĪsync asyncData().✓ Decreases initial page download time x1.5-2 (which is actually doesn't affect perfomance) Setup ✓ Makes prerendered and client rendered pages consistent in case API data changed after you deployed prerendered pages ✓ Increases page download speed for crawlers With this module your API data stores along with prerendered HTML, so the issue is solved ✓ If you use external API to fill your project with data, even after your site has been prerendered, you need to keep your API running to make client-side navigation possible. You might want to try it out before using this module, it is much more powerful. ⚠️⚠️⚠️ This feature called "full static generated mode" has been released as a native Nuxt.js feature recently. See it in action on my site: DreaMinder.pro Nuxt.js module that makes nuxt generate command to store data payload in dist dir implementing full static generation.
0 kommentar(er)
