Pull to refresh
114
0
Протько Сергей @Fesor

Full-stack developer

Send message
Грег Янг идею Event Sourcing-а форсит с 2005-ого года примерно, а используется в том или ином виде уже не первый десяток лет. Ну так, к слову.
таких задач как бы нет, вот и все.

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

Если компоненту вдруг понадобилось обновить состояние или поменять его — прокидываем в сервисы событие/действие, и далее ждем пока сверху у нас обновится состояние. Очень простая концепция которая невероятно упрощает махинации с UI.

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

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

собственно redux это реализация flux, просто в redux у нас единый источник правды и композиция редьюсеров, которые формируют новое состояние (а там у нас есть целоя гора возможностей как чего сделать), а flux — это просто принцип мол «юзайте event sourcing и все будет хорошо»
Про Redux слышал, но не смотрел.


подход redux-а как раз таки решает проблему flux-а которую вы описываете. Все состояние приложение хранится в одном месте, и спускается вниз разделяясь для каждого конкретного компонента. А там уже много всего можно придумать. Компоненты же поднимают ивенты о том что надо что-то сделать вверх, и так все проходит строго по циклу. Удобно, просто тестить, но на простых проектах — оверхэд.
Надо развивать культуру разработки, а не фреймворками меряться.
Вы об этом? Ну то есть надо замэпить данные на какого-то наследника Model, сделать например MyActionRequest < — Model, замэпить руками параметры реквеста (благо это просто), провалидировать… Как собственно это и происходило в Yii1.1.
Ну… в Yii1.1 приходилось прикладывать слишком много усилия что бы сделат так как я хочу, а не как заложено фреймворком. Банально много бойлерплейта. С 2.0 ситуация конечно получше (насколько я могу судить бегло пробежавшись по документации).
Вас никто не заставляет его использовать.


В Yii2 есть что-нибудь типа ларавелевский FormRequest-ов? Ну мол что бы отделить валидацию данных запроса от бизнес объектов?

В целом проблема в том что обычно люди используют то что есть, а не то что надо в данной конкретной ситуации. Тут уже была рядом дискуссия на эту тему, что AR подходит далеко не для всех задач, но есть «фанаты» которые просто не знают о других подходах.
Это справедливо для версии 1.1. В 2.0 не сказать что координально изменилась ситуация, но хотя бы есть IoC и можно писать нормально, если приложить усилия. Потому без жесткого код ревью давать новичку в руки Yii я бы не стал (ну и Laravel туда же). В прочем это справедливо для любого PHP фреймворка.

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

Из вариантов посложнее и интереснее — серверный пререндер (для React, Angualr2, Ember и других штук поддерживающих server-side рендринг), который чаще используется для улучшения UX, но и для поисковиков норм. В этом случае алгоритм будет одинаков для всех. Засылаем запрос в express-сервер какой-нибудь, тот запускает рендринг первоначальный приложения и выплевывает на клиент. Когда подтягиваются JS либы приложение оживает, но пользователь уже видит в принципе оное с каким-то состоянием, что собственно и улучшает UX.

Конечно же этот подход намного сложнее так как вводит ограничения на то, что мы можем делать и как примерно все это должно работать (например stateless UI, проход данных сверху вних и т.д. при таком варианте все это можно организовать относительно малой кровью).
Обычная классическая MVC модель из Laravel или Symfony


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

image

А в Laravel и Symfony классический MVA

image

Роль адаптера выполняют GRASP-контроллеры.

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

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

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


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


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

Ну и да, это автоматически решает проблемы с ботами соц сетей и т.д.

обновление sitemap с интервалом 10 минут, используя crontab


ну так себе решение на самом деле, было бы интереснее очереди сообщений и обновление по требованию или грамотная инвалидация кэша…

но готовое решение быстро нашлось — socketo.me.


опять же, ratchet это прикольно но он довольно давно не обновляется. Есть более качественные реализации WS серверов. Отдельно стоит заметить проект amphp и тамошнюю реализацию HTTP/WS сервера aerys

Ну и там же в amphp есть асинхронные драйвера для работы с mysql или postgres, что круто в условия event loop. В вашем же случае ORM хоть работает и быстро, но на это время блокируется весь сервер. Что не ок.

Не нашёл решение более элегантного, как через каждую минуту запускать команду в crontab


supervisord
Есть «Да» которое покрывает данный кейс.
единственное что для 2.x ошибка теперь чуть более детализирована. Появляется информация о контексте ошибки, ну мол у какого элемента это и все такое.
Если в test возникнет исключение, оно будет проглочено как в первой версии или всё же выведено в консоль?


выведет в консоль. Причем сначала ангуляр обернет исключение в свое (EXCEPTION: Error during evaluation of "click"), ну и выведет ORIGINAL EXCEPTION: Error: Your exception message.

что ngFormModel — не серебряная пуля.


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


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

Я стараюсь дробить компоненты таким образом, что бы они становились реально реюзабельными и помещались в один экран (с учетом ограничения по длине строки).

плюс отладка тяжелая

А вот тут статья немного лукавит. Как я отметил в статье, ангуляр теперь будет выкидывать ошибки при компиляции шаблонов и выполнении выражений (а не молчать как в 1.x затрудняя отладку). То есть выражение {{foobar.test}}' в случае если foobar не объект, будет падать с TypeError и т.д.

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

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

Также у меня плохие отношения с двухсторонним биндингом


В angular2 двустороннего биндинга нет, есть сахар для того что бы не писать постоянно проброс данных в обе стороны (иногда полезно, редко, но бывает).

С учетом того что теперь помимо ngModel есть ngFormModel, то необходимости в использовании двустороннего биндинга почти не остается. Только для очень простых случаев для которых подобные вещи выглядят оверхэдом.
В голову даже не лезет зачем так делать как вы написали


Вы писали на angular 1.0? в те времена подругому никак нельзя было. И в 1.1. В 1.2 уже можно было отказаться от скоупа в контроллерах, но в директивах еще было неудобно. в 1.3 уже можно было делать полноценные компоненты, а удобно это станет только с выходом 1.5.

Ну и да — у Angular 1.x ужасная документация. Ну то есть 3-4 года назад это было ок, и на фоне всего остального было круто. Но сегодня… ужас дикий, причем официальная дока и примеры никак не придерживаются этим самым goodpractices. А потому людей сходу учили плохим вещам.

Я очень рад что документация Angular2 в этом плане намного более качественнее сделана. Но примеры еще можно было бы порефакторить.
все еще поддерживает аттрибутивные директивы


Да, суть в простом разделении. Компоненты — существительные, сущности, отдельные UI компоненты. Атрибутивные директивы — прилагательные, декораторы для компонентов. Простой пример — компонет input и декоратор required добавляющий валидацию, расширяющий поведение компонента.

Лично мне подобное разделение нравится, так как оно пораждает меньше сложности и позволяет удобно расширять функционал компонентов. Но не думаю что эту фичу будут часто юзать.

Что до классовых директив — полностью согласен. Я к слову знаю пару людей которые расстроены тем что в angular2 так больше нельзя. Благо после пары холиваров они угомонились и приняли что это не ок вариант.

что не разберешь, откуда что берется

Если соблюдать правила (компонент — существительное, директива — прилагательное) и нормально именовывать директивы — то все довольно ок. Но да, я согласен что сделать плохо можно.

Также старый Angular использовал $scope (или даже $rootScope), и люди ошибочно его использовали для связи компонентов между собой


О да, и тут больше даже грех документации. Где-то с версии 1.3 angular можно вообще не использовать $scope (собственно я его не особо часто использую уже с версии 1.2 с введением controllerAs). Документация до сих пор преподносит инфу 2012-ого года как актуальную, хотя в best pratice и style guide хотя бы описано что это не ок идея. И что использовать $broadcast/$emit для общения своих директив это не ок говорится.

Я полагаю, что если бы в 2013-ом году обновили документацию и PhoneCat туториал под существующие уже на тот момент бэст практисы, проблем было бы меньше. Все же большинство сразу после полу часа чтения документации (который описывает именно $scope и подход с контроллерами) идут писать приложеньки а бэст практис — ну их.

В angular2 такой проблемы нет, все «плохое» спрятаны глубоко внутри.
неконтролируемую связность директив\модулей, что по сути имеется в MV* архитектурах тоже


Можете пояснить? Ибо я не особо понимаю о чем вы. Ибо никаких проблем с неконтролируемой связностью в angular2 нет, ну либо я уже отношусь к той категории людей которые не используют в ангуляре скоуп и «магию» со времен angular 1.2 и потому мне сложно понять о чем вы.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity