Scope

What's changed:

• Avoids item refetching for new items (i.e. without primary key) which partially fixes - App: Calls to undefined from presentation links within translations interface #20880
• Avoids unnecessary fetches for when there are no relational fields
• Avoids refetches when changing other fields inside the vform
• Now correctly uses relational data from when the user updates nested fields

Sadly the translation interface issue has thus far eluded my fixing wrath

Potential Risks / Drawbacks

• Potentially breaking existing links for users but my (ofc limited) tests were good

Review Notes / Questions

So after looking into how the presentation-link component works I found out that the only reason we are fetching data at all is because of relations. For the other fields we can just access values of the v-form. For relations however we need to resolve the relation of course so we use the api to get the needed nested-fields.

This uncovered to me that we can optimize this component in the following ways:

1. We dont need to fetch anything as long as we dont use relations. We can check beforehand whether or not the templated string contains relations.
2. We only need to resolve the relation to get the nested-value, if that nested-value has not been edited. This is because if the value got edited, it will appear in the v-forms provided values.
3. This is another bug currently where we dont actually update the presentation-link to use the edited nested-value. Currently we only use the api response for that. This is inconsistent because we do use the edited values for non-nested fields in the presentation-link.
4. And there is another bug when dealing with the translation interface: If you have a translation interface that contains presentation-links, said links will not be able to use relational fields such as languages.code up until you change one field inside the translation-interface because that leads to a create call in use-relation-multiple.ts which initializes the edited values with our $type and $index notation.
5. If we'll merge this it'd be good to open a new improvement-issue to allow refetching when changing an existing relation to a new relation for example you change your existing m2o relation from ID=1 to ID=2