docs(readme): clarify use of reply.viewAsync

[mohd-akram]

Checklist

• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[Eomm]

How removing the Migrating from view to viewAsync section, clarify the viewAsync method?

[mohd-akram]

It's not clear to me why a migration is necessary. The reason given is that view "short-circuits fastify's error handling hooks". That doesn't seem to be true? This leaves the remaining use which is "fastify.view has no mechanism for providing request-global variables". There also some other issues IMO with this:

• Suggesting using reply.viewAsync in a sync handler seems strange and unnecessary
• Suggesting to always replace fastify.view with reply.viewAsync seems wrong. One is a pure render function and the other changes the state (see next point).
• reply.viewAsync is behaving as both a get and a set, which is not great in terms of encapsulation. It returns the rendered view, but also seems to set the content type header.
• reply.viewAsync precludes template engines that might support streaming
• Applications tend to have many routes returning views. Suggesting to migrate from one method to another without providing clear benefits can cause a lot of unnecessary churn

[Eomm]

Suggesting to migrate from one method to another without providing clear benefits can cause a lot of unnecessary churn

So the solution is not to remove the section, but at least compare these 2 methods more deeply.

The migration was necessary 1y ago when the feature has been added, maybe today it is no more necessary and we should simply document the APIs so users may chose the best fit for them

[mohd-akram]

I don't think there's a significant difference between them. One lets you get the HTML text and the other doesn't. I kept that part. The rest of the section is just repeating things already mentioned in the README. I guess I can add how to use reply.viewAsync in a synchronous handler? That should cover all the bases.