Есть два типа команд: один тип — это команды с четкой специализацией каждого человека, раньше их было много, сейчас они, наверное, только в энтерпрайзе; второй тип — это команды из аджайл, разработчики из таких команд обычно фулл-стек, сейчас в веб деве пре-энтерпрайз таких большинство. Это один из принципов аджайл — взаимозаменяемость разработчиков, поэтому разрабам дают отдельные фичи делать "с низу до верху", от базы до верстки.
Посмотрим с другой стороны. "Специализация" в технологии часто означает то, что человек выучил что-то одно, и считает, что этого достаточно. Я знаю людей, которые за десять лет работы выучили как писать бизнес-логику на C# и MS SQL Server. Ни веба, ни десктопа, ни другой платформы они не знают. Являются ли они классными профи и убеленными сединами гуру? Нет, и более того, те люди довольно посредственные разработчики.
Большинство проектов не требуют глубинных знаний платформы. (И, кстати, шанс их получить у специалиста такой же, как и у фулл-стек разработчика. Платформа, которая требует постоянного вникания в свои тонкости, не выживает). Намного практически полезней для команды и успеха проекта навыки архитектуры и проектирования у разработчика, хотя бы в минимальном их виде.
Но хорошая архитектура — она в первую очередь для разработчиков, это ясный код, который легко использовать правильно, и сложно использовать неправильно. Для хорошего проектирования кода необходимо понимать специфику работы человека, который будет использовать твой код.
Но навыки проектирования (это именно навыки, не знания, теория тут не очень помогает) очень сложно получить, не побывав в роли пользователя своего же, или похожего, кода. Сложно извлечь урок проектирования и архитектуры из проекта, в котором ты можешь понять только часть. Сложно разработать хороший веб-апи, если ты никогда не использовал веб-апи.
Вот и получается бизнес-логика, которая требует целого слоя для адаптации к UI. Веб-апи, к которым нужно делать три запроса вместо одного. Постоянные обсуждения и переделки формата запросов и ответов (т.к. разрабатывают это разные люди, каждый из которых не понимает специфики другой части).
Это было бы так, отличайся они принципиально. Фронтенд фреймворки построены на нескольких базовых идеях, и разобравшись с четырьмя из них, с пятым разберешься с ходу.
К сожалению, не любой. Я думаю, здесь ситуация во многом похожа на спортивные достижения. Благодаря тренировкам можно стать намного сильнее и быстрее нетренированного человека, но невозможно стать, например, олимпийским чемпионом без генетической предрасположенности.
В науке и проще, и сложнее, можно сделать открытие случайно, не являясь лучшим из лучших, можно сильно двинуть область и за счет тяжкого многолетнего труда, не являясь, опять же, гением.
Но вот именно гениальные озарения, в любой области, к сожалению, недоступны середнячкам, я так считаю.
Нет, причем тут react-id. Я об "умном" обновлении ДОМ дерева, том, что, собственно, и делает Реакт реактивным.
В Реакте дерево ДОМ элементов является функцией, или проекцией, состояния приложения. И при изменении этого состояния дерево элементов перестраивается не полностью, а частично, производя минимальные изменения, необходимые для приведения дерева в нужное состояние.
Если не использовать Реакт (и другие virtual DOM библиотеки), то придется либо перестраивать все дерево полностью — и забыть о производительности, либо, как в Ангуляре, оптимизировать перестроение дерева для каждой отдельной директивы.
Web Components — это и есть изолированные кусочки, и это самое крутое, что сейчас есть для декомпозиции интерфейса.
Веб компоненты не исключают реакта и можно их сочетать.
учитывая что обычный DOM никуда не делся, а отделение обсерверов от непосредственной работы с DOM и оптимизации вызова рендер-методов компонентов — это совсем не исключительно Реактовская "магия" а просто принцип хорошей архитектуры в любой экосистеме
Преимущество виртуального DOM в том, что это встроено в библиотеку, а не реализуется каждый раз, как, например, при оптимизации директив в Ангуляре.
Надоели уже эти дифирамбы Реакту, которые исключительно дань моде, и не содержат никакой ценной информации в инженерном плане.
Немного преимуществ Реакта:
Нормальная работа с модульностью. Модули Ангуляр 1 не очень хорошо сочетаются с модульностью Javascript, т.к. объявляются и регистрируются в разных местах (ну или в одном, но тогда нужно следить, чтобы модуль был создан, ну или городить отложенную регистрацию).
Нормальная работа с children (по сравнению с Ангуляром). Нормальная — в смысле на уровне абстракций фреймворка, а не на уровне DOM.
Проверка шаблонов. В Реакте с TypeScript возможна компайл-тайм валидация шаблонов. В Ангуляре 1 шаблоны это просто строки, даже в рантайме не всегда валится ошибка. В Ангуляре 2 вроде чуть получше с этим, но тоже строки.
Отвечу сам себе: один из немногих явных плюсов — это нормальная работа с модульностью. В Ангуляр 2 нужно явно указывать компоненты/директивы, используемые в шаблоне, а в первом их нужно регистрировать в модуле, что проигрывает по явности и наглядности зависимости. (Однако, все еще нужно помнить, какой селектор использует компонент).
Вы, наверное, не совсем правильно меня поняли. Я не призываю отказаться от клиентской валидации, но она должна быть дополнением к серверной, в идеале использовать один и тот же код.
Считаю, что валидация форм — это тупиковый путь, который годится только для простейших приложений. Валидировать нужно бизнес сущности, и обязательно на стороне сервера (а на стороне клиента — опционально).
В сложном приложении бывает несколько форм для одной сущности, разные правила в зависимости от ролей пользователя, инлайн редактирование в гридах — делать валидацию форм — это значит дублировать код.
Валидация сущностей — это бизнес логика, и подход к ней должен быть соответствующий.
Вместо простого нормализованного API серверу приходится городить огород под клиента.
Да нет же, в том-то и дело, с тем же Angular ничего не нужно городить, у него достаточно гибкости, чтобы обеспечить редактирование нормализованных данных.
Кроме того, куда вы поместите функции для работы с данными?
В сервисы. Если же вы имели ввиду нечто вроде nameFull() — то в контроллер, во вью или в pipe. Взаимодействие с пользователем — в контроллеры.
Нормализация — это еще пол-беды. Для нокаута приходится данные копировать, вне зависимости от того, нужны ли изменения структуры, а часто потом еще и менять структуру для того, чтобы нокаут просто работал.
Это похоже на первый подход для Angular 1, который я описал.
Это может быть удобно при открытии поп-апа императивно — из какой-то логики, для запроса параметров, показа алерта и т.п.
Но иногда удобнее, чтобы поп-ап был частью разметки — например, при написании контролов типа дроп-дауна, либо сложных форм, где часть параметров выносится в поп-ап, но является частью скоупа. Тогда можно применять второй способ.
Я думаю, что ничем, кроме масштабируемости отдельных сервисов.
Есть два типа команд: один тип — это команды с четкой специализацией каждого человека, раньше их было много, сейчас они, наверное, только в энтерпрайзе; второй тип — это команды из аджайл, разработчики из таких команд обычно фулл-стек, сейчас в веб деве пре-энтерпрайз таких большинство. Это один из принципов аджайл — взаимозаменяемость разработчиков, поэтому разрабам дают отдельные фичи делать "с низу до верху", от базы до верстки.
Посмотрим с другой стороны. "Специализация" в технологии часто означает то, что человек выучил что-то одно, и считает, что этого достаточно. Я знаю людей, которые за десять лет работы выучили как писать бизнес-логику на C# и MS SQL Server. Ни веба, ни десктопа, ни другой платформы они не знают. Являются ли они классными профи и убеленными сединами гуру? Нет, и более того, те люди довольно посредственные разработчики.
Большинство проектов не требуют глубинных знаний платформы. (И, кстати, шанс их получить у специалиста такой же, как и у фулл-стек разработчика. Платформа, которая требует постоянного вникания в свои тонкости, не выживает). Намного практически полезней для команды и успеха проекта навыки архитектуры и проектирования у разработчика, хотя бы в минимальном их виде.
Но хорошая архитектура — она в первую очередь для разработчиков, это ясный код, который легко использовать правильно, и сложно использовать неправильно. Для хорошего проектирования кода необходимо понимать специфику работы человека, который будет использовать твой код.
Но навыки проектирования (это именно навыки, не знания, теория тут не очень помогает) очень сложно получить, не побывав в роли пользователя своего же, или похожего, кода. Сложно извлечь урок проектирования и архитектуры из проекта, в котором ты можешь понять только часть. Сложно разработать хороший веб-апи, если ты никогда не использовал веб-апи.
Вот и получается бизнес-логика, которая требует целого слоя для адаптации к UI. Веб-апи, к которым нужно делать три запроса вместо одного. Постоянные обсуждения и переделки формата запросов и ответов (т.к. разрабатывают это разные люди, каждый из которых не понимает специфики другой части).
Это было бы так, отличайся они принципиально. Фронтенд фреймворки построены на нескольких базовых идеях, и разобравшись с четырьмя из них, с пятым разберешься с ходу.
К сожалению, не любой. Я думаю, здесь ситуация во многом похожа на спортивные достижения. Благодаря тренировкам можно стать намного сильнее и быстрее нетренированного человека, но невозможно стать, например, олимпийским чемпионом без генетической предрасположенности.
В науке и проще, и сложнее, можно сделать открытие случайно, не являясь лучшим из лучших, можно сильно двинуть область и за счет тяжкого многолетнего труда, не являясь, опять же, гением.
Но вот именно гениальные озарения, в любой области, к сожалению, недоступны середнячкам, я так считаю.
Не будет ли реализация на основе прокси иметь те же ограничения и слабости, что и Нокаут?
Ну а как же реактивность? Реакт — это же не только абстракция для кастомных элементов.
Нет, причем тут react-id. Я об "умном" обновлении ДОМ дерева, том, что, собственно, и делает Реакт реактивным.
В Реакте дерево ДОМ элементов является функцией, или проекцией, состояния приложения. И при изменении этого состояния дерево элементов перестраивается не полностью, а частично, производя минимальные изменения, необходимые для приведения дерева в нужное состояние.
Если не использовать Реакт (и другие virtual DOM библиотеки), то придется либо перестраивать все дерево полностью — и забыть о производительности, либо, как в Ангуляре, оптимизировать перестроение дерева для каждой отдельной директивы.
Ну частично да, согласен. Но, например, умный патчинг DOM на чистых веб-компонентах не реализуешь.
Веб компоненты не исключают реакта и можно их сочетать.
Преимущество виртуального DOM в том, что это встроено в библиотеку, а не реализуется каждый раз, как, например, при оптимизации директив в Ангуляре.
Немного преимуществ Реакта:
Не совсем так, Реакт может работать и с изменяемым состоянием.
Отвечу сам себе: один из немногих явных плюсов — это нормальная работа с модульностью. В Ангуляр 2 нужно явно указывать компоненты/директивы, используемые в шаблоне, а в первом их нужно регистрировать в модуле, что проигрывает по явности и наглядности зависимости. (Однако, все еще нужно помнить, какой селектор использует компонент).
А в чем преимущество 2.0? Вторая версия это же, по сути, не обновление, а новый продукт.
Вы, наверное, не совсем правильно меня поняли. Я не призываю отказаться от клиентской валидации, но она должна быть дополнением к серверной, в идеале использовать один и тот же код.
Считаю, что валидация форм — это тупиковый путь, который годится только для простейших приложений. Валидировать нужно бизнес сущности, и обязательно на стороне сервера (а на стороне клиента — опционально).
В сложном приложении бывает несколько форм для одной сущности, разные правила в зависимости от ролей пользователя, инлайн редактирование в гридах — делать валидацию форм — это значит дублировать код.
Валидация сущностей — это бизнес логика, и подход к ней должен быть соответствующий.
Насколько я понимаю, React тоже сравнивает изначальные данные в дефолтной реализации
shouldComponentUpdate?Да нет же, в том-то и дело, с тем же Angular ничего не нужно городить, у него достаточно гибкости, чтобы обеспечить редактирование нормализованных данных.
В сервисы. Если же вы имели ввиду нечто вроде
nameFull()— то в контроллер, во вью или в pipe. Взаимодействие с пользователем — в контроллеры.Нормализация — это еще пол-беды. Для нокаута приходится данные копировать, вне зависимости от того, нужны ли изменения структуры, а часто потом еще и менять структуру для того, чтобы нокаут просто работал.
Это похоже на первый подход для Angular 1, который я описал.
Это может быть удобно при открытии поп-апа императивно — из какой-то логики, для запроса параметров, показа алерта и т.п.
Но иногда удобнее, чтобы поп-ап был частью разметки — например, при написании контролов типа дроп-дауна, либо сложных форм, где часть параметров выносится в поп-ап, но является частью скоупа. Тогда можно применять второй способ.
Контент попапа может быть динамическим, и зависеть от состояния вызывающего компонента.