GraphQL介绍-3 Aliases,Fragments,Operation Name

已经会CRUD了,还要学什么？

再来是介绍一些个人觉得在GraphQL里比较花俏的操作,虽然说是花俏,但使用的恰当的话同样可以帮助我们更好的维护程式

不学会怎样吗？

其实当初笔者在学习GraphQL时,直接跳过了这一篇和下一篇提到的内容,就开始使用GraphQL建立后端的Server了,也是在一段时间后才回来补这段GraphQL的技术(知识),所以如果读者非常期待(急着)能看到结果的话,可以直接跳过这一篇和下一篇直接进入实战环节

Aliases

why use?

还记得前面有提到我们可以把两个query包在同一个request吗？但如果今天我要同时查meals里面的牛肉麵和水饺的资料可以怎么做？
步骤1.找出全部的meal,所以使用meals进行查询

再来就是问题所在了,如果我想要对水饺和牛肉麵的价格进行编辑,以前端来说,可以在资料列表看到它们两后"分别"点击它们对他们进行编辑

例如我们边点击水饺后大概会看到类似这样的前端页面,让我可以进行编辑

对于User来说他需要点点水饺编辑完后再点牛肉麵进行编辑,这样的设计使他不能一次编辑多笔资料,可能会让他使用起来有些不方便,因此我们可以设计成类似这样的画面

理论上我们选完了牛肉麵和水饺,并且知道了他们的id应该就是把两个meal的完整资料在表单,透过以下语法进行查询

query{  meal(id:"58811ae5-1471-4366-844b-2886b3abccf1"){    id    itemName    price  }  meal(id:"19506d93-d6dc-486e-8b08-5c6045f8d348"){    id    itemName    price  }}

然后就出事情了,语法并不支持我们这样做

因此我们需要使用Aliases来替我们解决问题,使用方法为

# Write your query or mutation herequery{  meal1: meal(id:"58811ae5-1471-4366-844b-2886b3abccf1"){    id    itemName    price  }  meal2: meal(id:"19506d93-d6dc-486e-8b08-5c6045f8d348"){    id    itemName    price  }}

因此我们大概会在前端看到这样的画面

Aliases小结

原则上就是当两个以上相同的field name时,可以自己为它命一个别名,以上就是笔者认为比较有可能遇到的情境之一,当然以上的做法当然可以把所有的值存在靠浏览器cache起来在各个页面之间传递资料,不过这不是我们要讨论的事情,也不会是最理想的做法.

Fragments

why use?

虽然Aliases可以帮我们解决掉重複query重一个field时的情况,但如果是以下状况可读性就越来越差了

query{  meal1: meal(id:"58811ae5-1471-4366-844b-2886b3abccf1"){    id    itemName    price    unit    specialOffer    isStopSelling  }  meal2: meal(id:"19506d93-d6dc-486e-8b08-5c6045f8d348"){    id    itemName    price    unit    specialOffer    isStopSelling  }  meal3: meal(id:"f96d8779-1981-400a-b5b0-45ef36b7f6e8"){    id    itemName    price    unit    specialOffer    isStopSelling  }  meal4: meal(id:"251188ae-bc8c-4f37-b809-1884f0f6283e"){    id    itemName    price    unit    specialOffer    isStopSelling  }}

基本上有两个很大的问题,第一个为原则上我要取得的itemNmae,price诸如此类的东西是一样的,但我却要重複的写一样的内容,第二个为假设我真的有特殊状况为我只有最后一笔要有isStopSelling,也会变得非常的不易读,因此我们可以使用Fragments来帮我们完成,以下为範例

# Write your query or mutation herequery{  meal1: meal(id:"58811ae5-1471-4366-844b-2886b3abccf1"){    ...mealData  }  meal2: meal(id:"19506d93-d6dc-486e-8b08-5c6045f8d348"){    ...mealData  }  meal3: meal(id:"f96d8779-1981-400a-b5b0-45ef36b7f6e8"){    ...mealData  }  meal4: meal(id:"251188ae-bc8c-4f37-b809-1884f0f6283e"){   ...mealData    isStopSelling  }}fragment mealData on Meal {  id  itemName  price}

可以看到把共同需要回传的field names用...mealData表示后在最下面只要透过fragment就可以完成了,此外,最后一笔才有isStopSelling也可以比较明确的看得出来

Fragments小结

当你使用Aliases到一定程度后,可能会觉得code有点不好维护,这个时候就可以透过Fragments,甚至也可以处理一些field names不一的情况

Operation Name

why use?

笔者的经验是前端在使用api时,很常会同时query多个资料,这点对于维护者或是任何人看起来都会非常的难受,如下图

虽然我们可以从上述语法中了解,它同时查了meal和user但这件事情本身非常的不直观,因此我们需要帮这个query命一个名称

会发现得到的结果居然完全一样,那为什么要这样做？
虽然结果是一样的,但不同的是在读code时看到mealAndUser就可以很明确的知道这边在做什么事情

Operation Name小结

笔者觉得它完全是偏向维护的概念来使用的,不像Framents和Aliases,是真的在某些时候你使用了它时,是以让程式更乾净或是增加前端效能为目的的去使用

以上若有错误,还请不吝指教.谢谢

下一篇 GraphQL-Variables, Directives, Enumeration Types