/me пожимает плечами

@fomkin , Add todo должно работать сейчас?

Да. Вниз поскролить надо.

На прошлой работе примерно так и делали с первым плеем. Шаблоны генерал плеевский генератор и через xmlhttprequest обновляли кусок на клиенте

Не писать JavaScript можно и с scalajs сейчас

@fomkin суперкул

А то что клиент лёгкий выходит - это хорошо

scalajs это да. но это все равно js. это отдельное приложение. между сервером и клиентом надо выстраивать диалог.

здесь ты тудушку принял и сразу же ее в базу записал.

я хз, в чем крутость - поменяли аякс запрос рендеренного html на запрос через ws

или из очереди новое сообщение принял и сразу же его клиенту.

ну перед записью в базу все ранво клиент отправил на сервер что-то

мне кажется джаваскрипт штуки лучше писать на джаваскрипт, не? Есть ощущение что идея оборачивать жс во что бы то ни было не жизнеспособна, сколько бы ни пробовали.

Это не js. Вообще ничего на клиенте не делается.

При этом браузер получает не отрепдерений шаблон, а вызовы над DOM.

на клиенте чистый хтмл, как без жс то?

То есть когда ты кликаешь на чекбокс, тебе приходит, мол у такой-то ноды checked=true, а здесь <span> на <strike> замени.

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

на клиенте чистый хтмл, как без жс то?

Это машинерия. Он один раз написан и его трогать не надо.

мне кажется джаваскрипт штуки лучше писать на джаваскрипт, не? Есть ощущение что идея оборачивать жс во что бы то ни было не жизнеспособна, сколько бы ни пробовали.

Интерфейс - да, логика - почему бы нет?

логика чего?

@rockjam если сеть теряется то да, все плохо. но большие изменения UI - сколько угодно.

Клиентская логика

@rockjam но если сеть теряется, то это в любом случае все плохо, если приложение не сделано в offline first идеологии.

mvvm с js как-то проще покатит, нет?

mvvm с js как-то проще покатит, нет?

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

Потом из очереди получил событие. Пошел сразу на клиенте обновил.

10 строчками кода можно сделать то, для чего сейчас городят городухи из 1000 строк.

Мдя...

На мой вкус ахеренно

Единственное, что надо не свалиться в Listener Hell

А так интересно

Единственное, что надо не свалиться в Listener Hell

А что имеется в виду? Открытые соединения?

Весь UI построен пока на стандартных событиях

listen('click'); listen('mousedown'); listen('mouseup');

Ну вот когда компонет будет много их разруливать станет головозгно

*головомозгдно

А, это. Они слушаются на корне. То есть добавляются один раз для все приложения.

это понятно

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

*приложениях

И кстати не оч понятно как делать реюз компонет

В функцию выносить.

Но тогда у тебя нет контекста для распознования одних и техже событий из разных мест

Хотя может здесь получится ок так как все события получаются последовательно

А функции компоновать во что-то типа ML-овских функторов. Параметризуемые модули.

В нашем случае видимо классы.

Надо пробовать

Но тогда у тебя нет контекста для распознования одних и техже событий из разных мест

"Навешивание" событий идемпотентное. Это просто узел в виртуальном DOM. Если узел присутствует, то реакция на событие есть, если нет, то и реакции нет. Но вообще дизайн событий тебует переработки. Мне не очень нравится как сейчас плучилось.

Тем не менее Посздравляю получилась оригинальная идея!

Ура!

Я честно говоря не знаю как на JS но в толстых клиентах это решалось Event Bus

Тут по сути все большой EventBus. Когда происходит событие мы ничего не может сделать с DOM. Он иммутабельный. Но мы можем сгенерить экшн. Тогда будет вызвана функция, которая смержит текущий стейт с экшном, после чего это стет будет отдан на рендеринг, сгенерится новый иммутабельный DOM, сделается дифф со старым, список изменений улетит на клиент.

Так сейчас на фронте модно делать. Очень по-хипстерси.

Это я уловил еще в первый раз когда ты рассказывал;)

В общем еще пара тройка летних выходных и можно будет выкладывать на гитхабчик, что бы все могли попробовать :)

Давай Жги ;)

Леша молодец :) ребят, тема на самом деле офигенная. У такого подхода очень крутые плюшки из коробки: офигенный дебагинг, сбор статистики (куда юзеры кликают, в какой последовательности). А еще можно очень легко UI-тесты писать. Представьте, есть требование: после нажатия на "Купить", должна появиться корзина. Так вот эти тесты можно писать на сервере (без селениума). Понятно, что селениумные тесты все равно нужны, но они выполняются на порядок дольше, пирамида Кона, туды-сюды

есть четкое ощущение, что те кто этим восторгается просто никогда не писал подобный ui)

писал, и ui тесты на моке с кармой писал :)

Строго говоря "подобного" нет

ну да, подобного не видел. Но как бывший фронтендер идею могу оценить

да вы издеваетесь чтоли, рендерим хтмл на бекенде - вот же новизна, ниразу не видел)

Неее вот рендерить на бекенде, этого полно

ну а тут разве не это?)

ERROR: S client not available

ты ничего не понял :(

рендер всего + частичный рендеринг)

тут не рендерится ui на бэке

Дьявол в деталях. Статическая страница против динамической, pull против push.

тут не рендерится ui на бэке

Да, как такового "рендеринга" на сервере не происходит. Сервер удаленно управляет DOM на стороне клиента.

ну вот по вебсокету то что летит - даже если это не зарендеренный ui, а команды на манипуляцию c ui - я особой разницы не вижу, кроме что потом опупеешь это писать)

Что писать?

ну а что можно с деревом выполнить?

вроде у N2O эрланговского такая же идея

пушать с сервера куски по ws

vaadin то же делает

вроде у N2O эрланговского такая же идея

Да. Вдохновляюсь N2O и React/Redux.

vaadin то же делает

Не совсем. Ваадин это вполне себе клиент-сайд компоненты на GWT, которые управляются с сервера через RPC. Каждый компонент это вполне себе такой серьезный кусок джаваскрипта и некий сетевой интерфейс к нему. Хотя возможно за 5 лет там все поменялось, но вроде бы было именно так.

Ну и самое главное, что ваадин это ООП в плохом смысле слова. Императивная лапша и тысячи строк бойлерплейта. Опять же по инфе 5-летней давности.

да любая поделка с созданная с целью "не писать на js" придет в ужасное состояние при попытке покрыть все кейсы

да любая поделка с созданная с целью "не писать на js" придет в ужасное состояние при попытке покрыть все кейсы

Тут даже не "не писать на жс", а "не писать фронтэнд как отдельную программу". Для "не писать на жс" есть масса замечательных вещей. Тот же Scala.js, который отлично работает и покрывает все что может быть в JS.

да любая поделка с созданная с целью "не писать на js" придет в ужасное состояние при попытке покрыть все кейсы

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

если не писать фронтенд как отдельную программу, то с ростом размера проекта этот путь гораздо быстрее приведет к суицидальным мыслям

Почему?

больше связности и меньше управлямости

Кстати, на счет scala.js есть интересный вопрос: например я хочу обратиться к свойству объекта document, которого нет в интерфейсе scala.js. Как мне это правильно сделать?

а потом начнется жижа размазнная между сервером и клиентом

ну если только это не идеальный случай)

Кстати, на счет scala.js есть интересный вопрос: например я хочу обратиться к свойству объекта document, которого нет в интерфейсе scala.js. Как мне это правильно сделать?

scala.scalajs.js.Dynamic.global

а потом начнется жижа размазнная между сервером и клиентом

Ну ок.

@fomkin , смотрю как завараженный на этот код. немного не понял, вот допустим такой случай : есть несколько элементов в DOM которые содержат одну и ту же инфу. с помощью ажакс я обычно б такое обновил сразу в одном месте. немного не могу представить, как здесь такое сделать?

@fomkin , смотрю как завараженный на этот код. немного не понял, вот допустим такой случай : есть несколько элементов в DOM которые содержат одну и ту же инфу. с помощью ажакс я обычно б такое обновил сразу в одном месте. немного не могу представить, как здесь такое сделать?

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

да, так

все верно

Окей, сейчас расскажу.

можно сделать прослойки, одна дает данные, другая на них биндится и отдает что и как нужно на фронт, например =)