Обновить
53

Пользователь

6
Подписчики
Отправить сообщение
Но ведь в Лондоне левостороннее движение, а люди на эскалаторе стоят справа. Мне почему-то казалось, что стоящие справа люди в нашем метро — следствие правостороннего движения.
А потом жаренные ракообразные идут на корм
А кроме опроса счётчиков в Академе есть столь же масштабные централизированные IT системы?
С «ручным» парсингом прилетевшего обновления — в целом понятно.
Мне почему-то казалось, что есть готовая библиотека с магией, которая сделает за меня вот эту работу:

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


а так же в другую сторону.

Обновилось, например, на каком-то из клиентов firstname, а об этом сразу узнал сервер и потом все клиенты. сами, без дополнительных телодвижений. А потом эти изменения ещё и отобразились в шаблонах. Сами.

Походу, такая магия есть только у Метеора. У остальных — только реактивные переменные.
Вот фулл-стек решение не всегда плохо, мне кажется. Когда нужно на существующий бэкенд добавить реактивности, тогда метеор «не очень». Но когда делается что-то с нуля — ощущается некая разница в сложности подхода.

с одной стороны, у нас есть метеор, который в целом работает.
с другой стороны «небольшой стек» — Java-GraphQL-Apollo-MobX-React который ещё нужно суметь запустить. Ведь в каждом компоненте из списка есть какой-то нюанс.

мне кажется, что порог входа во втором случае на порядок выше, чем в первом. И не понятно почему так. Почему нет более простого решения. Может быть оно никому и не нужно?

На сколько я понял, работая с метеором, в нём нет возможности напрямую сделать реактивную переменную/поле — реактивность завязана на Монгу.
В длинном стеке же можно сделать реактивную переменную, но ценой довольно слоистой архитектуры. Возможно, из-за этого отличия и получается такая разница в сложности…
Благодарю, попробую копнуть в сторону Apollo.

А за универсальность… Ведь у Метеора получилось довольно универсально, через синхронизацию Монги
Так я и не спрашиваю за эту библиотеку. Я спрашиваю за то, что использовать совместно с ней.
Сорри, я немного неправильно понял — подумалось, что это про JSON, полученный через Ajax.

Мне нужна именно магия для реактивности.
Если она будет работать через JSON, прилетающий по весокету — будет отлично.
Наверное, я немного плаваю в терминологии и плохо вопрошаю.

Вот есть куча @observable. Некоторые из них я хочу синхронизировать с сервером. Чтобы при изменении на клиенте они тут же отсылались на сервер. И в обратную сторону — при изменении на сервере обновлялся клиент.

В вышеупомянутом LogStore это делается руками. Вот есть ли какая-то библиотека, которая автоматизировала бы процесс синхронизации стейтов между сервером и клиентом?
а если не JSON, но Вебсокеты? Есть ли готовые обёртки для реактивности?
Понял, благодарю.

А если мне хочется реактивности, подобной Метеору, что из готового взять в дополнении к mobx+react?
Чтобы при изменении данных на сервере все клиенты видели их сразу.
Как я понимаю, нужна какая-то обёртка над вебсокетами. Что со стороны фронтенда, что со стороны бэкенда.
Глупый, наверное вопрос, но можно ли использовать subj в связке с бэкендом на яве?
Если да, то как?
Если нет, то есть ли аналоги, которые можно?
А кто что пьет, отказавшись от чая/кофе?
Воду/Сок/Смешная третья опция?
Накидайте интересных идей, а?
И ссылка на обзор с доработками: http://uncle-sem.livejournal.com/152921.html
Модифицируя eeprom можно настроить некоторые вещи под себя
И, чтобы два раза не вставать, есть ещё один список https://github.com/A-gambit/awesome-telegram-chats
Анархическая электроника — Чат про ардуино

Вот и нет. это сателлит к ru_electronics для дискуссионных тем.

а вообще по радио немного больше групп: https://t.me/ru_electronics_feed/24
Электроника и схемы подключения, от 30 000

ардуино?
С одной стороны как-бы «не очень». А с другой — из-за этого, вполне возможно, намного меньше неадекватов в группах.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность