Да, нужно больше языков, конечно!
Если серьезно, то по-моему после появления arrow-functions в ES6 или typescript (в котором они были от рождения), это всё на столько бесполезно…
Разумеется, вы не можете. Никаких особых флагов, кроме --jsx (кажется, он так называется) не нужны.
Компонент — generic от его props. Всё, что не указано в generic типе, передавать, разумеется, нельзя.
Сильно уменьшает сложность за счёт именно правильной декомпозиции.
Имеет очень низкий порог вхождения: практически любой разработчик может за разумное время поправить баг в UI и не разломает при этом всё.
Даёт возможности для статической типизации всего UI. Не думаю, что какой-то другой фреймворк даст возможность проверить, что в "<a hrea" нет опечатки. Какой-нибудь статический анализатор html может это сделать, но это тривиальный случай, статическая типизация даёт на много больше, чем это, но я тут не хочу углубляться. Для нас это очень важно, как можно было понять из статьи.
Подразумевается, что если технология в продакшне на крупных сайтах — значит вероятность того, что её завтра все забудут, несколько ниже, чем если она менее распространена. По крайней мере я себе этот довод вижу так.
1. По моему опыту количество переходов между состояниями много больше, чем количество сущностей. Разумно ли проверять переходы из состояния в состояние?
2. Валидация в доменной модели подразумевает, что мы валидируем всю модель целиком. Если в результате транзакции оказалось, что модель неконсистентна — значит, мы просто забыли что-то проверить.
Ой, это только какая-то не та версия. Вот оригинальное видео, а то, что выше — уже какая-то другая версия того же доклада, не та, которую я хотел скинуть
Вообще у этого чувака много очень смешных выступлений, например вот это про FRP и ClojureScript.
Да уже несколько лет как :)
Примерно в тот момент, когда ребята из facebook поняли, что всё это время мы отделяли представление от логики неправильно, и гораздо естественнее создавать компоненты, а не разделять «вёрстку» и «логику» просто потому что так принято.
У Александра Соловьёва на эту тему просто шикарнейший доклад, обожаю его, можете посмотреть.
Понятно.
В принципе я совсем чуть-чуть рассказал в конце последней статьи (в разделе «Валидация»).
Но конечно тема очень большая, потому что требований к фреймворку валидации было довольно много. Надо собраться как-нибудь и описать это всё :)
Ну… У меня, если честно, что-то никаких ассоциаций со стэк-фреймами нет :)
Пользователь увидит то валидационное сообщение, которое возникло в сущности.
Тут у нас ещё есть заморочка с тем, что у нас разные приложения работают с одними и теми же сущностями. Например, потребитель может сохраняться через сервисы (значит, на каком-то сайте регистрируется), а может через нашу админку (значит, наш сотрудник создаёт какого-то потребителя зачем-то). И мы должны разные сообщения показывать в таком случае. Так что у нас в коде используются ключи сообщений, а сами тексты хранятся в базе, и различаются для разных приложений.
Планировал на эту тему следующую статью писать :)
У нас фреймворк валидации работает следующим образом. Вся валидация находится в сущностях и частично в репозиториях. Ошибки валидации не висят в воздухе, а привязываются к ключам валидации. Для этого у нас есть класс ValidationKey с наследниками, например EntityPropertyValidationKey, который содержит в себе ссылку на сущность и название свойства, к которому он относится. В процессе сохранения данных в базу клиентский код должен связать валидационный ключ с этими данными. Если мы говорим про Web, то данные у нас приходят в полях вью-моделей. При этом данные могут перемещаться от одного объекта к другому. Например, во вью-модели мы создаём не сущность, а какую-то DTO'шку, которая в последствие передаётся в репозиторий. В такой ситуации мы связываем исходные данные с полями DTO'шки, а затем в репозитории связываем поле DTO'шки с полем сущности.
Говоря «связываем» я подразумеваю, что у нас где-то во фреймворке валидации просто хранится связь валидационных ключей между собой и валидационных ключей и путей по свойствам вью-моделей.
Надеюсь, хоть что-то понятно, просто не хотелось бы тут ещё код писать :)
И как это связано с необходимостью переносить валидацию в команды? Нужно просто сделать архитектуру валидации немного сложнее, чем представлено, позволяя отслеживать, как данные перемещаются из одних объектов в другие.
Поддержка tsx (typescript and xml, аналог facebook'овского jsx для react с типами) была написана сообществом, после упорных доработок была включена в компилятор и уже полгода как доступна в Visual Studio. Официально. Говорить при этом, что TypeScript не управляется сообществом, мне кажется совершенно некорректно.
MSSQL поддерживает загрузку .NET-сборок, функции в которых можно мапить на хранимые процедуры самого SQL. За счёт этого можно сделать поддержку и регулярных выражений в MSSQL, и прокинуть её в тот же linq to sql примерно так же, как это показано в этой статье для EF.
Не нужно выносить разметку. Она связана с логикой приложения, и это не coupling, это cohesion. Компонент — это логика и представление. Тут SRP не по принципу «ты определяешь представление (как будет выглядеть какой-то элемент)» и «ты определяешь логику (как взаимодействовать с конкретным элементом)», а по принципу «ты инкапсулированный компонент, в тебе представление и логика его отображения».
Тут правда есть нюанс с тем, как верстальщика с этим работать заставить. У нас процесс построен, что верстальщик концептуально верстает элементы управления, а мы уже из этой вёрстки создаём компоненты, так что у нас нет проблемы.
На эту тему есть совершенно прекрасный доклад Александра Соловьева Как писать UI без боли. Вообще у него совершенно потрясающие видео на YouTube, очень советую и другие посмотреть :)
Если серьезно, то по-моему после появления arrow-functions в ES6 или typescript (в котором они были от рождения), это всё на столько бесполезно…
Компонент — generic от его props. Всё, что не указано в generic типе, передавать, разумеется, нельзя.
2. Валидация в доменной модели подразумевает, что мы валидируем всю модель целиком. Если в результате транзакции оказалось, что модель неконсистентна — значит, мы просто забыли что-то проверить.
Вообще у этого чувака много очень смешных выступлений, например вот это про FRP и ClojureScript.
Примерно в тот момент, когда ребята из facebook поняли, что всё это время мы отделяли представление от логики неправильно, и гораздо естественнее создавать компоненты, а не разделять «вёрстку» и «логику» просто потому что так принято.
У Александра Соловьёва на эту тему просто шикарнейший доклад, обожаю его, можете посмотреть.
В принципе я совсем чуть-чуть рассказал в конце последней статьи (в разделе «Валидация»).
Но конечно тема очень большая, потому что требований к фреймворку валидации было довольно много. Надо собраться как-нибудь и описать это всё :)
Пользователь увидит то валидационное сообщение, которое возникло в сущности.
Тут у нас ещё есть заморочка с тем, что у нас разные приложения работают с одними и теми же сущностями. Например, потребитель может сохраняться через сервисы (значит, на каком-то сайте регистрируется), а может через нашу админку (значит, наш сотрудник создаёт какого-то потребителя зачем-то). И мы должны разные сообщения показывать в таком случае. Так что у нас в коде используются ключи сообщений, а сами тексты хранятся в базе, и различаются для разных приложений.
У нас фреймворк валидации работает следующим образом. Вся валидация находится в сущностях и частично в репозиториях. Ошибки валидации не висят в воздухе, а привязываются к ключам валидации. Для этого у нас есть класс ValidationKey с наследниками, например EntityPropertyValidationKey, который содержит в себе ссылку на сущность и название свойства, к которому он относится. В процессе сохранения данных в базу клиентский код должен связать валидационный ключ с этими данными. Если мы говорим про Web, то данные у нас приходят в полях вью-моделей. При этом данные могут перемещаться от одного объекта к другому. Например, во вью-модели мы создаём не сущность, а какую-то DTO'шку, которая в последствие передаётся в репозиторий. В такой ситуации мы связываем исходные данные с полями DTO'шки, а затем в репозитории связываем поле DTO'шки с полем сущности.
Говоря «связываем» я подразумеваю, что у нас где-то во фреймворке валидации просто хранится связь валидационных ключей между собой и валидационных ключей и путей по свойствам вью-моделей.
Надеюсь, хоть что-то понятно, просто не хотелось бы тут ещё код писать :)
Поддержка tsx (typescript and xml, аналог facebook'овского jsx для react с типами) была написана сообществом, после упорных доработок была включена в компилятор и уже полгода как доступна в Visual Studio. Официально. Говорить при этом, что TypeScript не управляется сообществом, мне кажется совершенно некорректно.
Тут правда есть нюанс с тем, как верстальщика с этим работать заставить. У нас процесс построен, что верстальщик концептуально верстает элементы управления, а мы уже из этой вёрстки создаём компоненты, так что у нас нет проблемы.
На эту тему есть совершенно прекрасный доклад Александра Соловьева Как писать UI без боли. Вообще у него совершенно потрясающие видео на YouTube, очень советую и другие посмотреть :)