Информация
- В рейтинге
- 600-й
- Откуда
- Нижний Новгород, Нижегородская обл., Россия
- Работает в
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Фронтенд разработчик
Ведущий
JavaScript
React
TypeScript
HTML
CSS
SCSS
Веб-разработка
Адаптивная верстка
MobX
Насколько я знаю лишнего рендера не будет, потому что 18+ реакт будет автоматически батчить такие апдейты, но mobx реакции вызовутся два раза да
Привет, все зависит от того как писать !
У нас тоже были утечки памяти, но они были связаны с тем, что в некоторые reaction не были прикинуты сигналы на удаление
В общем утечек памяти в самом observer я с уверенностью могу сказать что нет, потому что у нас вкладка с фронтом (два фронта: главное приложение + iframe приложение внутри) после работы GC занимает память 84-86 МB
Важный момент: мы не используем React хуки вовсе в слое представления для БЛ (кроме юайных хуков вроде useTable), поэтому прокси не отправляются в массив зависимостей в хуках, как и не используются в замыканиях в хуках. Это может быть связано с утечками
Да, спасибо за внимательность, допишу об этом моменте в статье!
Этот варнинг убирается через настройку
Привет!
В данный момент мы разрабатываем чисто CSR апку, но на гитхабе у меня можно найти пример работы MobX в режиме SSR (GOZON), а также да, как вы упомянули, можно использовать mobx-tanstack-query + написать некий стор который имеет базовое состояние-слепок стейта
Что то кнопка зарегистрироваться не работает
Получается если компонент будет переиспользоваться в двух+ фичах, то ему место в общей components? Это же тот же хаос создастся:)
Честно скажу выглядит очень красиво и аккуратно!
На счёт клиента для фронта увидел такой код, не совсем понял откуда берется api, предполагаю что это целое апи из бэка
Если это так, тогда вопрос как обстоят дела с тришейкингом? Не потянется ли в бандл весь api для того чтобы работала типизация на фронте?
Нейростатья + реклама своей платформы 👍
Интересно сравнить что быстрее neovim или zed
Очень сочный и полезный дайджест, спасибо!
Тот же пример на "всеми" нелюбимом стейт менеджере...
Причём как правило достаточно использовать observer и computed.
И никаких useShallow :)
Взяли в прод, спасибо!
Ну и как подметили выше - отображение всего содержимого повышает когнитивную нагрузку, будет разбегаться глаза
Тогда не представляю как должно быть "правильно" для этого элемента ввода, с точки зрения UI/UX, потому что растянуть список по высоте до размеров экрана это неполноценное решение, которое все равно заставит скроллить, а отображение огромного модального окна чтобы выбрать эти элементы тоже, на мой взгляд, странно
В статье не хватает рецепта свиных крылышек
Так это разве не основной их рабочий класс ? Выпускники из вузов
Да! Нужен конкретный сценарий чтобы подтвердить смысл выпадающего списка с отображением максимально допустимого в экран ))) количества элементов
А точно ли отображение фиксированного количества элементов в выпадающем списке (напр. 4.5) является антипаттерном?
В большинстве случаев не имеет ценности отображать выпадающий список высотой во весь экран, чтобы выбрать пару элементов, а в других случаях хватит поиска
Автор как будто умалчивает реальную причину блокировки, что наводит на определенные мысли, что, вероятно, блокировка не была просто сделана "по ошибке"
К примеру мой аккаунт существует с 2015 года и я активно работаю на GitHub и за все время меня ни разу не блокировали. Может быть это конечно везение?