После первого взгляда на доки и примеры, ощущение что это тот же Knockout.
На Knockout я писал и Ractive я вижу один весомый плюс — свойства ModelView избавлены от того что они должны быть функциями.
В React же главные фишки в том, что у него виртуальный DOM и классы React можно агрегировать друг с другом. А в Knockout, Angular и Ractive — нельзя
| Порог вхождения — это не блажь или злые козни разработчика фреймворка, желающего потешить свое самолюбие, а объективные требования к квалификации программиста
Порог вхождения — … это требования…
Хорошо, вы мне сейчас определение в вашей интерпретации описали, а дальше то что? Вы ничего по поводу того, что этот фреймворк с высоким порогом вхождения является эффективным инструментом не сказали. Пока что лишь вижу минус в скорости обучения команды и вливания новичков.
Философия у React очень понравилась мне, кстати. Т.к. MVC (или MVP) у меня всё же ассоциируется как с архитектурой всего приложения вместе с серверной частью.
Когда постепенно входило в моду MVC in MVC я становился всё более и более грустным, т.к. ничего не упрощалось, а лишь наоборот.
Пока что я не встречал ничего более простого и удобного чем React для того что бы синхронизировать состояние и DOM.
Я устал уже слушать оправдания сложных(с высоким порогом вхождения) фреймворков, что они нужны для больших и сложных приложений, поэтому и сложные.
Тут большая логическая ошибка, из первого никогда не следует второе.
Как правило, время расставляет всё на свои места и потом эти сложные фреймворки получают «заслуженную» славу.
А судить тех, кто не желает сено перекидывать штыковой лопатой, я бы не стал.
А я ещё убрал отображение Metro приложений в статус баре.
Когда сделают пуск гибридным, возможно тогда уже однородно будут смотреться они вместе с классическими в панели.
| Если бы мы сделали типизированные сообщения, то внутри месседж системы нам пришлось бы cделать unchecked cast.
Зачем? Если вам приходит точно Avatar через аргумент, зачем вам приводить типы?
На сколько я понял из статьи(я мог ошибиться), то у вас идут Msg от Abonent к Abonent и они выполняются(метод run) на Abonent получателе.
Проверку самого Abonent поручили самому Msg. А логика того кто кому может послать Msg прячется исключительно в интерфейсе клиента. Другими словами, это клиент решает, что при наведении курсора на табуретку, отключается возможность послать Msg с действием ударить. Но мы это сможем сделать взломав клиент и тогда у вас будет в логи сыпать недопустимые операции.
Правильно я всё понял?
Если так, то очень интересна архитектура проверка доступности сообщений на клиенте. Т.к. мне кажется. вы решали проблему согласованности ограничений игровой логики и ошибок сообщений, если действие было выполнено, но не не поддерживается самим Msg.
У меня глаз зацепился за кусок кода и не отпускает:
Override
public void run(@NotNNull Abonent abonent) {
if (! (abonent instanceof Avatar)) {
Cast.logError(abonent, Avatar.class);
return;
}
final Avatar avatar = (Avatar) abonent
//…
}
По сути это нарушение LSP, в том моменте где вы начинаете проверять тип абонента. Что говорит о том, что есть проблема в архитектуре. Это вынужденная мера?
В теории, если уж вам приходит Abonent, то вы должны внутри ориентироваться на его интерфейс. Иначе какой смысл указывать в контракте тип аргумента?
Windows Phone:
Не должно быть прямоугольников в ленте избранном и т.д.
Контент сам должен себя выделять. Прекрасный пример такого приложения — ВКонтакте официальный.
Добавьте, пожалуйста, в контекстное меню копирования ссылки на статью. Очень часто нужно отослать кому то ссылку, а через браузер искать статью очень не удобно.
Вот это: facebook.github.io/react/docs/tutorial.html#composing-components
На Knockout я писал и Ractive я вижу один весомый плюс — свойства ModelView избавлены от того что они должны быть функциями.
В React же главные фишки в том, что у него виртуальный DOM и классы React можно агрегировать друг с другом. А в Knockout, Angular и Ractive — нельзя
return?
Порог вхождения — … это требования…
Хорошо, вы мне сейчас определение в вашей интерпретации описали, а дальше то что? Вы ничего по поводу того, что этот фреймворк с высоким порогом вхождения является эффективным инструментом не сказали. Пока что лишь вижу минус в скорости обучения команды и вливания новичков.
Когда постепенно входило в моду MVC in MVC я становился всё более и более грустным, т.к. ничего не упрощалось, а лишь наоборот.
Пока что я не встречал ничего более простого и удобного чем React для того что бы синхронизировать состояние и DOM.
Тут большая логическая ошибка, из первого никогда не следует второе.
Как правило, время расставляет всё на свои места и потом эти сложные фреймворки получают «заслуженную» славу.
А судить тех, кто не желает сено перекидывать штыковой лопатой, я бы не стал.
В эти года у меня в холодильнике еда была редкостью, и стоял я в очередях по несколько часов — хватит нести чушь.
Когда сделают пуск гибридным, возможно тогда уже однородно будут смотреться они вместе с классическими в панели.
Зачем? Если вам приходит точно Avatar через аргумент, зачем вам приводить типы?
На сколько я понял из статьи(я мог ошибиться), то у вас идут Msg от Abonent к Abonent и они выполняются(метод run) на Abonent получателе.
Проверку самого Abonent поручили самому Msg. А логика того кто кому может послать Msg прячется исключительно в интерфейсе клиента. Другими словами, это клиент решает, что при наведении курсора на табуретку, отключается возможность послать Msg с действием ударить. Но мы это сможем сделать взломав клиент и тогда у вас будет в логи сыпать недопустимые операции.
Правильно я всё понял?
Если так, то очень интересна архитектура проверка доступности сообщений на клиенте. Т.к. мне кажется. вы решали проблему согласованности ограничений игровой логики и ошибок сообщений, если действие было выполнено, но не не поддерживается самим Msg.
Override
public void run(@NotNNull Abonent abonent) {
if (! (abonent instanceof Avatar)) {
Cast.logError(abonent, Avatar.class);
return;
}
final Avatar avatar = (Avatar) abonent
//…
}
По сути это нарушение LSP, в том моменте где вы начинаете проверять тип абонента. Что говорит о том, что есть проблема в архитектуре. Это вынужденная мера?
В теории, если уж вам приходит Abonent, то вы должны внутри ориентироваться на его интерфейс. Иначе какой смысл указывать в контракте тип аргумента?
Они же вроде как местные дистрибьюторы?
Ничего ему не будет.
Не должно быть прямоугольников в ленте избранном и т.д.
Контент сам должен себя выделять. Прекрасный пример такого приложения — ВКонтакте официальный.
Добавьте, пожалуйста, в контекстное меню копирования ссылки на статью. Очень часто нужно отослать кому то ссылку, а через браузер искать статью очень не удобно.