Сделал вот так, насколько это правильно?

вообще можно и покороче const listHeroes = heroes.filter(hero => hero.id === 1).map(hero => (<li><AppPromoItems heroes={hero}/></li>);

вообще можно и покороче const listHeroes = heroes.filter(hero => hero.id === 1).map(hero => (<li><AppPromoItems heroes={hero}/></li>);

Ребята, кто сталкивался с такой проблемой, подскажите, как решить?

Ребята, кто сталкивался с такой проблемой, подскажите, как решить?

посмотри, что экспортирует библиотека

кто-нибудь работал с либой luxon ?

Если у вас фильтр и мап, замените на reduce

Не

всмысле не? 2 прохода лучше 1 ??

всмысле не? 2 прохода лучше 1 ??

Потому что {loader} не в контексте jsx - обьект

если кто то не знает reduce не значит что он менее читабелен

если кто то не знает reduce не значит что он менее читабелен

Спасибо)

а вынести и назвать логично?

Зачем все это, когда filter().map() отлично решают задачу?

Ребят, помогите пожалуйста, есть локальная bd.json, всю инфу из нее выгружаю в редакс, далее получаю ее в app-promo используя useEffect, как выводить запись из этой бд по определенному id? а не все, что там есть, и вообще, правильно ли я делаю, используя useEffect?

⁉️

Щас бы с 50 элементами всерьез думать о производительности перебора

Жизнь она сложнопредсказуемая. Ща у тебя 50 элементов, поменялись требования - 500 элементов. Ушло в продакшн - пару тысяч. Поработало там год - 100500

Жизнь она сложнопредсказуемая. Ща у тебя 50 элементов, поменялись требования - 500 элементов. Ушло в продакшн - пару тысяч. Поработало там год - 100500

Это да, согласен что заранее оптимизировать зло, что оптимизировать надо ботлнек и вот это все. Но выигрыш в читаемости .filter .map тоже такой себе эфмерный. Что та херня что эта херня, больше от предпочтений зависит

Есть случаи когда семантически вооще нефига не очевидно что использовать

я ща про сфериеский вакуум а не конкретный кусок кода))

Это да, согласен что заранее оптимизировать зло, что оптимизировать надо ботлнек и вот это все. Но выигрыш в читаемости .filter .map тоже такой себе эфмерный. Что та херня что эта херня, больше от предпочтений зависит

Я вот подумал на счёт этого "пиара" MobX... Вот простой кейс для работы с аналитикой (код на Reatom). // File 1: Google subscribe(addedProduct, productInfo => { // ...отправка данных в гугыль }) // File 2: Yandex subscribe(addedProduct, productInfo => { // ...отправка данных в яшу }) // File 3: VK subscribe(addedProduct, productInfo => { // ...отправка данных в вк }) // etc... Reatom — ок, +TS Effector — ок, +TS Redux — +- через middleware и с костыльным выводом типов А как справляется с этим кейсом MobX? :)

аналогично const addedProduct = observable(null); // File 1: Google reaction(() => addedProduct.get(), productInfo => { // ...отправка данных в гугыль }) // File 2: Yandex reaction(() => addedProduct.get(), productInfo => { // ...отправка данных в яшу }) // File 3: VK reaction(() => addedProduct.get(), productInfo => { // ...отправка данных в вк }) addedProduct.set(...); ... addedProduct.set(...);

Есть чат на PWA? Вопрос могу ли я из PWA читать clipboard (когда захочу), естественно запросив права на это.

Чета я там заблокирован 🤔🤔🤔🤔

Там нужно слушать событие а не изменение значений

В mobx нет событий потому что вместо них можно использовать переменные состояния и сущность "событие" становится избыточной

а введение этой сущности может дать какие-то преимущества?

А зачем? Уже есть один способ различным обработчикам отреагировать на новою информацию. В данном случае изменение переменной в которую записывается информация о событии и является тем самым способом вызвать соответствующих обработчиков этого события

Ребят, подскажите, тут всё ок с этим кодом?

Ребят, подскажите, тут всё ок с этим кодом?

не, это я сам в квадратик обвел) меня смущает этот момент как раз

не, это я сам в квадратик обвел) меня смущает этот момент как раз

Имхо, я бы вынес в сам обработчик выдергивание языка, а не создавал на каждую кнопку отдельный обработчик, суть которого - просто прокидывать значение lng

Имхо, я бы вынес в сам обработчик выдергивание языка, а не создавал на каждую кнопку отдельный обработчик, суть которого - просто прокидывать значение lng

без него ругается index.js:1 Warning: Each child in a list should have a unique "key" prop.

О как, не сталкивался с таким, ну раз так. То что делать, пусть будет. Может сможешь тогда его как аттрибут кнопки читать в обработчике? Тогда и data не потребуется.

так?

я бы еще хэндлер в useCallback хук обернул

Ребят, подскажите, тут всё ок с этим кодом?