Comments 16
По поводу FlatList - может быть лучше с дизайнерами как-то решать такие ситуации, попросить их придумать элемент списка фиксированной высоты, чтобы работал getItemLayout и можно было делать скролл к нужной позиции?
Просто сложновато выглядит ваше решение.
Если бы можно было сделать элемент в чате фиксированной высоты, то мы бы использовали предложенный вами метод. Однако, к чатам это не применимо как бы дизайнер не старался - все элементы всегда будут иметь разные размеры в зависимости от длины текста. Так же, нужно учитывать, что существуют еще такие уникальные по длине элементы как голосовые сообщения, изображения и вложения.
Боже, какой кошмар то. "ведения блогов и комментирования публикаций коллег". "Чтобы они могли активнее участвовать в жизни компании"
Зачем все это??? Зачем активно участвовать в жизни компании? И так понятно что ТОПы будут нести ересь, писать всякую ахинею типа "мы команда, мы должны напрячься, затянуть пояса" и все в таком же духе, а все остальные ниже рангом будут восхвалять, анонимные опросы в корп.чате с вопросом что вас не устраивает в компании?
И вот эта фраза "есть неплохие готовые платформы вроде rocket.chat." наверное должна заканчиваться "но у них всех есть фатальный недостаток".
>>Им приложение помогает собирать фидбек о функциях, а также краудсорсить новые идеи.
Рукалицоджипег, почему идеи а не "фичи"?
Здравствуйте!
Ответим так) Мы в любом случае большую часть своей жизни проводим на рабочем месте и для многих людей с развитыми социальными функциями (не для всех конечно) важно ощущать себя частью команды, делиться мнениями и общаться с коллегами. В приложении негативом сотрудники тоже очень активно, кстати, делятся. В "Перчатке" можно предложить какое-то нововведение напрямую топ-менеджеру, и если оно эффективное и экономически обоснованное, оно будет реализовано, есть такие кейсы.
В компаниях с развитой корпоративной культурой всегда активные блоги, иногда даже два — анонимный и открытый — а называются они по-разному (Перчатка, Этушка или как-то ещё).
Я понял, спасибо. Можете личное мнение написать в "Личку"?
Второй вопрос. Почему от одной компании ПО в маркете разное. Имеется в виду, как Пятерочка/Перекресток/Около и так далее? Просто странно как то. Пилить одно приложение проще, же. Я понимаю набор товаров разный и бонусы разные, ну так как то начать в эту сторону что то делать.
P.S. И да, у жены так и не получилось заказать ни через одно. В приложении "Перекрёсток" бонусная карта не прикрепилась, потому что у неё нет CVV (оператор предложил сходить и купить новую карту, зачем тогда заказывать доставку если я могу сходить и сам?). В Пятерочке нельзя было выбрать место доставки, так как ранее выбирали другое местоположение (в другом городе делали заказ) и оно видимо как то закрепилось за номером (оператор так и не смог помочь и не понимал почему не работает) и так далее.
Лучше бы вы принудили сотрудников следить за ценниками, каждый день косяки на кассах и как нестрано все в пользу магазина, ниразу не ошиблись в меньшую сторону.
А вы использовали react-navigation или react-native-navigation от wix? И что использовали для BottomSheets (если использовали)?
А что вы думаете про перспективы redux-saga? Автор похоже что забросил проект, я думаю про перевод всей асинхронной логики на хуки.
Мы используем react-navigation - эта самая популярная библиотека + она на 100% закрывает все наши потребности в плане навигации по приложению. Можно было бы поэкспериментировать с react-native-navigation, но при разработки MVP даже не вставал вопрос о выборе библиотеке навигации. Для различных вариацией BottomSheets мы использовали три разных библиотеки react-native-scroll-bottom-sheet, reanimated-bottom-sheet, reanimated-bottom-sheet. У каждой библиотеки имеются свои возможности и ограничения - функционала очень много и не везде удалось использовать одну и ту же библиотеку. Возможно, в будущем, при рефакторинге, нам удасться сократить число библиотек для работы с BottomSheet в проекте.Идея с переносом асинхронной логике в хуки сама по себе интересная. Нам не нравится, что redux-saga обязывает результат запроса сначала положить в глобальное состояние приложения, а только потом как-то реагировать в компоненте/скрине. Иногда (довольно часто) нужно просто async/await функцию вызвать прямо из компонента. Мы использовали в проекте redux-saga по причине того, что этот подход достаточно давно известен и хорошо себя зарекомендовал. Однако, в последнее время, мы присматриваемся к переносу части логики связанной с чатами на MobX, чтобы уменьшить количество бойлерплейта и снизить сложность кода бизнес логики. За лето мы написали на MobX веб версию чатов и подумали, что будет хорошей идеей унифицировать эту часть логики для всех платформ, чтобы не писать ее дважды
За две недели после запуска в «Перчатке» зарегистрировалась четверть сотрудников «Перекрестка», каждый день в приложение заходит 20% из них, и эти показатели растут.
дайте угадаю (я не сотрудник x5 просто видел как это в других делается конторах)
'мы зарегистрировали в приложении всех сотрудников автоматически'
'заставляем всех туда заходить потому что в томже приложении рассылаем важную инфу, например квиточки по ЗП или объявления которые раньше обязаны прочитать все но теперь в старом месте они недоступны'
радуемся-удивляемся-хлопаем, у нас за неделю 80% персонала начало пользоваться!!! 20% каждый день пользуются!!! ничёсе удача 11!!! какой удобный инструмент!
==
ох…
вообще меня удивляет что сейчас на дворе 21 год, а с первой такой системой я столкнулся в российской дочке забугорной корпорации в 14 году… и вообще по мере работы наблюдал как в разных конторах 'мы разработали инновационный портал для сотрудников с соцсетями'… чот вы долго до этого шли.
А еще вопрос - как вы связываете SQLLite и React? Через контекст? Или просто через какой-то сервис читаете нужные данные в state нужного компонента?
Как и для чего мы сделали «Перчатку» — приложение для сотрудников «Перекрёстка» с элементами соцсети