How to design API driven Web components? Is it a good pattern?

I am working on a project which creates APIs using Flask and web UI based on ReactJS. Since it is a very early stage of the application most of the times our APIs change in terms of fields and links of the resources. and due to the change in the APIs and addition of more resources, routes and depth we have to change in the frontend too, which seems pretty repetitive.

So I started thinking of how can we avoid these changes on multiple locations for the same cause. One approach which I can instantly see is to define these web components definitions in API itself and build it in such a way that if my models or API definition changes, API definition of web components will also adjust itself. And since frontend will be based on very generic definitions it will automatically change visuals based on API definition.

For example: There is a USER model which initially did not have city field in it and so the form for sign up in frontend. And now if I add city field in model then API based form definition will automatically get the new field and adjust the form definition in API. Now if someone clicks on signup new definition of Form will be picked from API and frontend will render that form with the new field in it. So here I just need to change it at one place in this example which is model.

But now this pattern pops up few questions which are hard to get answer of, at this early stage of project for me, question are:

1. Is it right pattern for the big project?
2. Is it a scalable solution for API driven micro-services based project?
3. Will there be conflicts if there are multiple teams working on this kind of project?
4. How will I be able to maintain API versioning for such project?
5. Is it good to cache APIs which are mostly frontend component definitions?
6. Is there any other pattern which I can follow to reduce repetitive tasks keeping project based on micro-services?