Собеседование на FRONTEND Разработчика уровня Senior (Middle +)

Привет, Евгений. Меня зовут Айк. Я фронтенд-разработчик почти уже с пятилетним опытом разработки. Являюсь старшим фронтенд-разработчиком в эстонской компании. И получается сегодня рад тебя видеть для вот обсуждения проведения Vue и просто вот поговорим про Vue, про JavaScript-экосистему, как всё это настроено и какие есть интересные фишки. Ну, в основном Vue именно вообще, э, так как на сегодняшний день React является одним из таких, ну, быстрых фреймворков и развивается достаточно быстро. Несмотря на это, мы должны смотреть и на другие инструменты, такие как вот такой как Vue, который неплохо тоже имеет звёздочки в GitHub и других репозиториях и так далее. Вот, в принципе, достаточно сильный инструмент.

Почему мы и выбрали сегодня Vue для вот обсуждения? Потому что развивается быстрее, чем казалось бы. Почему? Потому что там такие интересные всякие дизайн-паттерны были интегрированы в процессе, которые вот не ожидают даже коммьюнити. Давай, пожалуйста, до Vue расскажи про свой коммерческий опыт разработки и когда тебе приходилось использовать Vue, какие плюсы во время разработки.

Да, привет, тоже. Меня зовут Евгений, кто не знает. Я, в принципе, больше 5 лет в коммерции. Ну, прямо вот так вот плотненько программирую на Vue. Сейчас вот с этого года, с начала этого года перешёл на React. Ну, просто по причине того, что устроился в компанию и там стек другой. И до этого момента у меня весь опыт — это вьюшный. В принципе, я не сталкивался с тем, чтобы вообще какое-то там приложение не собрать на Vue. То есть иногда, да, возникают какие-то проблемы, бывает там, что отличается или нужно какое-то решение прямо придумать, и оно не идеально, так скажем, во вписывается, где-то самописное приходит.

Но это частный случай, прямо, скажем так, большая часть кейсов, что React решает, что Vue решает, что там Angular или любой другой фреймворк, если взять, они решают эту задачу. Но Vue в контексте, если говорить, то мне больше нравится, что часть решений, которые он предлагает, уже как бы есть из коробки, их можно использовать. Ну и, возможно, даже сейчас где-то в некоторых моментах чуть меньше кода надо генерировать. Ну по сути, однотипного там объявления каких-то функций, там переменных и так далее. В React это ты вот больше пишешь вот этот такой небольшой бойлерплейт, скажем так. С учётом того, что да, Vue действительно сейчас развивается быстро, я думаю, что в принципе он наберёт тоже популярность. Единственный момент, который мне, скажем так, наверное, не очень как бы хорошо заходит — это то, что за ним не стоит крупная компания. Ввиду этого, то есть у него, скорее всего, возможен, ну, на мой взгляд, возможен небольшой потолок, ну ограничения в плане какого-то дальнейшего развития. Если что-то с основателем там случится либо с другими членами команды, потому что всё-таки мне кажется, сам создатель как-то курирует направление, ну, и развитие смотрит какие-то идеи, которые применяются в других фреймворках, и пытается их как-то интегрировать и дать нам их как инструмент. То есть, мне кажется, вот Vue — это такой некий такой, такая смесь самого лучшего из других фреймворков и библиотек. Спасибо.

Вот, единственно, подчеркну, такой момент, что если смотреть и экосистему Реакта и вот компанию Meta, которая поддерживает этот инструмент, мы видели это в последних версиях типа девятнадцатой версии Реакта, что что-то наблюдается либо упадок поддержки со стороны, это потому, что мы видели deprecated ряд ресурсов, точнее пакетов, которые достаточно часто были использованы ранее. И это вот вызвало даже панику среди разработчиков, среди коммьюнити, почему всё же было принято такое решение вот сделать deprecated и вообще обновление девятнадцатой версии достаточно медленно шло. Вот многие ожидали более быстро насчёт компайлера того же, который, ну, должно было заменять всякие вот использование колбэков, всякие вот хуки, которые для оптимизации, но при этом мы в конечном итоге получили такой результат, что это не то, что мы ожидали, так долго, да, это пока что вот так себе работает. Конечно, здесь нужно подчеркнуть, что не всегда вот поддержка со стороны крупных компаний — это вот о'кей, бум, всё там всё о'кей, работаем, да, потому что, и для Vue, да, получается, у нас есть, получается, спонсоры, которые поддерживают, партнёры поддерживают экосистему. Это достаточно круто, да, по с этой стороны тоже мы можем думать, да, здесь, кстати, дополню. Отчасти, мне кажется, даже то, что спонсоры какие-то есть, они поддерживают развитие фреймворка, то возможно они являются как бы людьми, к которым прислушивается то, что делает команда Vue и что хочет сообщество. И она, то есть, внедряет уже какие-то дополнительные вот эти фишки или функциональность новую внедряет. То есть последние там патчи, насколько я помню, сейчас с 3.2 там до 3.4, там, в принципе, существенный не такой функционал добавился. Вот Vue Model хорошо там развили. То есть можно делать сразу несколько этих, вешать директив на там на один компонент. Ну я думаю, что мы ещё поговорим об этом.

Угу.

Да. Вот, даже, вот, просто, такой, как бы, пример из того, что прямо сейчас вспомнил.

Супер.

Спасибо.

Ты сказал, что, ну, получается, работаешь и с React, и с Vue. Можешь вот рассказать в принципе про разницы, которые ты видишь между этими инструментами, но именно больше технически, да, какие есть нюансы во время разработки? Вот что лучше, про какие-то именно юзкейсы, да, какие-то которые хотел бы это выделить.

На самом деле, здесь, по большому счёту, там 90% мне кажется типичных кейсов решается и там, и там прекрасно. То есть нет каких-то сложностей. Получается, когда мы начинаем углубляться в частные случаи, там какие-то оптимизации, виртуальный списки или что-то ещё в этом роде, за счёт более богатой экосистемы на Реакте можно подобрать библиотечку, можно подобрать там готовое какое-то решение, красиво сделать. А вот с Vue у меня пару раз были проблемы в этом ключе, что не удавалось подобрать библиотеку виртуализации. Приходилось либо вообще, скажем так, отказываться от того решения, которое было запланировано изначально, ну, по дизайну, там, по задумке перехода, и что-то по-другому как-то решать вопрос, либо смириться с тем, что там вот не несколько библиотек тоже подбирал, скажем так, работали, но частично с багами. Естественно, это частный пакет какого-то там обычного частного разработчика. И даже несмотря на то, что там issue какое-то ему оставили, то есть не факт, что он там быстро поправит, тоже как бы надо понимать. Вот. И в этом ключе чуть-чуть вот, в Vue, на самом деле, проигрывает по экосистеме, по инструментам, по доступным каким-то решениям прямо готовым, что ты берёшь, интегрируешь и всё. То есть это как бы такое вот прямо на поверхности различия, которое здесь лежит. Потом то, что с этого года сначала я вот пишу на React, как бы слышал многое, что многие ругают JSX, ну, то есть его вот этот вот синтаксис.

Хотя в целом, на самом деле, по своим ощущениям, я скажу, что мне понравился вот этот JSX и его возможности. К сожалению, во Vue приходится немножко это писать по-другому. Я не скажу, что это невозможно написать, но это чуть-чуть пишется по-другому. Опять же, за счёт того, что там используются директивы и так далее, но в целом как бы задача решается на самом деле. То есть, конечно, результат от этого не меняется.

И плюс, э-э, да, производительность Vue, ну, прямо из коробки, если говорить, она всё-таки выше, чем у React. У React приходится много думать насчёт оптимизации. То есть вот я сейчас по ходу дела, когда делаем проект, не только там как написать код, как реализовать, но и плюс ещё надо подумать, не вызовет ли это дополнительную нагрузку на перерендер там компонентов или одного или всего дерева и так далее. То есть тут уже как бы вот такая больше техническая глубина должна проявляться. Понятно, что разработчики, кто с опытом, это уже как бы в курсе, знают, где что надо использовать. Вот в переходе на Vue эта задача как бы решается, то есть сама собой, потому что, ну, Vue он, в принципе, даже и как реактив...

наблюдается либо упадок поддержки со стораним это, потому что мы видели deprated ряд ресурсов, точнее пакетов которые достаточно часто были использованы ранее. И это вот вызвало даже панику среди разработчиков, среди коммьюнити, почему всё же было принято такое решение вот сделать deпрокейд и

вообще обновление девятнадцатой версии достаточно медленно шло. Вот многие ожидали более быстро насчёт компайлера того же, который, ну, должно было заменять всякие вот использование колбэков, всякие вот хуки, которые для оптимизации, но при этом мы в конечном итоге получили такой результат, что это

не то, что мы ожидали так долго, да, это пока что вот так себе работает. Конечно здесь нужно подчеркнуть, что не всегда вот поддержка со стороны крупных компаний - это вот о'кей, бум, всё там всё о'кей, работаем, да потому, что, и, для, вю,, да,, получается, у

нас есть, получается спонсоры, которые поддерживают партнёры и поддерживают вэкосистему. Это достаточно круто, да по с этой стороны тоже мы можем думать да,, здесь,, кстати,, дополню., Отчасти,, мне кажется, даже то, что спонсоры какие-то есть, они поддерживают развитие фреймворка, то возможно они являются как

бы людьми, к которым прислушивается то что делает команда VW и что хочет сообщество. И она, то есть, внедряет уже какие-то дополнительные вот эти фишки или функциональность новую внедряет. То есть последние там патчи, насколько я помню, сейчас с 3,2 там до 3,4, там, в

принципе, существенный не такой функционал добавился. Вот Vmмоel хорошо там развили. То есть можно делать сразу несколько этих вешать директив на там на один компонент. Ну я думаю, что мы ещё поговорим об этом.

Угу., Да. Вот, даже, вот, просто, такой, как, бы, пример из того, что прямо сейчас вспомнил.

Супер., Спасибо., Ты, сказал,, что,, ну, получается, работаешь и с реактом, и со View. можешь вот рассказать в принципе про разницы, которые ты видишь между этими инструментами, но именно больше технически, да, какие есть нюансы во время разработки? Вот что лучше про

какие-то именно юзкейсы, да, какие-то которые хотел бы это выделить. На, самом, деле, здесь,, по, большому, счёту там 90%, мне кажется, типичных кейсов решается и там, и там прекрасно. То есть нет каких-то сложностей. Получается когда мы начинаем углубляться в частные

случаи, там какие-то оптимизации виртуальный списки или что-то ещё в этом роде, за счёт более богатой экосистемы на Реакте можно подобрать библиотечку можно подобрать там готовое какое-то решение, красиво сделать. А вот с Ю у меня пару раз были проблемы в этом

ключе, что не удавалось подобрать библиотеку виртуализации. приходилось либо вообще, скажем так, отказываться от того решения, которое было запланировано изначально, ну, по дизайну, там, по задумке перехода и что-то по-другому как-то решатьт вопрос, либо смириться с тем, что там вот не несколько библиотек

тоже подбирал, скажем так, работали, но частично с багами. Естественно, это частный пакет какого-то там обычного частного разработчика. И даже несмотря на то, что там ишью какое-то ему оставили, то есть не факт, что он там быстро поправит, тоже как бы надо

понимать. Вот. И в этом ключе чуть-чуть вот, в VIIW, на, самом, деле, проигрывает, по вот экосистеме, по инструментам, по доступным каким-то решениям прямо готовым, что ты берёшь, интегрируешь и всё. То есть это как бы такое вот прямо на поверхности различия, которое здесь

лежит. Потом то, что с этого года сначала я вот пишу на реакте, как бы слышал многое, что многие ругают GSX ну, то есть его вот этот вот синтаксис.

Хотя в целом, на самом деле, по своим ощущениям, я скажу, что мне понравился вот этот JSX и его возможности. К сожалению, во приходится немножко это писать по-другому. Я не скажу, что это невозможно написать, но это чуть-чуть пишется по-другому. Опять же, за счёт

того, что там используются директивы и так далее, но в целом как бы задача решается на самом деле. То есть конечно, результат от этого не меняется.

И плюс, э-э, да, производительность VW ну, прямо из коробки, если говорить, она всё-таки она выше, чем у Реactта. У Реакта приходится много думать насчёт оптимизации. То есть вот я сейчас по ходу дела, когда делаем проект, не только там как написать код, как

реализовать, но и плюс ещё надо подумать, не вызовет ли это дополнительную нагрузку на перерендер там компонентов или одного или всего дерева и так далее. То есть тут уже как бы вот такая больше техническая глубина должна проявляться. Понятно, что

разработчики, кто с опытом, это уже как бы в курсе, знают, где что надо использовать. Вот в переходе на View эта задача как бы решается, то есть сама собой, потому что, ну, VW он, в принципе, даже и как реактивный

фреймворк считается, он снимает, ну, с разработчика вот многие вот такие вещи что не нужно думать там про оптимизации но это только в каких-то там уже, ну действительно сложных кейсах. Плюс детуol, который есть, нам наглядно может показать, где у нас просадка, и там уже

подумать над оптимизацией нужно будет. Тоже, в, этом, контексте, очень, считаю,, удобно. Хорошо., Спасибо., О'кей., Я,, в, принципе, понял, ты про что вот сказал вот в принципе JSX, темплейты и всякие, но давай поочерёдно. Вот можешь рассказать как ты понимаешь понятие separation of

consoers или разделение обязанностей да? Вот как именно? Ну когда мы рассказываем про View и React терминология достаточно часто используется. Когда у нас есть View, да у него более всё аккуратно идёт, да, мы часто не видим даже там, не знаю, всякие

модульные стили файлов, да, всякие разделения и так далее. Часто у нас есть, получается, чётко есть структура темплейта, есть скрипт, да, есть тели в одном файле. Чётко этой обязанности как таково разделены. А в Реакте мы видим чуть другую ситуацию. И там чуть с этой

стороны сложнее. Вот что можешь сказать про про этот дизайн механизм, да который используется ну,, это,, в, принципе,, не, касается какой-то конкретной технологии, просто реализация, этой, дизайн-механизма, в, V в, и в Реакте чётко отличаются. Здесь, в принципе, можно сказать то, что

поскольку VWфйвоwor и, кстати говоря вот почему многие-то, допустим, любят фреймворки он уже немножко какие-то правила тебе задаёт, как надо писать, как не надо писать. То есть, да, если, допустим взять option API, там вот есть дата раздел, сюда клади там какие-то данные

есть там раздел методы, сюда клади там методы и так далее. Реакты, да поскольку библиотека, ты можешь свободно писать, как хочешь. Но тут получается сложность в чём-то, что когда разработчик в контексте Реакта работает он принимает либо паттерн команды и

соответственно, там, если они решили что будет использовать там, как допустим, scSS модульный, то они придерживаются этого паттерна. У них там будет файлик описывающий компонент, там отдельно лежать, там файлик стиле и так далее. Либо, может быть, они что-то другое там, не знаю, что ещё сейчас

модно. CSS NGS или ещё они типа, style, components, использовали. Дада., Да,, что-то, такое, вот, как, бы, View тоже здесь прощает и на самом деле тоже предлагает уже сразу из коробки. Ну вот если ты компонент этот пишешь, будь добр, там пиши в секциите саму вёрстку

как он будет скелет компонента. Секция стиля описывает, как этот скелет будет выглядеть. Ну и секция скрипта здесь в контексте разделения говорит о том, что вот, э-э, тут всё касае касаемо логики компонента содержится, там какие-то расчёты, там, может быть, ещё что-то. И

мне кажется, что вот именно как раз этот подход более удобен для разработчика потому что ты не бегаешь по куче разных файлов, чисто открыл, у тебя всё есть всё на ладони, ты там работаешь с разделом с одним, посмотрел его с

другим, ну, и так далее. Хотя здесь же есть и минус, конечно, то, что если комбаент большой и там много-много строк кода, приходится его как-то либо декомпозировать, чтобы это было более читаемо. То есть здесь тоже такой момент присутствует, мне кажется.

Пока, говорим, про, обязанности,, вот, хотел слушать, это достаточно так интересный вопрос. Настоящее время среди форумов да, там коммьюнити обсуждает. Что ты думаешь насчёт пользования FСД, да вообще? Какое у тебя мнение про вот эту архитектуру? И какие минусы, да, есть у

этого подхода вообще? Или, может, ты, не знаю, использовал достаточно часто, как такова не можешь разделить этого подхода?

Да,, вопрос, я,, в, принципе,, понял., Здесь больше такой проектный, наверное архитектурный, да, подход. Мне кажется придумали люди, которые работают с Реактом и не знают, как размещать компоненты и куда складывать файлики.

Условно понятно, что структура проекта у нас не отражает архитектуру. Это просто ну, скажем так, принцип хранения файлов в той или иной папке. FSD получается,, я, смотрел,, ну,, когда, вот только-только там что-то зарелизили первую версию на комьюнити, где ещё

было, по-моему, семь слоёв там был слой провайдеров. Точно. Потом его убрали, сейчас, по-моему, его нет.

Что ещё там было? Ну, все остальные вроде слои там остались. Вот я, в принципе, использовал, но где-то, может быть, этот подход будет хорошим с точки зрения, если команда вообще не применяет никакой там архитектурный, скажем так подход свой и структурирование никакое

не применяет. Это хотя бы наведёт какой-то порядок в проекте. То есть если так говорить, и лучше бы хотя бы даже если они вообще ничего не применяют, применяли бы FSD. С другой стороны, я опять же видел мм ну в разных

командах то, что если уже есть в команде какой-то принцип размещения файлов по папкам и какое-то взаимодействие на архитектурном уровне между компонентами то уже есть какой-то внутренний гайд команды, который разработчик может полистать, почитать и, в принципе просто начать применять. Поэтому, да

вот если кратко, то если ничего, никакую структуру не применяете, никакую там архитектуру не проектируете, то хотя бы возьмите ФSD. В целом его можно также и на вW использовать, за исключением того что если в реакте там будут какие-то файлики со стилями дополнительные, может

там ещё что-то лежать, то во просто будет, ну, грубо говоря, одиночные компоненты точка View и где уже описаны все внутренности этого компонента. Ну, в целом наверное так.

Почему, спрашивал,, потому, что, Да,, супер, спасибо. Почему спрашивал? Потому что вот, например, в одном из докладов Яндекса там был рассказ именно про FСД.

И получается человек, который преставил информацию про ФСД, говорит, не знаю там где-то там у нас не хватило директории, мы создали там, в общем, мы сделали интеграцию так, как нам нужно.

Ну, это, конечно, создаёт хаос, потому что если будет поддержка со стороны других разработчиков того же проекта да, здесь у нас так себе ситуация создаётся, да, получается. Тогда от компании нужно или вот команды разработчиков нужно будет создать до строгий документ проекту, да, не знаю

мы добавили новую, ну, типа разделение директорий, если на уровне этого сказать, мы добавили, знаете, вот новый слой или новую директорию. Это отвечает за это. Но при этом здесь такой нюанс что FSD как такова не покрывает, да, все нюансы, все вопросы. Я думаю, что как

таково ещё развить этот механизм, чтобы можно было использовать и для более таких больших проектов. А, отлично. И вот насчёт интересных вопросов провю есть такой, ну, механизм, который называется реактивность, да?

Реактивность - это у нас и, ну, в реакте как такова тоже есть по другому механизму реализовано, да, там свои подходы по стейту. А в review у нас как бы тоже обновление состояния. Мы и называем реактивностью, да, реактивность как работает. можешь рассказать

пожалуйста, вот про эти нюансы во второй версии, во третьей версии и почему всё же решили поменять механизм, да, как бы ну,, вообще, реактивность, тут, я, бы, не сказал, что прям это относится к вью.

Просто он на концепции реактивности на самом деле основывается. Вообще реактивность - это, если говорить технически, то тогда, когда меняется какая-то переменная, другая, которая зависит от изменённой, автоматически также пересчитывается. Вторая версия VIIE была сделана на гетрах сетерах насколько я помню. Там вроде бы на лету

нельзя было какие-то свойства добавлять когда прокси, которые, ну, на которые перешли уже в третьей версии, позволяли на лету добавлять какие-то новые свойства объектам. Ну, объект, в принципе, который представляет себе описание внутренней структуры, там ноды и или компонента. Ну, кто как тут, кому

как удобней. Получается, за счёт тех же проксей, в принципе, удалось достигнуть большую производительность самого фреймворка, то есть он стал быстрее.

Плюс ещё добавили типизацию, ну, что тоже, мне кажется, сыграло тут плюсом. Вот. Раньше прямо в нутрянку второй версии я не залазил, не смотрел. В третьей версии немножко побольше покопался и нашёл тоже такие интересные детали, что стали использовать бинарные

маски в некоторых случаях. Ну, то есть и понятно, бинарные маски, ой, бинарные операторы, ну, я имею в виду эти которые, кстати, мало фронттенчики используют, они работает достаточно быстро, и за счёт этого можно тоже увеличить производительность каких-то решений.

Хорошо,, спасибо., Вот, ты, сказал, насчёт кетерсетеров второй версии. Вот такой вопрос. Например, у нас есть массив, да вот, ну, это именно касается апдейту на лету, да, у нас есть массив из пяти элементов и есть желание обновить третий элемент конкретно. На третьей версии у

нас получается сделать достаточно быстро по индексу обновить и всё реагирует. Да у нас VW. Но наву второй версии напрямую обновление по индексу не работает.

Можешь объяснить, почему это так? вторая версия, потому что ориентируется на ссылки и по сути массив-то остался тот же, то есть для него как будто бы в памяти, ну, ничего не поменялось. Ссылка осталась на массив той же самой, и

поэтому он считает, что изменений-то и не произошло. Там, по-моему, даже в документации указано, что, ребят используйте тогда глобальный view.set метод чтобы, ну, заставить View обновить, Value.

А, ты, рассказал, про, прокси?, Вот., Чус. Давай поговорим про вот этот замечательный объект в Джесе, да вообще, когда он появилсь и для чего используется. Про рефлект API, например если сможешь рассказать.

Про, стандарт, не, помню, вот, в, каком стандарте, ну, относительно, скажем так недавние стандарты, но прокси позволяет сслеживать какой-то объект, точнее, ну в смысле, свойства объекта может позволять какие-то операции совершать над этими свойствами. Ну, не знаю, там можно какой-то логер сделать, можно ещё

что-то, то есть там можно какую-то функцию дополнительную вызвать. То есть там, насколько я помню, есть метод который устанавливает, ну это свойство сет по-моему.

Ну, да,, сетегетеры,, в, принципе,, там механизмы, да,, они, как, бы, остаются., Да-дада., Вот., И получается, что в зависимости от случая мы можем что-то сделать. Мы можем вообще даже через прокси, через функцию set да, переопределить значение. То есть если у нас там мы хотим пять, а напишем

код, вместо него будет статично 10 там условно возвращать. То есть тоже такие вещи можно делать.

Ну,, рефлект, API,, да,, называется, именно группа методов, которая вот именно используется рядом с прокси, например вот для реализации подобных отслежек.

Вот тоже появилось рядом с вот прокси. Отлично. можешь, пожалуйста, рассказать про Virtal Дом, про своё видение, про этот подход и почему всё же, по-твоему да, почему всё же ВИ решил использовать именно этот подход, а не что-то, не знаю, по другим путём идти?

А, здесь,, кстати,, этот, вопрос, хороший., Я не прямо там сильно сразу скажу, что погружался, почему там они решили Virtal Dom использовать. Ну, какая история или предыстория на этот счёт была. Вот. Но в целом, э, Virтуal DOM по сути - это

механизм, когда вот V вместо настоящего дома просто хранит, ну, вот это дерево описанное в виде объектов, какие у него там есть свойства, что он должен рендерить, какой там див и так далее. И он смотрит вот эти вот все свойства

которые есть внутри каждого узла. Частично, если у этого узла меняются какие-то данные, либо методы, либо там свойства, либо value там какое-то. для того, чтобы не всё дерево перерисовывать, он старается это оптимизированно заменить вот эту ноду.

То есть как бы не трогая остальные. Ну а дальше уже по сути процесс там происходит, что всё это вирту виртуальное дерево отрисовывается в дом в дом дерева, которое видим.

А, более, подробно, вот, про, какие-то интересные детали можешь рассказать про именно Virtal Dom? Да, и вот рассказал в целом, да, как работает, но более детально, да, как таковол дом, который мы говорим, у нас есть оригинальный дом.

И у них происходит определённый мёрдю да, но на стороне виртул дома у нас не всё так просто, как если вот так абстрактно смотреть.

Достаточно часто разработчики путают что там просто вот один экземпляр, да там, не знаю, создаётся копия и всё, там получается происходят какие-то операции.

На самом деле вот если знаешь, да, как бы и про Virтуal Дом именно более подробно, как работает, а что происходит на стране именно Virtal Дома, если оригинально оставить в покое? Да, вот дом, если оставить в покое, именно сам

процесс тех сравнений на уровне. А,, ну, ты, имеешь, в, виду,, что, мы, можем просто получить рассинхронизацию того что мы видим в реальности и того, что в действительности внутри фреймворка, ну то есть внутри памяти Virтуal Dom хранится. Ну, то есть да, это вот

мутирование, допустим, про псов. Вот здесь вот тоже по такой причине иногда бывает, что они же доступны только для чтение. И разработчики бывает, ну напрямую изменяют этот пропс, не отдавая через имит события. То есть получается что как будто бы внутри дочернего

компонента вот этот вот пропс изменился. Ну, то есть его смутировали, а у родителя он остался-то неизменённый. И в итоге мы вот получаем как раз проблему когда у нас визуальность расходится с тем, что не совпадает virртуал дом. Ну и

там, по-моему, вьюшка кидает warрning на этот счёт, типа посмотри и обрати внимание. Конечно, вроде бы как ничего такого критичного нету, но с другой стороны, когда важна точность, точность данных, то мы можем, ну, её простонапросто потерять.

Угу., О'кей., Хорошо,, спасибо., Ну, вот. Может быть, может быть, про это имелось в виду или нет?

А,, ну, давай, вот, чучуть, другой, вопрос обсудим и вернёмся к этому. Вот насчёт алгоритмов можешь рассказать. Ну, как бы это достаточно частый вопрос. Вот именно как понимаешь понятие сложности алгоритма? Вот бигу, если взять именно по количеству мм,, по, количеству, операций,, то, есть,, ну,

грубо говоря, это время, за которое, ну алгоритм у нас пройдёт от начала и до конца. Ну, если вот так, ну естественно,, если, у, нас, будет, два вложенных цикла, ну, вложенный цикл друг друга, то у нас как бы во второй степени

увеличивается сложность алгоритма, и это, ну, на самом деле, просто увеличивает время расчёта всех операций пока циклы не закончатся.

Хорошо., Вот, почему, я, задал, этот, вопрос. Есть доклад такой про вот это про React касается, но рассказывает про Virtal Dom, про эффективность работы Виртуал дома со сравнением вот именно с домом. И там рассказывается, что даёт эффективность в, ну, в размере куба, да

получается, если у нас в ну если, не знаю, доме у нас там происходит 10.000 ираций, чтобы там, ну, получить тот же результат, там снижается это в корень куба, да? вот столько снижается количество операций. Это достаточно такой частый вопрос про именно

эффективность, если мы сравниваем дом и virтуal дом. И я не просто так задал вопрос именно про алгоритмы. А что касается сложности алгоритма, здесь мы оцениваем же его, ну, по количеству, по таймингу, по мемоor, который используется, да, в процессе решения

алгоритма. Вот. И для этого здесь есть разные факторы по этой части в целом. Virtual Dom. Да, я вот что хотел слышать ещё, что Virtual Dom - это не только одна копия, да, вообще дома. Там на самом деле несколько

ну, там получается внутри виртуал дома процесс сам более тяжёлый, чем вот именно процесс мёрдинга основного дома с виртуал домом. Ну, как такова финальная версия виртуал дома. А внутри уже виртуал дома у нас есть другие процессы которые уже мы получаем финальную версию

вот дома. Вот на стороне React IV здесь достаточно колоссально они отличаются да, получается. Можешь, пожалуйста рассказать про React Reconculation и React Fiber, которые вот по разным вот стадиям развития Реакта появились, да?

React reconcilation сперва и дальше у нас пришёл React Fiber, как такова, не знаю, в ковечках заменитель механизм которые Да,, я, что-то, слышал, там, вот,, ну, эти, скажем так, понятия, но прям глубоко тоже что-то всё не хватало времени прямо

почитать и поразбираться. Если я правильно помню, там раньше, по-моему когда нода уничтожалась в реакте, то есть считалось, что как будто бы все дочерние ноды, ну, от дерева, если смотреть, просто будут заново как бы собираться. По-моему, Вью вот как раз

решает этот вопрос тем, что он всё-таки всё дерево там, ну, не обходит, не строит. он сравнивает какой-то конкретный компонент, и он, э, на самом деле создаёт под капотом этот определённый идентификатор, по которому ну, но нода сравнивается с тем, что как

бы в ней изменилось и нет, и уже получается как бы происходит вот этот мёрш процесс. Ну, что-то вот такое рядом, но, честно говоря, что-то это сейчас может сразу-то и не вспомню да., О'кей., Это,, в, принципе,, интересный вопрос вот про реактостему. Получается

Колещин у нас появилась сперва, да долгое время поддерживалась и вообще представляет обе представляет механизмы именно обновления вот дома и как вообще обновляет React дом. Но при этом здесь Fiber появилось, чтобы решить ряд ограничений, которое был было у Реакри

Конколена. Ну, например, React Concation, он не умел асинхронно работать, да, параллельно решать какие-то вот части вот дома, а он взял цели, не знаю, Virt дома и сделали это сравнение. И вот это достаточно тяжело работало тогда, да. У нас, когда

до сих пор мы рассказываем про Virтуal Dom, мы до сих пор остановимся про именно этот подход, да, реакции Конколена. Вот появилось Fiber, он, в принципе, взял тот те же подходы которые есть у этого реконлейшна, но при этом добавил все свои фишки, да.

Например, есть такая фишка, как, да который там, не знаю, ты несколько раз обновляешь стейт, но он берёт только один, да, из обучается Fiber именно представлял эту возможность, чтобы и вот реализовать этот подход. Ещё Fiber, если я верно помню, добавил такой подход, как

конкуренции рендерин. Да, он по выдал полный контроль над кадрами страницы, и в общем, можно было более оптимально вот это все проблемы решить с контролем кадров. Там был рассказ про Request Animation Frame, как он всё это дело там контролирует и работает. И получается у

нас Reconcilation и Fiber - это, в принципе, для одной и той же задачи, но Fiber он более профессиональный, бо у него более серьёзные механизмы для реализации, да, как бы и для из-за этого именно Fiber используется. Там не но как

такова основой являются, да, реализации а являются так называемые файберы. файбер именно вот, ну, ты сказал про но да, в recнation, а здесь они называются файбера именно. Вот такая терминология получается. Это один из однст вопросов про реакт экосистему, да, если вот

сказать и вообще очень разные вопросы затрогивает, да. Вот. Но можешь теперь поговорить про ВW, можешь рассказать про Вюмен, как он может, какие фишки он может добавил от себя, потому что есть алгоритмы, которые вё от себя всё же добавил для реализации того же подхода.

Хороший, вопрос,, но, если, прямо, в, детали смотреть, то в детали вот как это прямо вот детально детально детально это вью сделал, я не вдавался. Да, что-то было там в каких-то обновлениях, по-моему что они переписали вообще механизм вот этого рендеринга.

Угу. Вот, сейчас, даже, не, помню, в, какой-то версии. Или 3.2, или 3.1, что ли, что что-то. Ну, не ну,, в, принципе,, можем, обобщить,, да, третья, не, совсем, свежая,, да,, но, это, точно, по-моему, было в третьей версии. Прямо заморочились на этот счёт. И вот что-то

как-то этот момент и Ну,, там, я, делаю, подсказку,, называется типа блок три. Optimizйer, точнее оптимайer, ну,, ну,, механизм,, который, сделал оптимизацию именно вот для виртуал дома.

Ну, получается, который они сделали вот ну, переписали, именно так и называется. Получается, вот про это хотел слышать что VIW, в принципе, да, взял подход Virtл дома, но не так, что они взяли из коробки и так и использовали, они все

свои фишки, ну, свои фишки добавили и Vю, а, имеет своё так внедрение в механизм виртуал дома тоже, да, как бы с этой стороны тоже стоит это подчеркнуть потому что вот всё же интересные подходы, которые вот выигрывает и по

оптимизации, по всему другому, по всем остальным процессам. В принципе, мы про много чего-то рассказали, вот поговорили про вот Вюэкосистему. И сейчас вот хотелось прослушать вот про Dependency Injection. Слышал, да, ты про этот подход?

Да,, он, в, принципе, такой, популярный, в Несте, ну вже агуля,, да,, как, бы, это, взя.

Ну, дада,, в, Ангуляре, тоже, есть, такая история. Ну, а как в AVI тоже используется, да, как бы у нас провайжек типа.

А, вообще,, если, так, посмотреть,, то, да,, по сути, прой некоторая такая аналогия Dependency Injection да,, ну, что, терминология, было, изменено, но в конечном итоге, но мы получаем тот же подход, реализованный уже во в экосистеме, да, получается, в принципе

мы видим тот же самый ну, или, этот,, как, он, там,, React, Contтек, это вот тоже аналогия. Хотя почему-то кто-то говорит, что пройкт - это не реакт контекст. Ну не знаю, как по мне концепция та же самая да., Ну,, в, принципе,, да,, я, тоже, согласен

с этим, потому что как такова Dependcy Injection, он представляет возможность поделиться данными между разными модулями. И это вот достаточно хитро происходит, да, получается. И механизм точно по слоям это напоминает и повторяет точнее. Отлично. Вот провёл.

Мы, в принципе, поговорили про основные концепции, про вот обязанности слоёв и так далее. Про физда успели чуть-чуть поговорить. Вот давай. Ну да, в принципе, да, совсем чуть-чуть. Вот сейчас вот хочу такой вопрос затронуть.

Ты можешь сказать твоё мнение насчёт использования модульных стилей в VIW-приложении. Достаточно часто видно что там в приложениях, кроме этот основного механизма стиля, который в view файлах есть, используются ещё модульные стили, да, типа, например, с поддержкой процессора какого-то. Как ты

это вообще вот считаешь, это нормальный подход с VI приложениями или всё же не стоит так сделать? Слушай, я тут у меня единого мнения на этот счёт нету, на самом деле, потому что ну,, просто, вот, как, как, твоя, практика,

ну, твоя практика показывает, да, в проектах достаточно часто это видно когда, не знаю, там, а, используются стили в разных компонентах, напоминает подход реакта, но при этом здесь мы и вроде в впроекте, да, можно было всё организовать в одном файле. Как ты

думаешь, когда это вот в принципе можно считать о'кей, да ладно, пусть так оставим. Вообще, модульность, хорошая, такая история, когда действительно приложение клиентское какое-то большое, там много да, разных каких-то компонентов. И бывает так, что, не знаю, с точки зрения

какой-то логики, наверное, компоненты вроде бы по-одинаковому называются, но чуть-чуть там как-то там они вообще по-другому работают или там совсем по-другому. выглядят там какие-нибудь карточки, например, типичные. И может быть ещё модульный подход удобен для тех, кто микрофронтенды делает например, потому что

таким образом в модуле запираясь или для какого-то конкретного компонента, мы, по сути, не будем разрушать стили другого ну, аналогичного с таким же там классом.

И тем самым проще поддерживать или даже не сделать, скажем так, пакости другой команде, например, или другим разработчикам. Здесь такой, наверное больше вопрос разделение ответственности как будто бы возникает. Опять же, тут есть такой минус, на самом деле, вот, на

мой взгляд, из того, что когда много типичных классов, ну, прямо вот они подходят там, ну, а одно правило там отличается, ну, может быть, два максимум, да, на этапе вот рефакторинга по факту, когда уже плюс-минус приложение какое-то усто устояло с точки

зрения функционала и дизайна, можно это конечно, вынести всё в одни и те же стили. Ну, то есть, чтобы они были общие. Это снизит, на самом деле, в итоге вес бандла, вес приложения. Ну грубо, говоря,, по, большому, счёту,, общие

стили подключат сразу там где-то везде а часть, ну да, будет отличаться. Либо же это просто в каждом компоненте свои куски этих стилей. И в конечном счёте это по сути как бы два раза мы написали ну там продублировали строчки, а каждая

строчка у нас ээ сколько-тодасит, как бы модульность. Сейчас я вот лично сам на модульности мы редко пишем. Ну так иногда как бы пишем. Просто за счёт того, что мы взяли Tailwin CSS и начали его использовать. В принципе, он даёт

единый стиль. Там разово можно настроить в нём тему, и у тебя, по сути, главное помнить, какие классы ты хочешь. Вот навешал эти классы, да, и как бы используешь один раз. Э, ну и любители просто глобальных стилей тоже есть, но

насколько я знаю, стараются люди придерживаться там какому-то правилу. Вот Яндекс, например, написал написал методологию свою БМ тоже как бы использует. Ну, здесь, мне кажется просто по большому счёту, кому как удобней. Ну, если прямо совсем быстро что-то надо, почему бы Aйil там

какой-нибудь не взять? Стили готовые там уже всё раскидано, то есть просто берёшь и используешь. Но с другой стороны, это такая колбаса из строчки из длинной строчки разных стилей, когда там не просто флекс, там флекс колы или что-то ещё, а когда там транзишены, там

что-то БГ, плюс разные варианты отображения на разных устройствах, плюс ещё, может быть, там какая-то тема, а может быть и не одна, и там начинается там вот это вот чисто писание параграфических строк стилей на четыре-пять, э, строчек, скажем так. Ну

ну, там, чуть, applyй, спасает,, да, ситуацию, когда Apply используется. Да,, Appлай, тоже, спасает, да,, как, бы, тоже, можно, таким, путём, пойти.

Поэтому здесь чаще я, скажем так принимал опыт команды, которая взяла в проект. То есть, если они там решили модульные стили, то о'кей, для меня как бы не проблема. Делаем модульные. Если мы там решили общими стилями, о'кей тоже делаем. Ну, по этому принципу

дальше. Если там TailWin, то тоже о'кей. То есть как бы у меня такого единого здесь мнения нету. Многие фыркаются.

Кому-то вот одно подавай, кому-то другое. Но мне кажется, тут, если ты вообще технический специалист и используешь в своей работе какой-то инструмент, то, мне кажется, тебе неважно, какой он. Главное, просто, ну сомневаешься, вот спроси у команды всегда есть к кому обратиться. Ну, если

ты там не один подпроект пилишь. Вот так. А супер., Спасибо, большое., И,, наверное, последний вопрос. Это касается, в принципе, вообще вот фронтенду. А что ты думаешь вообще про микрофронтенды?

Вообще, как они показывают и когда вот стоит использовать действительно? Ну да микрофронды рекомендуют здесь, когда несколько команд работает, грубо говоря над одним приложением, но внутри него есть разделение ответственности. Там одна команда пишет, там, например, не знаю, ну, возьмём уж совсем просто там

сайдбар меню, отвечает там за какой-то лейут и ещё что-то. Другая команда этим не занимается. Она там занимается там раздел, конкретным каким-то разделом на сайте. И чтобы не мешать друг другу, по сути, вот эти микрофронтенды разделяют разделяют зону ответственности, да. Вот.

Ну и по сути каждая команда может работать независимо, не мешая другой. Причём нам, кстати, здесь не всегда важно. Одна команда может пилить на одном фреймворке, другая на другом, там третья на третьем. То есть и как будто бы получается некий осьминок из разных

фреймворков на одной странице. Но разрабочики никогда, мне кажется, не ищут лёгких путей в этом ключе. И мы будем исключением. Но на самом деле я вот сколько что-то так не смотрел немножко так почитывал, почитывал и что-то у многих тоже вот не знаю нам как

вот интегрировать фреймворк в другой или когда обёртка одного фреймворка. Короче бывает проблема. Вот у нас точно, мы недавно сервис делали, что у нас использовался ангуляр, короче, внутри микрофронтенда и получается обёрка тоже на ангуляре. И там типа браузер не

понимал, какую версию взять Ангуляра, а у нас там разные версии были, и он почему-то брал только одну. Возникал конфликт, что в более новой версии нет короче, ну там какой-то момент, короче изменился и получается ломалась вёрстка.

Ну там типа что-то приложение не работало. У нас архитектор ушёл решатьт вопрос. Э, что-то он победить, насколько я понял, напрямую не смог. Он там каким-то хаком, короче, заставил думать браузер, что это типа разные версии, там что-то внеся какие-то корректировки там

в текстовый файлик, ну уже в бандл, и только тогда как бы заработало. Ну, это частая какая-то история. Я прямо вот тоже слышал, мы обсуждали, в общем-то такое решение. Но так вот, если смотреть в моём понимании micрофронд, не знаю

это вот конкретно просто какой-то скелет страницы там с разными дивами и куда в каждый див встроивается какой-то свой фреймворк там или, ну, руль приложение какое-то. Вот это, по-моему, вообще самый самый простой вариант, когда не надо там что-то там что-то париться с

какими-то сборщиками, вепаками и прочее. Ну, потому что вот есть конкретно размеченный блок, туда интегрирует, там хочешь View, хочешь Solid, хочешь там swell, неважно, сюда тоже есть, но по-моему, вот можно даже разрулить на уровне сервера, чтобы сразу рендерингом отдавалась страница, то есть как бы, ну

чтобы как бы SEO поддерживалось, но в целом может быть проще сразу написать страницу на, ну, как бы отрендеренную на сервере и отдать клиенту и как бы не париться. Ну, то есть, не знаю, как-то не прижились у меня, короче

микрофронтенды, на самом деле, в практике. То есть, знаешь, кто-то использует, но вот у меня что-то они не очень прижались. Я ещё покатически так к ним отношусь и немножко так как бы пока даже их не затрагивал этот вот аспект.

Ну, кому-то нравится. То есть опять же личное предпочтение, кому как удобней. Угу., Хорошо,, спасибо, большое., И, наверное, всё. Я также скажу своё мнение про Вё, так как по большому вот, да Евгений, ты рассказывал про вот вю и все

вот вопросы ответил. Спасибо большое тебе за время. А провёл вот в целом скажу, что лично мне нравится достаточно строгий механизм разделения обязанностей, да, и даже в рамках одного вот вью-файла, когда открываешь, уже чётко понятно, где что лежит. Именно

Евгений тоже подчеркнул, что насчёт, не знаю, там дета, то там лежат какие-то вот переменные, всякие значения, которые вот можно вот связывать с реактивностью и так далее. Вот получается у нас во вью более это всё понятно, более семантично выглядит со стороны вот поддержки кода

чем, например, в реакте, потому что в Реакт у нас состояние, например, ну даже долгое время мы объясняем, что вот не знаю, хукинь нужно держать вот между пропсом, да, когда мы делаем деструктуризацию пропсов и, не знаю методов, которые идут ниже, не делать

нарушение этой семантики кода. И Вю это сделать даже не нужно, потому что Vю насколько бы ты хотел, всё равно этого разделения как бы уже есть. И это более сложно, да, сделать в определённые нарушения по коду, а, по семантике. И

э, вёл про это достаточно вот хорошо думал и про вот реализацию этой всей логики. Ещё есть разные выборы, да, там options API, composition API, которые добавляет достаточно хорошую абстракцию для кода. И, э, мне нравится такой подход, что у нас вот для как

конкретного приложения один или другой подход может быть хорошим выбором, да. И в реакте, например, если вот сделать какое-то вот сравнение, например, есть классовые компоненты, есть функциональные компоненты, но там здесь вот ситуация чуть сложная, да, почему-то классовые компоненты вот, ну

по-большому сейчас считаются уже устаревшими, да, там используется там достаточно редко, например, для error паounder и так далее. А вW, в принципе команда не сказала, знаешь, там options API - это вообще не то, не нужно использовать, а вот возьмите вот только

composition API. Типа не произошло такое, что ты прокей, всё не нужно использовать. А это мне нравится, что команда как бы имеет определённые подходы. Он не говорит, знаешь, этокейт всё, удаляем или убираем и так далее.

говорит, ну, на он равномерно поддерживает всю экосистему и всё использует, да, все используют Options API и так далее. Также из хороших новостей в что поддерживается хорошо Typeesриpt для вот любителей, ну точнее, не для любителей, а для больших приложений, это, наверное, лучший выбор

для реализации, потому что без его никак. Это, наверное, отдельная тема сегодня обсудить. Это более обширно тут рассказать про Typeescreт или обсудить вот нюансы его работы. Но это достаточно важный такой тоже плюс. Ещё вот например, именно механизмов Dependency Injection и таких вот дизайн-паттернов

присутствие подобных дизайн-паттернов больше, чем вот, например, в Реакте потому что в React уже нам нужно будет самому что-то реализовать. А в View вот использования дизайн паттернов каких-то шаблонов уже есть из капотов, да. из коробки. Это достаточно отлично. Вот получается

команда вот использует разные интересные подходы для поддержки своего инструмента. В целом мы сегодня обсудили, получается, и плюсы, и минусы технологии VIW. Без минусов никак. В любом технологии этих минусов есть и реакция, и вот, не знаю, вангуляри и так

далее. Но важно было вот обсудить, какие есть чётко вот минусы, чётко плюсы, а не вот, не знаю, сказать это вот, не знаю самая лучшая технология, нужно учить только него, не смотреть какие-то другие. Это достаточно важно субъективно всё вот обсудить и оценить. Спасибо

большое. Ев ещё, дополню., Кстати, говоря,, вот, я, прямо негодую после перехода на реакт немножко, ну, в связи с работой, да негодуют в том плане, что мне не хватает этих ээ слушателей событий компонента который есть во вью, но нету в реакте.

То есть когда я могу просто взять кастомно, прослушать событие какое-то компонента дочернего и выполнить какое-то действие в родителе. При этом в реакте, ну, такое можно сделать, но ты обязан прокидывать дополнительно функцию какую-то сверху и так далее, что как бы

не всегда, наверное, хочется. И вот этот как бы подход мне прям ну как бы нравится на самом деле. И ещё дополню по небольшим минусам в плане вюшки с типизацией. Есть небольшая такая проблемка типизации на уровне роутера ну, роутинга страниц, если мы роутер

настраиваем. И когда открываем этот API компонента дочернего, ну, для родителей чтобы он дёргал его функции. Это я сейчас про Define Expose. И вот здесь немножко такая как бы не очень типиза не очень типизация. И не знаю, будут ли они

решать, возможно, решат в будущих релизах. Э, очень надеюсь. Но иногда приходится вот танцы с бубном там, э, на тайпскрипте прописывать, чтобы хоть как-то как-то и был было пояснение, что можно вызвать такой такой или там другой метод.

Да,, кстати,, я, заметил, это, и, скажу,, что, в Гитхабе есть открытий тикет по этому поводу и думаю, что это в будущих версиях будет решено. Ну, как таково да, спасибо, что рассказал. Таких проблем есть ещё, да, как бы, кроме

этого. Но если вот так отдельно обсудить, наверное, вот Typeesриpt как таковая экосистема не поддерживается во всех технологиях на 100%, ну библиотеках и так всё. Имею в виду, что это в постоянном таком процессе развития новых фишек, новых каких-то поддержки абстракций, да, которая есть в

технологиях. И по этому поводу можно не переживать, потому что только какой-то отдельная деталь не означает, что View например, Typeescriptриpt - это fail да? Вот. Угу.

Это, кстати, касается компонентов которые на композишене написаны. В принципе, если на option описываешь компонент, они по умолчанию методы открыты. И, по-моему, даже Typeesрипt подсказывает, что есть, что типа можно его вызвать на самом деле.

Супер., Тогда, спасибо., Да, да,, надеюсь,, было, всем, полезно. Всё,, спасибо, всем., Всем, пока. Всем, пока.