Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
А что за мессенджер вообще планируется?
Насколько он будет зависим от единого центра?
Какое шифрование там планируется, и, в случае e2e, какие будут способы проверить, не произошла ли атака mitm?
Будет ли он децентрализованным (например, федеративным)?
Будет ли возможность поднять свой сервер и его клиентам общаться с клиентами на других серверах?
Какие вообще отличия от того же джаббера, например?
Насколько он будет зависим от единого центра?
Какое шифрование там планируется, и, в случае e2e, какие будут способы проверить, не произошла ли атака mitm?
Будет ли он децентрализованным (например, федеративным)?
Будет ли возможность поднять свой сервер и его клиентам общаться с клиентами на других серверах?
Какие вообще отличия от того же джаббера, например?
Месседжер не планируется, а уже давно работает. Вот только не нужен он никому, кроме МЛМ-адептов Gem4me, ждущих уже не один год, что их месседжер убьёт все Ватсапы с Телеграмами. И вот тогда они (адепты) заживут ваще шикарно. Протокол закрыт, код клиента закрыт. По факту — это простая финансовая пирамида. Ниже добрый человек скинул ссылки.
Все эти проблемы с потерей фокуса разве не решаются если поле ввода поместить в iframe?
не очень понимаю, как оно решит проблему с фокусом
Даже если и решит как то, то коммуникация с этим полем будет сложнее, этой же реализации работы с запоминанием каретки
Даже если и решит как то, то коммуникация с этим полем будет сложнее, этой же реализации работы с запоминанием каретки
Можно тезисно про mobx, чем не устроил и если если переезжать, то на что?
— местами не работали реакции, когда прям вся команда ожидала реагирования. Мы начали изучать исходники, там код далеко не в лучшем состоянии и они ищут мантейнера
— пришлось очень много эксперементировать с архитектурой сторов. Т.к. месенджер очень связный, к примеру одно и тоже сообщение может быть в многих состояних: в самом чате, быть запиненым сверху, быть на редактировании в превью, быть в реплае, пересылаться через форвард и еще парочка кейсов. У них всех схожие и отличающиеся @computed свойства и action. Как это хэндлить? есть сырой месседж с бэка, а над ним базовый класс, а там по 2 слоя абстрации в зависимости от использования. В итоге изобретали свой велосипед архитектурный со сторами, вью моделями и шинами в общении и прочим
— если сильно полагаешься на реактивное програмирование, в виде постоянных реакций, очень тяжело дебажить код. А если в итоге начинаешь использовать только в @observable и @computed реактивность для обновления UI, стоит ли тогда вообще юзать для этого mobX
и прочие мелкие сомнения, про то что mobx это все таки черный ящик, которому ты должен доверять, в каком порядке он резолвит реакции, синхронно или асинхронно и все такое
По поводу поменять, да кроме редакса, альтернатив не слышал
— пришлось очень много эксперементировать с архитектурой сторов. Т.к. месенджер очень связный, к примеру одно и тоже сообщение может быть в многих состояних: в самом чате, быть запиненым сверху, быть на редактировании в превью, быть в реплае, пересылаться через форвард и еще парочка кейсов. У них всех схожие и отличающиеся @computed свойства и action. Как это хэндлить? есть сырой месседж с бэка, а над ним базовый класс, а там по 2 слоя абстрации в зависимости от использования. В итоге изобретали свой велосипед архитектурный со сторами, вью моделями и шинами в общении и прочим
— если сильно полагаешься на реактивное програмирование, в виде постоянных реакций, очень тяжело дебажить код. А если в итоге начинаешь использовать только в @observable и @computed реактивность для обновления UI, стоит ли тогда вообще юзать для этого mobX
и прочие мелкие сомнения, про то что mobx это все таки черный ящик, которому ты должен доверять, в каком порядке он резолвит реакции, синхронно или асинхронно и все такое
По поводу поменять, да кроме редакса, альтернатив не слышал
местами не работали реакции
Нужен конкретный кейс с кодом и ссылочку на codesandbox где эти реакции не работают. Чтобы любой мог это проверить и убедится в этом. Иначе любой может говорить все что угодно, например что у него react не рэднерит тэг img какое же это дно.
пришлось очень много эксперементировать с архитектурой сторов
То, что вы описали тут, это не проблемы Mobx, Redux и т.п. Быть программистом и разрабатывать архитектурные решения никто не отменял. Нельзя просто взять какой-то инструмент и он сам по себе работает вне зависимости от того какое у вас приложение, как оно устроена и какая у него логика работы.
если сильно полагаешься на реактивное програмирование, в виде постоянных реакций, очень тяжело дебажить код. А если в итоге начинаешь использовать только в @observable и @computed реактивность для обновления UI, стоит ли тогда вообще юзать для этого mobX
Для обновления ui и нужно использовать только @observable и @computed.
autorun и reaction это не прямые инструменты для обновления ui. И уж темболее никто вам не диктует и не навязывает использовать именно прям все реактивное при реактивное.
Есть ещё шикарная штука в MobX'e — when.
fetchData = async () => {
// Мы не можем выполнить эту функция и дернуть АПИ, потому что у нас есть зависимость, после получения данных от которой мы можем дергать нужную нам АПИшку
await when(() => myDependency.dataLoaded === true);
const someIds = myDependency.items.map(item => item.id);
await apiRequest.data({ids: someIds });
// ...
}
и прочие мелкие сомнения, про то что mobx это все таки черный ящик, которому ты должен доверять, в каком порядке он резолвит реакции, синхронно или асинхронно и все такое
Нет никакой магии
mobx5 — ES6 Proxy
mobx4 — getters / setters
Вместо того чтобы думать и гадать что и как происходит и как все на все реагирует, может но это легко и быстро проверить. Вот пожалуйста исчерпывающий пример в котором явно все понятно:
codesandbox.io/s/zen-surf-g9r9t?file=/src/App.tsx
Посмотрите код, посмотрите консоль, по нажимаете на кнопочку и снова посмотрите в консоль. После этого раскомментируйте конфигурацию реакций
setTimeout(() => {
configure({
reactionScheduler: f => {
setTimeout(f, 1);
}
});
}, 1);
вот эту, обновите страницу, повторите все действия и посмотрите, что результат уже стал совсем другой, просто небом и земля, теперь все батчится автоматом и реакции все асинхронные и нет нужны в action/runInAction. Далее уберите обертку из setTimeout в которую завернута конфигурация и повторите все, обратите внимание на самый верх вывода консоли, в этом случае даже в самом старте и инициализации кода уже будут асинхронные реакции и autorun уже сработает не 2 раза подряд вначале, а забатчится и сработает 1 раз.
Теперь вы понимаете как именно это работает и что происходит при тех или иных манипуляциях.
Лично я использую такой конфиг реакций (завернутый в setTimeout, т.к. при ините мне нужно чтобы реакции были синхронными, а далее в ходе работы приложения уже синхронные не нужны), чтобы все синхронные изменения батчились автоматом и потом уже асинхронно вызывались реакции.
Нужен конкретный кейс с кодом и ссылочку на codesandbox где эти реакции не работают. Чтобы любой мог это проверить и убедится в этом. Иначе любой может говорить все что угодно, например что у него react не рэднерит тэг img какое же это дно.
Как меня просили я тезисно описал, и в случае если есть большой интерес это действительно можно в отдельную статью холиварную вынести обсуждение с примерами и прочим
То, что вы описали тут, это не проблемы Mobx, Redux и т.п. Быть программистом и разрабатывать архитектурные решения никто не отменял. Нельзя просто взять какой-то инструмент и он сам по себе работает вне зависимости от того какое у вас приложение, как оно устроена и какая у него логика работы.
Отчасти и да и нет. Дело в малом наличии бест практисов из-за малого комьюнити, в редаксе полно уже опробованных путей деления на модули пакеты и прочее, а тут надо набить все шишки
Для обновления ui и нужно использовать только @observable и @computed.
autorun и reaction это не прямые инструменты для обновления ui. И уж темболее никто вам не диктует и не навязывает использовать именно прям все реактивное при реактивное.
Есть ещё шикарная штука в MobX'e — when.
Я немного не к тому вел мысль, скорее хотел донести, если от mobx использовать, только 2 эти штуки для обновления UI, то нужен ли мне мобх вообще. Вот мы и пытаемся построить взаимодействие наших сторов тоже на реакциях, а не только UI обновлять.
А по поводу when, это не то чтобы шикарная штука, чуть не аккуратно расставишь их, и можешь наплодить кучу промисов, которые никогда не зарезолвятся
Вместо того чтобы думать и гадать что и как происходит и как все на все реагирует, может но это легко и быстро проверить. Вот пожалуйста исчерпывающий пример в котором явно все понятно:
Вы действительно хорошо покрыли базовый кейс. А что если у меня целое дерево реакций. К примеру, я в месенджере перехожу с одного чата в другой, я меняю id группы, мы реагируем на смену, переключаем чат, потом запускаем загрузку сообщений в истории, реагируем на загрузку истории, проверку все ли пользователи есть в мобх или надо догрузить, вычисляем положение скрола взависимости от сообщений, чтобы показать последнее прочитанное и там еще целый ряд реакций. Проблему уже в том, что мы не всегда можем продгнозировать, в каком порядке вызовутся реакции. Опять же я туманно поясняю, для этого я и говорил, что стоило бы в отдельную статью это выносить :)
Я понял, у вас все сводится к тому, что в асинхронном мире Javascript'a вы боретесь с асинхронностью и хотите всё максимально синхронно, т.к. асинхронность конкретно вам мешает, вставляет палки в колеса и делает все не предсказуемым и не прогнозируемым.
Вам не нужна эта синхронность, это не Javascript way. В противном случае вы выбрали не тот язык, для синхронности идеально подходит PHP, там все чисто сверху вниз и на каждый запрос создается изолированный процесс. Да PHP можно использовать асинхронно, но это мы затрагивать не будем.
Javascript особенно в браузере это вообще не про синхронность, здесь асинхронно всё, вплоть до рендера страницы самим браузером. Поэтому записывать в минусы то, что работает не синхронно, должно быть записано в минусы тому, кто считает что это минус.
Ну как бы никто вам не говорит плохой код написать невозможно если использовать Mobx, с таким же успехом можно while(true) {} воткнуть и потом обвинять в этом JS, потому что в JS так можно сделать. Это же абсурд, не так ли?
Опять же, это сугубо ваша проблема, а не проблема инструмента. Если вам не хватило дня на пролистывание документации по mobx и экспериментов на подобии тех, что я вам уже скинул по ссылке, то вам нужно этим обязательно заняться.
Если не получается рисовать картины, разве в этом виноват холст или кисточка? Особенно когда другие люди по соседству замечательно рисуют на таких же холстах и такими же кисточками, и у них получаются замечательные картины.
Codesandbox знаете где искать, набросали там примеры которые у вас не работают, скинули сюда ссылочку, а я и другие люди с удовольствием на них поглядим.
Ну если не нужен, то удачи с тонной лапшекода и говнокода гарантируемо идущего с этим в довесок для всех этих дел при использовании голого реакта или реакта + редакса, посмотрим как вы будете кайфовать тогда =)
Да хоть миллион, порядок реакций не важен, JS асинхронный и проектироваться он должен асинхронно и никак иначе. Если вам кровь из носа нужно откуда-то испускать команды, чтобы синхронно в другом месте что либо делалось, то банальный EventEmitter к вашим услугам, никто не запрещает всё это совмещать. Я использую EventEmitter вместо кучи reaction'ов, это банально проще контролировать и поддерживать. Но это не значит что я не использую reaction и autorun, ещё как использую, но нужно знать грань где лучше одно, а где другое.
Вам не нужна эта синхронность, это не Javascript way. В противном случае вы выбрали не тот язык, для синхронности идеально подходит PHP, там все чисто сверху вниз и на каждый запрос создается изолированный процесс. Да PHP можно использовать асинхронно, но это мы затрагивать не будем.
Javascript особенно в браузере это вообще не про синхронность, здесь асинхронно всё, вплоть до рендера страницы самим браузером. Поэтому записывать в минусы то, что работает не синхронно, должно быть записано в минусы тому, кто считает что это минус.
А по поводу when, это не то чтобы шикарная штука, чуть не аккуратно расставишь их, и можешь наплодить кучу промисов, которые никогда не зарезолвятся
Ну как бы никто вам не говорит плохой код написать невозможно если использовать Mobx, с таким же успехом можно while(true) {} воткнуть и потом обвинять в этом JS, потому что в JS так можно сделать. Это же абсурд, не так ли?
Дело в малом наличии бест практисов из-за малого комьюнити, в редаксе полно уже опробованных путей деления на модули пакеты и прочее, а тут надо набить все шишки
Опять же, это сугубо ваша проблема, а не проблема инструмента. Если вам не хватило дня на пролистывание документации по mobx и экспериментов на подобии тех, что я вам уже скинул по ссылке, то вам нужно этим обязательно заняться.
Если не получается рисовать картины, разве в этом виноват холст или кисточка? Особенно когда другие люди по соседству замечательно рисуют на таких же холстах и такими же кисточками, и у них получаются замечательные картины.
Как меня просили я тезисно описал, и в случае если есть большой интерес это действительно можно в отдельную статью холиварную вынести обсуждение с примерами и прочим
Codesandbox знаете где искать, набросали там примеры которые у вас не работают, скинули сюда ссылочку, а я и другие люди с удовольствием на них поглядим.
Я немного не к тому вел мысль, скорее хотел донести, если от mobx использовать, только 2 эти штуки для обновления UI, то нужен ли мне мобх вообще.
Ну если не нужен, то удачи с тонной лапшекода и говнокода гарантируемо идущего с этим в довесок для всех этих дел при использовании голого реакта или реакта + редакса, посмотрим как вы будете кайфовать тогда =)
А что если у меня целое дерево реакций.
…
Проблему уже в том, что мы не всегда можем продгнозировать, в каком порядке вызовутся реакции.
Да хоть миллион, порядок реакций не важен, JS асинхронный и проектироваться он должен асинхронно и никак иначе. Если вам кровь из носа нужно откуда-то испускать команды, чтобы синхронно в другом месте что либо делалось, то банальный EventEmitter к вашим услугам, никто не запрещает всё это совмещать. Я использую EventEmitter вместо кучи reaction'ов, это банально проще контролировать и поддерживать. Но это не значит что я не использую reaction и autorun, ещё как использую, но нужно знать грань где лучше одно, а где другое.
Я понял, у вас все сводится к тому, что в асинхронном мире Javascript'a вы боретесь с асинхронностью и хотите всё максимально синхронно, т.к. асинхронность конкретно вам мешает, вставляет палки в колеса и делает все не предсказуемым и не прогнозируемым.
По факту да) если я не могу гарантировать предсказуемость, как же я смогу пользователю гарантировать результат, по крайней мере эти две вещи кажутся связанными
Ну как бы никто вам не говорит плохой код написать невозможно если использовать Mobx, с таким же успехом можно while(true) {} воткнуть и потом обвинять в этом JS, потому что в JS так можно сделать. Это же абсурд, не так ли?
Тут идея чуть в другом, инструмент дает больше возможностей ошибиться. Это как использовать addEventListener('click', this.click), вместо onClick. Во первых, тебе надо сделать removeEventListener и быть уверенным что this.click, это тот же инстанс функции. Вроде все очевидно и не допустишь баг, но с onClick нет возможностей накосячить. А тут тебе в руки дают револьвер в видео потенциальных зависающих промисов и утечек памяти с реакциями которые незадиспоузились, и говорят не престрели детей главное))
Я использую EventEmitter вместо кучи reaction'ов, это банально проще контролировать и поддерживать. Но это не значит что я не использую reaction и autorun, ещё как использую, но нужно знать грань где лучше одно, а где другое.
Если бы поделились какими наработками, я был бы очень рад :)
Если бы поделились какими наработками, я был бы очень рад :)
На здоровье)
codesandbox.io/s/dreamy-cartwright-7ncgx?file=/src/App.tsx
По факту да) если я не могу гарантировать предсказуемость, как же я смогу пользователю гарантировать результат, по крайней мере эти две вещи кажутся связанными
Ну смотрите, синхронность в UI без батчинга изменений и минимального кол-ва рендеров это анти-производительность, анти-паттерн, анти-{дальше придумаете сами}, даже голый реакт против этого и не дает это вам сделать просто так, вот пожалуйста:
codesandbox.io/s/friendly-hoover-67l7j?file=/src/App.tsx
Это абсолютно логично и правильно когда UI ждет пока все синхронные изменения выполнятся, чтобы так сказать получить финальное состояние на текущий момент и уже только после этого инициализировать рендер.
И есть третий случай. А что, если пользователь мышкой поставил каретку на определенную позицию в тексте?
А что если пользователь на iPadOS и каретку перетаскивает пальцем?
В эмодзях на Windows нет флагов стран (точнее в качестве них используются пары букв), поэтому добавьте ещё один пункт в ТЗ:
— Заменять текстовые эмодзи на элементы <img /> с изображениями-полифилами.
Благодарю за подробную статью и разбор
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы разрабатывали поле ввода новых сообщений в нашем мессенджере (Gem4me)