На скринах туториал MUI, используют оба способа, но не ясно в каких случаях что лучше использовать.

Вот как для себя разложил:

1 Если нужно залазить в theme то использовать styled из MUI
На сколько я понял то styled из MUI это просто синтаксический сахор для withStyles (это так?)

2 Если подключаем стили через className (если их много например разом в одном компоненте), а не привязываемся к сущности компонента, то используем makeStyles

3 Если делаем новый компонент без переопределения то используем styled из styled-components

Вопросы:
1 Все верно понимаю?
2 Для простого переопределения когда не нужно лезть в theme, лучше использовать styled из MUI или styled-components? Какие минусы у второго?

Всем привет. Правильно ли будет постоянно обращаться к localstorage, или лучше забрать из него всё в какую-то переменную, например в массив?

Ну смотри localStorage синхронный, так что он блокирует тред, решай сам.

Он в принципе быстро работает? Или всё таки не рекомендуется? Приложение маленькое (тестовое задание)

Он в принципе быстро работает? Или всё таки не рекомендуется? Приложение маленькое (тестовое задание)

Если это тестовое задание не надо морочится с такими мелочами, сам он довольно шустрый да, что ты будешь там хранить?

Он в принципе быстро работает? Или всё таки не рекомендуется? Приложение маленькое (тестовое задание)

Там прямо в задании - используй локасторэдж чтобы шутки, которые ты добавил в favourites, не удалились при перезагрузке страницы

Там прямо в задании - используй локасторэдж чтобы шутки, которые ты добавил в favourites, не удалились при перезагрузке страницы

При старте забираешь данные из localStorage и работаешь с ними в памяти (стейт или стейт-менеджер). Когда нужно обновить/удалить/добавить — делаешь это в памяти, а потом отправляешь в localStorage. Так будет больше всего похоже на настоящее приложение и в абстрактной перспективе можно будет заменить localStorage на серверное хранилище

Отличный ответ, спасибо!

Ещё раз — суть не в скорости, а в абстрагировании хранилища. Чтобы можно было наименьшим количеством телодвижений заменить localStorage на sessionStorage или api бэкенда. Если хочешь заработать дополнительных «очков», то сделай асинхронную обёртку над localStorage, которая будет тебе возвращать промисы. Тогда это решение очень легко будет заменить на бэкенд, ты покажешь, что понимаешь суть абстрагирования от хранилища и вот это вот всё.

Отличный ответ, спасибо!

Но тут любое решение правильное, если ты сможешь его аргументировать (желательно, комментариями в коде) — «я не стал заморачиваться и каждый раз напрямую иду в localStorage, потому что хотел сделать быстрее и это решает задачу» или «я наебенил здесь абстракций, чтобы можно было расширять и модифицировать приложение, потому что я могу и потому что забочусь о будущем продукта».

Оба варианта правильные с объяснениями и к обоим можно придраться, если объяснений нет.

Компонент должен быть либо управляемым, либо неуправляемым. Это внутренняя кухня реакта. Нигде не задокументировано, как компонент должен себя вести в случае изменения на лету, а значит команда реакта может в любой момент выпустить апдейт, в котором такие компоненты не будут работать