Есть класс людей (и даже целые регионы в нашей необъятной стране), для которых во всем мире всегда виноваты евреи. Спорность этого утверждения отрицать не буду - чести много.
Мне нравится такой подход к собеседованию. Помню, что где-то на просторах интернета видел собес в Альфу на котором собеседующие спрашивали, что будет если функцию 2 раза привязать к контекстам через bind (запомнил только это, но там было еще много чего интересного)
Стабильность заметно улучшилась - стабильно вылетает каждые 30 минут. Вместо нового оружия в игре большие восклицательные знаки. Графика визуально и правда стала лучше. Xbox
Я думаю, что вы однажды столкнетесь с клиентом, на котором будут нужны десятки / сотни вычислений из разных источников данных и тогда мы поговорим с вами о глубоком сравнении, оптимизации и других инструментах реакта и библиотеках которые отвечают за хранение данных
В редаксе и прочих библиотеках где не производится deep comparsion, не обойтись без встроенных инструментов реакта. Или смириться с неизбежным перерендерингом компонентов
Откуда? Какие такие экшены на генераторах в Mobx? Mobx 5 это ванильный js/ts код за исключением, может быть makeAutoObservable в конструкторе класса. Все. После этого делайте хоть на генераторах, хоть на промисах, хоть на async/await, никто не диктует условий
Это один из главных аргументов. Но это дело вкусовщины. Нравится вам бойлерплейт и идеология flux, нет проблем. Проблема в том, что это не избавляет вас от «проблем» реакта, таких, как например, always new свойств. С Mobx useCallback, useMemo, memo, можно позабыть, потому что он решает проблемы связанные с ними
Городить спред операторы и безумную логику без оптимизации - вот это сомнительная идея. По факту, useState хорош либо когда мы «получили данные и забыли», либо когда нам нужен boolean | string | number в useState.
Конечно. У вас есть список пользователей, при клике на одном из них вы переходите к странице с личной информацией, на которой у вас есть «жирный клиент» с возможностью добавлять, удалять и редактировать поля. Хранить такой стор как глобальный плохая практика, ведь при изменении юзера вам нужно делать условный «reset” стора, чтобы данные от прошлого юзера были затерты
В дополнение, предлагаю вам рассказать, что может предложить Mobx и redux в части локальных стейтов, когда не нужна «глобальная область видимости», а нужен конкретный стор для конкретного компонента, который будет работать как useState, но не наследовать его недостатков.
Вопрос, когда начнут сжать за слово VPN в статьях это вопрос времени, ИМХО
Раздражает useCallback и массив зависимостей в хуках. И перерендер ВСЕХ подписчиков контекста
Круто. Очень сильно что-то напоминает, но без батчинга. Он же тут есть?
«Иммутабельность лучше, чем мутабельность». От создателей switch case лучше чем if else
Есть класс людей (и даже целые регионы в нашей необъятной стране), для которых во всем мире всегда виноваты евреи. Спорность этого утверждения отрицать не буду - чести много.
Если бы вы умели причинно-следственные связи, то быстро бы разобрались, какой дед и когда там начал войну
В таком виде, как она представлена у вас в примере, не прикрутится.
Мне нравится такой подход к собеседованию. Помню, что где-то на просторах интернета видел собес в Альфу на котором собеседующие спрашивали, что будет если функцию 2 раза привязать к контекстам через bind (запомнил только это, но там было еще много чего интересного)
Стабильность заметно улучшилась - стабильно вылетает каждые 30 минут. Вместо нового оружия в игре большие восклицательные знаки. Графика визуально и правда стала лучше. Xbox
-> Локальный стор - это же context.
Store / state и тд это хранилище, контекст тут вообще не при чем
Я думаю, что вы однажды столкнетесь с клиентом, на котором будут нужны десятки / сотни вычислений из разных источников данных и тогда мы поговорим с вами о глубоком сравнении, оптимизации и других инструментах реакта и библиотеках которые отвечают за хранение данных
Как useReducer поможет при изменении ссылки в памяти при перерендеринге?
В редаксе и прочих библиотеках где не производится deep comparsion, не обойтись без встроенных инструментов реакта. Или смириться с неизбежным перерендерингом компонентов
Вы очень слабый программист, если получаете весь список со всеми атрибутами в одном массиве. Вы и ваши бэк энд разработчики
Конечно, внутри, все устроено сложнее, но это скрыто от пользователя, по факту взаимодействовать придется с почти ванильным js
Откуда? Какие такие экшены на генераторах в Mobx? Mobx 5 это ванильный js/ts код за исключением, может быть makeAutoObservable в конструкторе класса. Все. После этого делайте хоть на генераторах, хоть на промисах, хоть на async/await, никто не диктует условий
Это один из главных аргументов. Но это дело вкусовщины. Нравится вам бойлерплейт и идеология flux, нет проблем. Проблема в том, что это не избавляет вас от «проблем» реакта, таких, как например, always new свойств. С Mobx useCallback, useMemo, memo, можно позабыть, потому что он решает проблемы связанные с ними
Городить спред операторы и безумную логику без оптимизации - вот это сомнительная идея. По факту, useState хорош либо когда мы «получили данные и забыли», либо когда нам нужен boolean | string | number в useState.
Конечно. У вас есть список пользователей, при клике на одном из них вы переходите к странице с личной информацией, на которой у вас есть «жирный клиент» с возможностью добавлять, удалять и редактировать поля. Хранить такой стор как глобальный плохая практика, ведь при изменении юзера вам нужно делать условный «reset” стора, чтобы данные от прошлого юзера были затерты
В дополнение, предлагаю вам рассказать, что может предложить Mobx и redux в части локальных стейтов, когда не нужна «глобальная область видимости», а нужен конкретный стор для конкретного компонента, который будет работать как useState, но не наследовать его недостатков.