Web Components — это и есть изолированные кусочки, и это самое крутое, что сейчас есть для декомпозиции интерфейса.
Веб компоненты не исключают реакта и можно их сочетать.
учитывая что обычный DOM никуда не делся, а отделение обсерверов от непосредственной работы с DOM и оптимизации вызова рендер-методов компонентов — это совсем не исключительно Реактовская "магия" а просто принцип хорошей архитектуры в любой экосистеме
Преимущество виртуального DOM в том, что это встроено в библиотеку, а не реализуется каждый раз, как, например, при оптимизации директив в Ангуляре.
Надоели уже эти дифирамбы Реакту, которые исключительно дань моде, и не содержат никакой ценной информации в инженерном плане.
Немного преимуществ Реакта:
Нормальная работа с модульностью. Модули Ангуляр 1 не очень хорошо сочетаются с модульностью Javascript, т.к. объявляются и регистрируются в разных местах (ну или в одном, но тогда нужно следить, чтобы модуль был создан, ну или городить отложенную регистрацию).
Нормальная работа с children (по сравнению с Ангуляром). Нормальная — в смысле на уровне абстракций фреймворка, а не на уровне DOM.
Проверка шаблонов. В Реакте с TypeScript возможна компайл-тайм валидация шаблонов. В Ангуляре 1 шаблоны это просто строки, даже в рантайме не всегда валится ошибка. В Ангуляре 2 вроде чуть получше с этим, но тоже строки.
Отвечу сам себе: один из немногих явных плюсов — это нормальная работа с модульностью. В Ангуляр 2 нужно явно указывать компоненты/директивы, используемые в шаблоне, а в первом их нужно регистрировать в модуле, что проигрывает по явности и наглядности зависимости. (Однако, все еще нужно помнить, какой селектор использует компонент).
Вы, наверное, не совсем правильно меня поняли. Я не призываю отказаться от клиентской валидации, но она должна быть дополнением к серверной, в идеале использовать один и тот же код.
Считаю, что валидация форм — это тупиковый путь, который годится только для простейших приложений. Валидировать нужно бизнес сущности, и обязательно на стороне сервера (а на стороне клиента — опционально).
В сложном приложении бывает несколько форм для одной сущности, разные правила в зависимости от ролей пользователя, инлайн редактирование в гридах — делать валидацию форм — это значит дублировать код.
Валидация сущностей — это бизнес логика, и подход к ней должен быть соответствующий.
Вместо простого нормализованного API серверу приходится городить огород под клиента.
Да нет же, в том-то и дело, с тем же Angular ничего не нужно городить, у него достаточно гибкости, чтобы обеспечить редактирование нормализованных данных.
Кроме того, куда вы поместите функции для работы с данными?
В сервисы. Если же вы имели ввиду нечто вроде nameFull() — то в контроллер, во вью или в pipe. Взаимодействие с пользователем — в контроллеры.
Нормализация — это еще пол-беды. Для нокаута приходится данные копировать, вне зависимости от того, нужны ли изменения структуры, а часто потом еще и менять структуру для того, чтобы нокаут просто работал.
Это похоже на первый подход для Angular 1, который я описал.
Это может быть удобно при открытии поп-апа императивно — из какой-то логики, для запроса параметров, показа алерта и т.п.
Но иногда удобнее, чтобы поп-ап был частью разметки — например, при написании контролов типа дроп-дауна, либо сложных форм, где часть параметров выносится в поп-ап, но является частью скоупа. Тогда можно применять второй способ.
Я не думаю, что метаданные обеспечат необходимый уровень гибкости, в частности, подмену произвольного сервиса или использование scoped врапперов и т.п.
Я с KnockoutJs давно не работал, но раньше, помню, постоянно была проблема с взаимозависимостями, да и с обычными тоже, вроде бы понятно, как это работает, но предусмотреть и продумать все случаи в сложных моделях просто нереально. Приходилось менять структуру объекта, выносить какие-то свойства или функции, что ломало нафиг маппинг.
В общем, проще в принципе не значит проще на практике :) Надеюсь, они пофиксили это в новых версиях, возможно, там можно было бы разделить фазы инвалидации зависимостей и их пересчета, чтобы избавиться от множественных каскадных пересчетов.
Ангуляр, конечно, достает своим $digest циклом, он вроде как и не должен использоваться, но постоянно приходится. Но работа самого dirty-checker-а очень предсказуемая, как по мне, обычно все работает.
Стандартный контейнер определяет необходимый для .NET Core минимум способов регистрации зависимости: transient, singleton, scoped. Их реализует любой контейнер. Нужно ли было усложнить интерфейс добавления зависимостей и сделать его более богатым и совместимым со всеми фичами Simple Injector, Ninject, Castle Winsdor, Autofac и т.д?
Я считаю, что нет, это не принесло бы значительной пользы, но сильно усложнило бы написание адаптеров для сторонних библиотек. Это хорошая практика дизайна системы — делать точки расширения с простым и очевидным интерфейсом, без сложных внутренних инвариантов. Такие интерфейсы легко понять и реализовать.
Понять, запомнить и реализовать все инварианты регистрации любого из современных контейнеров очень и очень сложно, что привело бы к кучке реализаций, совместимых между собой на 90%, и порождающих такие баги, что обычные ошибки регистрации будут потом казаться ясными, как предупреждения компилятора.
В кои-то веки Майкрософт предпочла простоту универсальности.
Я думаю, в календаре нужен коллбек на показ месяца. На сколько месяцев вперед нужно его загружать, сказать сложно.
Я не думаю, что тут есть чисто проблема для Реакта, для она будет одинакова для любого фреймворка — загружать график перед показом месяца.
С KnockoutJS у меня как-то не задались отношения. Мне не очень нравится необходимость подготавливать модели. Ангуляр подкупает своей возможностью, грубо говоря, "редактировать JSON".
Ну частично да, согласен. Но, например, умный патчинг DOM на чистых веб-компонентах не реализуешь.
Веб компоненты не исключают реакта и можно их сочетать.
Преимущество виртуального DOM в том, что это встроено в библиотеку, а не реализуется каждый раз, как, например, при оптимизации директив в Ангуляре.
Немного преимуществ Реакта:
Не совсем так, Реакт может работать и с изменяемым состоянием.
Отвечу сам себе: один из немногих явных плюсов — это нормальная работа с модульностью. В Ангуляр 2 нужно явно указывать компоненты/директивы, используемые в шаблоне, а в первом их нужно регистрировать в модуле, что проигрывает по явности и наглядности зависимости. (Однако, все еще нужно помнить, какой селектор использует компонент).
А в чем преимущество 2.0? Вторая версия это же, по сути, не обновление, а новый продукт.
Вы, наверное, не совсем правильно меня поняли. Я не призываю отказаться от клиентской валидации, но она должна быть дополнением к серверной, в идеале использовать один и тот же код.
Считаю, что валидация форм — это тупиковый путь, который годится только для простейших приложений. Валидировать нужно бизнес сущности, и обязательно на стороне сервера (а на стороне клиента — опционально).
В сложном приложении бывает несколько форм для одной сущности, разные правила в зависимости от ролей пользователя, инлайн редактирование в гридах — делать валидацию форм — это значит дублировать код.
Валидация сущностей — это бизнес логика, и подход к ней должен быть соответствующий.
Насколько я понимаю, React тоже сравнивает изначальные данные в дефолтной реализации
shouldComponentUpdate?Да нет же, в том-то и дело, с тем же Angular ничего не нужно городить, у него достаточно гибкости, чтобы обеспечить редактирование нормализованных данных.
В сервисы. Если же вы имели ввиду нечто вроде
nameFull()— то в контроллер, во вью или в pipe. Взаимодействие с пользователем — в контроллеры.Нормализация — это еще пол-беды. Для нокаута приходится данные копировать, вне зависимости от того, нужны ли изменения структуры, а часто потом еще и менять структуру для того, чтобы нокаут просто работал.
Это похоже на первый подход для Angular 1, который я описал.
Это может быть удобно при открытии поп-апа императивно — из какой-то логики, для запроса параметров, показа алерта и т.п.
Но иногда удобнее, чтобы поп-ап был частью разметки — например, при написании контролов типа дроп-дауна, либо сложных форм, где часть параметров выносится в поп-ап, но является частью скоупа. Тогда можно применять второй способ.
Контент попапа может быть динамическим, и зависеть от состояния вызывающего компонента.
Я не думаю, что метаданные обеспечат необходимый уровень гибкости, в частности, подмену произвольного сервиса или использование scoped врапперов и т.п.
Новый дотнет модульный, тот же асп нет конфигурируется путем регистрации и использования зависимостей. Какая этому альтернатива?
Не совсем понимаю, что вы имеете ввиду под сохранением контекста? Можете пояснить?
Я с KnockoutJs давно не работал, но раньше, помню, постоянно была проблема с взаимозависимостями, да и с обычными тоже, вроде бы понятно, как это работает, но предусмотреть и продумать все случаи в сложных моделях просто нереально. Приходилось менять структуру объекта, выносить какие-то свойства или функции, что ломало нафиг маппинг.
В общем, проще в принципе не значит проще на практике :) Надеюсь, они пофиксили это в новых версиях, возможно, там можно было бы разделить фазы инвалидации зависимостей и их пересчета, чтобы избавиться от множественных каскадных пересчетов.
Ангуляр, конечно, достает своим
$digestциклом, он вроде как и не должен использоваться, но постоянно приходится. Но работа самого dirty-checker-а очень предсказуемая, как по мне, обычно все работает.react-overlaysтоже используетReactDOM.unstable_renderSubtreeIntoContainer. В чем его отличие от обычногоrender, вы не знаете случайно?Стандартный контейнер определяет необходимый для .NET Core минимум способов регистрации зависимости: transient, singleton, scoped. Их реализует любой контейнер. Нужно ли было усложнить интерфейс добавления зависимостей и сделать его более богатым и совместимым со всеми фичами Simple Injector, Ninject, Castle Winsdor, Autofac и т.д?
Я считаю, что нет, это не принесло бы значительной пользы, но сильно усложнило бы написание адаптеров для сторонних библиотек. Это хорошая практика дизайна системы — делать точки расширения с простым и очевидным интерфейсом, без сложных внутренних инвариантов. Такие интерфейсы легко понять и реализовать.
Понять, запомнить и реализовать все инварианты регистрации любого из современных контейнеров очень и очень сложно, что привело бы к кучке реализаций, совместимых между собой на 90%, и порождающих такие баги, что обычные ошибки регистрации будут потом казаться ясными, как предупреждения компилятора.
В кои-то веки Майкрософт предпочла простоту универсальности.
Я думаю, в календаре нужен коллбек на показ месяца. На сколько месяцев вперед нужно его загружать, сказать сложно.
Я не думаю, что тут есть чисто проблема для Реакта, для она будет одинакова для любого фреймворка — загружать график перед показом месяца.
С KnockoutJS у меня как-то не задались отношения. Мне не очень нравится необходимость подготавливать модели. Ангуляр подкупает своей возможностью, грубо говоря, "редактировать JSON".
Riotjs выглядит интересно.