Typescript компилится в любом случае не смотря на ошибки(если прямо не указано обратного).
А почему он не проверяет push? Х.з. забыли пофиксить наверное. Пару версий назад можно и так было делать:
profesor08, яж не спорю. Но nuxt !== SSR. SSR это технология, которая используется в том числе и в nuxt, помимо кучи всего иного. SSR, как я уже сказал, не имеет никакого отношения к пробрасываю api, это особенности реализации.
profesor08, т.е. заменить запросы к внутреннему api запросами к внешнему api создаваемому nuxt или иной прокладкой. Это какбэ обычный back-end. К SSR никакого отношения такое поведение не имеет.
Только вместе с родителем. Каждый z-index создаёт свой контекст наложения, все z-index внутри рассчитываются исключительно от непосредственного родителя. Если внутри .a лежит .b с z-index: 1, а внутри .b лежит .c z-index: -100500, то .c относительно .a имеет тот же z-index что и .b(1), потому что для .a - ".b и его дети" - единый контекст.
Тогда это имеет некоторый смысл.
Сам никогда так не делал, но теоретически тебе надо сделать простейший mode: 'server'плагин, пробрасывающий нужные модули в контекстasyncData, а в самом asyncData в зависимости от process.server использовать тот или иной вариант.
С практической точки зрения всё ниже уже объяснили. С точки зрения назначения же свойство и метод точно также отличаются. Геттеры и сеттеры предоставляют именно свойство объекта, пусть и вычисляемое. Методы могут воплощать любую логику, свойство же всегда должно иметь конкретное значение.
Bavashi, "В данном договоре г. Москва утверждается наследным владением г.Собянина."
Не говоря уже о том, откуда, перешибить вас всех коромыслом, программный код будет знать кто может там договариваться, а кто нет? Вручную забитые петабайты соотношений? Разве что нейронка, но это отдельная тема.
А почему он не проверяет push? Х.з. забыли пофиксить наверное. Пару версий назад можно и так было делать: Можешь запилить им issue на github'e.