Я понял, у вас все сводится к тому, что в асинхронном мире Javascript'a вы боретесь с асинхронностью и хотите всё максимально синхронно, т.к. асинхронность конкретно вам мешает, вставляет палки в колеса и делает все не предсказуемым и не прогнозируемым.
По факту да) если я не могу гарантировать предсказуемость, как же я смогу пользователю гарантировать результат, по крайней мере эти две вещи кажутся связанными
Ну как бы никто вам не говорит плохой код написать невозможно если использовать Mobx, с таким же успехом можно while(true) {} воткнуть и потом обвинять в этом JS, потому что в JS так можно сделать. Это же абсурд, не так ли?
Тут идея чуть в другом, инструмент дает больше возможностей ошибиться. Это как использовать addEventListener('click', this.click), вместо onClick. Во первых, тебе надо сделать removeEventListener и быть уверенным что this.click, это тот же инстанс функции. Вроде все очевидно и не допустишь баг, но с onClick нет возможностей накосячить. А тут тебе в руки дают револьвер в видео потенциальных зависающих промисов и утечек памяти с реакциями которые незадиспоузились, и говорят не престрели детей главное))
Я использую EventEmitter вместо кучи reaction'ов, это банально проще контролировать и поддерживать. Но это не значит что я не использую reaction и autorun, ещё как использую, но нужно знать грань где лучше одно, а где другое.
Если бы поделились какими наработками, я был бы очень рад :)
все верно, у нас стоит такая задача на обсуждении, для более унифицированного формата картинок между платформами и так же это позволит расширить количество emoji
Нужен конкретный кейс с кодом и ссылочку на codesandbox где эти реакции не работают. Чтобы любой мог это проверить и убедится в этом. Иначе любой может говорить все что угодно, например что у него react не рэднерит тэг img какое же это дно.
Как меня просили я тезисно описал, и в случае если есть большой интерес это действительно можно в отдельную статью холиварную вынести обсуждение с примерами и прочим
То, что вы описали тут, это не проблемы Mobx, Redux и т.п. Быть программистом и разрабатывать архитектурные решения никто не отменял. Нельзя просто взять какой-то инструмент и он сам по себе работает вне зависимости от того какое у вас приложение, как оно устроена и какая у него логика работы.
Отчасти и да и нет. Дело в малом наличии бест практисов из-за малого комьюнити, в редаксе полно уже опробованных путей деления на модули пакеты и прочее, а тут надо набить все шишки
Для обновления ui и нужно использовать только @observable и @computed.
autorun и reaction это не прямые инструменты для обновления ui. И уж темболее никто вам не диктует и не навязывает использовать именно прям все реактивное при реактивное.
Есть ещё шикарная штука в MobX'e — when.
Я немного не к тому вел мысль, скорее хотел донести, если от mobx использовать, только 2 эти штуки для обновления UI, то нужен ли мне мобх вообще. Вот мы и пытаемся построить взаимодействие наших сторов тоже на реакциях, а не только UI обновлять.
А по поводу when, это не то чтобы шикарная штука, чуть не аккуратно расставишь их, и можешь наплодить кучу промисов, которые никогда не зарезолвятся
Вместо того чтобы думать и гадать что и как происходит и как все на все реагирует, может но это легко и быстро проверить. Вот пожалуйста исчерпывающий пример в котором явно все понятно:
Вы действительно хорошо покрыли базовый кейс. А что если у меня целое дерево реакций. К примеру, я в месенджере перехожу с одного чата в другой, я меняю id группы, мы реагируем на смену, переключаем чат, потом запускаем загрузку сообщений в истории, реагируем на загрузку истории, проверку все ли пользователи есть в мобх или надо догрузить, вычисляем положение скрола взависимости от сообщений, чтобы показать последнее прочитанное и там еще целый ряд реакций. Проблему уже в том, что мы не всегда можем продгнозировать, в каком порядке вызовутся реакции. Опять же я туманно поясняю, для этого я и говорил, что стоило бы в отдельную статью это выносить :)
— местами не работали реакции, когда прям вся команда ожидала реагирования. Мы начали изучать исходники, там код далеко не в лучшем состоянии и они ищут мантейнера
— пришлось очень много эксперементировать с архитектурой сторов. Т.к. месенджер очень связный, к примеру одно и тоже сообщение может быть в многих состояних: в самом чате, быть запиненым сверху, быть на редактировании в превью, быть в реплае, пересылаться через форвард и еще парочка кейсов. У них всех схожие и отличающиеся @computed свойства и action. Как это хэндлить? есть сырой месседж с бэка, а над ним базовый класс, а там по 2 слоя абстрации в зависимости от использования. В итоге изобретали свой велосипед архитектурный со сторами, вью моделями и шинами в общении и прочим
— если сильно полагаешься на реактивное програмирование, в виде постоянных реакций, очень тяжело дебажить код. А если в итоге начинаешь использовать только в @observable и @computed реактивность для обновления UI, стоит ли тогда вообще юзать для этого mobX
и прочие мелкие сомнения, про то что mobx это все таки черный ящик, которому ты должен доверять, в каком порядке он резолвит реакции, синхронно или асинхронно и все такое
По поводу поменять, да кроме редакса, альтернатив не слышал
Сейчас потестил обычный input добавил в iframe и кликнул вне iframe и фокус ушел. И звучит это логично. Ведь если бы на 1 странице внутри iframe был бы input и вне iframe еще один input. Тогда у нас была бы возможность поставить 2 каретки, и в какой из них печатался бы текст
не очень понимаю, как оно решит проблему с фокусом
Даже если и решит как то, то коммуникация с этим полем будет сложнее, этой же реализации работы с запоминанием каретки
1. Поразительно. А были конфликты, когда сотрудник отказывался от телефона? Вот не хочу, не буду, не стану и все тут. Или, например, кладет в тумбочку и по факту не пользуется?
Отличная статья, спасибо.
Пара вопросов:
1. Телефон выдавали только сотрудникам в зале или вообще всем? Слабо могу себе представить топ-менеджера не с айфоном :)
2. Стоимость телефона в ритейле порядка 8-9 тыс рублей, затраты довольно существенны. Как вы оцениваете их окупаемость?
3. Данная модель уже мало где продается — планируете ли менять и если да, то на какую?
Спасибо за ответы.
По факту да) если я не могу гарантировать предсказуемость, как же я смогу пользователю гарантировать результат, по крайней мере эти две вещи кажутся связанными
Тут идея чуть в другом, инструмент дает больше возможностей ошибиться. Это как использовать addEventListener('click', this.click), вместо onClick. Во первых, тебе надо сделать removeEventListener и быть уверенным что this.click, это тот же инстанс функции. Вроде все очевидно и не допустишь баг, но с onClick нет возможностей накосячить. А тут тебе в руки дают револьвер в видео потенциальных зависающих промисов и утечек памяти с реакциями которые незадиспоузились, и говорят не престрели детей главное))
Если бы поделились какими наработками, я был бы очень рад :)
Как меня просили я тезисно описал, и в случае если есть большой интерес это действительно можно в отдельную статью холиварную вынести обсуждение с примерами и прочим
Отчасти и да и нет. Дело в малом наличии бест практисов из-за малого комьюнити, в редаксе полно уже опробованных путей деления на модули пакеты и прочее, а тут надо набить все шишки
Я немного не к тому вел мысль, скорее хотел донести, если от mobx использовать, только 2 эти штуки для обновления UI, то нужен ли мне мобх вообще. Вот мы и пытаемся построить взаимодействие наших сторов тоже на реакциях, а не только UI обновлять.
А по поводу when, это не то чтобы шикарная штука, чуть не аккуратно расставишь их, и можешь наплодить кучу промисов, которые никогда не зарезолвятся
Вы действительно хорошо покрыли базовый кейс. А что если у меня целое дерево реакций. К примеру, я в месенджере перехожу с одного чата в другой, я меняю id группы, мы реагируем на смену, переключаем чат, потом запускаем загрузку сообщений в истории, реагируем на загрузку истории, проверку все ли пользователи есть в мобх или надо догрузить, вычисляем положение скрола взависимости от сообщений, чтобы показать последнее прочитанное и там еще целый ряд реакций. Проблему уже в том, что мы не всегда можем продгнозировать, в каком порядке вызовутся реакции. Опять же я туманно поясняю, для этого я и говорил, что стоило бы в отдельную статью это выносить :)
— пришлось очень много эксперементировать с архитектурой сторов. Т.к. месенджер очень связный, к примеру одно и тоже сообщение может быть в многих состояних: в самом чате, быть запиненым сверху, быть на редактировании в превью, быть в реплае, пересылаться через форвард и еще парочка кейсов. У них всех схожие и отличающиеся @computed свойства и action. Как это хэндлить? есть сырой месседж с бэка, а над ним базовый класс, а там по 2 слоя абстрации в зависимости от использования. В итоге изобретали свой велосипед архитектурный со сторами, вью моделями и шинами в общении и прочим
— если сильно полагаешься на реактивное програмирование, в виде постоянных реакций, очень тяжело дебажить код. А если в итоге начинаешь использовать только в @observable и @computed реактивность для обновления UI, стоит ли тогда вообще юзать для этого mobX
и прочие мелкие сомнения, про то что mobx это все таки черный ящик, которому ты должен доверять, в каком порядке он резолвит реакции, синхронно или асинхронно и все такое
По поводу поменять, да кроме редакса, альтернатив не слышал
Даже если и решит как то, то коммуникация с этим полем будет сложнее, этой же реализации работы с запоминанием каретки
2, 3 — Понятно, спасибо.
Пара вопросов:
1. Телефон выдавали только сотрудникам в зале или вообще всем? Слабо могу себе представить топ-менеджера не с айфоном :)
2. Стоимость телефона в ритейле порядка 8-9 тыс рублей, затраты довольно существенны. Как вы оцениваете их окупаемость?
3. Данная модель уже мало где продается — планируете ли менять и если да, то на какую?
Спасибо за ответы.