IB
Parent -> child
Size: a a a
2020 July 18
MU
тут slug и productId разве не одно и тоже?
нет разумеется, иначе бы они одинаково назывались бы
IB
@andreynazarov я кстати соглашусь с максимом, asyncData/fetch на каждом уровне - абсолютно нормальная практика
АН
нет разумеется, иначе бы они одинаково назывались бы
странно както
MU
странно както
что именно?
IB
Потому что у каждого "слоя" своя информация, которую должен получить
АН
что именно?
ну тоесть /product/123 это 123= слаг а /product/123/spec тут 123 это productId
MU
ну тоесть /product/123 это 123= слаг а /product/123/spec тут 123 это productId
по идее
но я скинул методы запроса к беку
но я скинул методы запроса к беку
MU
не URL роута
MU
так устроена архитектура API и как-то изменить ее не вариант
АН
тоесть вы получаете slug и надо сначала сходить в api чтобы получить id и потом уже с ним идти получать spec
АН
почему api не может сразу spec выдать конечно печально)))
MU
почему api не может сразу spec выдать конечно печально)))
потому что эти данные не относятся к основному роуту и не нужны всем пользователям
АН
но бек же знает slug->id, оно может выдать spec
MU
но бек же знает slug->id, оно может выдать spec
я не знаю особенностей реализации бека)
MU
то есть на бек я не повлияю сейчас никак
IB
В общем, я тоже мучался с параллельными вызовами asyncData, а потом мы перешли на fetch-хук и в нём все работает логично (т.к. в нем есть this-контекст, т.е. доступны пропсы, которые могут зависеть от результатов fetch выше по иерархии)
АН
то есть на бек я не повлияю сейчас никак
в качестве костыля в ребенке просто делайте тоже самое что в родителе и все
MU
В общем, я тоже мучался с параллельными вызовами asyncData, а потом мы перешли на fetch-хук и в нём все работает логично (т.к. в нем есть this-контекст, т.е. доступны пропсы, которые могут зависеть от результатов fetch выше по иерархии)
то есть ты имеешь ввиду, что нужно id прокидывать пропсом в nuxt-child, а не сетить в store, и таким образом сохранится привязка по иерархии?
АН
типа if (id == null) dispatch('get/id')