Volodymyr
что ? СССР распался же в 91 , как так то
from
Artem
как раз наоборот)
это интересно, потому что на сколько я знаю как раз таки из-за этих функций реакта, как раз смысл конструктора отпадает )
Artem
и лучше через них работать )
from
это интересно, потому что на сколько я знаю как раз таки из-за этих функций реакта, как раз смысл конструктора отпадает )
не придирайся к слову "конструктор", можно через класс проперти задать (как на скриншоте и сделано), это то же самое, что конструктор
from
в componentDidMount должны быть только асинхронные сайдэффекты (и ещё в редких случаях код, связанный с замерами dom-элементов)
from
Но тут ssr, я если честно хз какой бестпрактис для индикации "всё, мы в браузере"
Artem
в componentDidMount должны быть только асинхронные сайдэффекты (и ещё в редких случаях код, связанный с замерами dom-элементов)
интересно, спасибо есть над чем подумать )
Андрей
😕
from
😕
но если хочется анимацию запустить, то вероятно стоит класс анимации завязать на этот же стейт isLoading
Daniel
Надо доку сср погуглить или в их чатик зайти, здесь не совсем верное место
from
Кто нить реализовывал компонент на подобии input range с двумя ползунками касательно реакта ?
вроде вот это было норм http://lea.verou.me/2016/05/introducing-multirange-a-tiny-polyfill-for-html5-two-handle-sliders/
🦜
Bogdan
useReducer когда юзаешь, если в стейте много значений, которые нужно менять, как их менять? или дробить на компоненты меньше? например есть инпуты, помимо инпутов есть число, которое уменьшать, увеличивать можно
Bogdan
вот как тут например, я и счетчик хочу, и инпуты изменять, одним редюсером можно?
https://codesandbox.io/s/0jlvq3rkn
from
Bogdan
ты глянь пример, проблема не в полях, а в том , что два раза useReducer использую
from
from
*useReducer
конечно, хуков можно сколько хочешь (ну в рамках читаемости) использовать, в том их и суть отчасти
Bogdan
Bogdan
только называть как их? reducer, reducer2, reducer3 такое себе
Dmitry
Igor
В одном случае мы делим массив каждый rAF и сразу же в рендере пересоздаем ВСЕ объекты компонентов которые уже замонтировались + новые, во втором случае мы делим весь массив при первом рендере и уже с каждой частью массива работает индивидуальный компонент - за счет чего нет работы по пересозданию и пересчету объектов тех элементов, что уже отрендерились
И еще я подумал: а сама по себе идея LazyScroll сохраняется во втором варианте?
В первом случае, который ListLazyController и который использует ListLazy, кажется, как будто должен "грузиться" постепенно, но почему тогда скролл есть сразу?
from
только называть как их? reducer, reducer2, reducer3 такое себе
в редаксе вроде по фиче называют
from
можно formReducer, counterReducer
Bogdan
екшен при диспаче , а стейт когда
Bogdan
при диспатче тоже, это ж один вызов
туплю что то, вот диспач
dispatch({ type: name })
передали екшен, а стейт он откуда взял?
Bogdan
в useReducer второй параметр?
from
туплю что то, вот диспач
dispatch({ type: name })
передали екшен, а стейт он откуда взял?
так конкретный диспатч забайнджен на конкретный стейт
Bogdan
так конкретный диспатч забайнджен на конкретный стейт
ну конкретно в хуке он стейт взял тот, что передали в useReducer вторым параметром?
from
ну конкретно в хуке он стейт взял тот, что передали в useReducer вторым параметром?
в качестве изначального да
from
а так стейт в реакте хранится грубо говоря неважно где
from
Это для нас удобная условность что "стейт в компоненте"
Технически не важно где он там именно, главное что он правильно сопоставлен всегда)
artalar
И еще я подумал: а сама по себе идея LazyScroll сохраняется во втором варианте?
В первом случае, который ListLazyController и который использует ListLazy, кажется, как будто должен "грузиться" постепенно, но почему тогда скролл есть сразу?
Не, скролл везде будет "расти", попробуйте больше элементов поставить или делей увеличить, или тротл на CPU поставить.
Если хочется сразу и скрол точного размера - это придется немного заморочится и оно того не стоит, как мне кажется
Bogdan
в качестве изначального да
я вроде понял, счетчик например проще сделать с помощью useState, а обработку форму можно с useReducer
from
Stepan
Парни привет.
Посоветуйте пожалуйста: делаю SPA. В определенный момент с него на бекэнд идет GET запрос на API. В заголовках запроса есть Header Authorization: Barier token. В токене закодирован ID пользователя. Так я определяю кто обратился к API и отдаю его контент. Вот я думаю, я так с кеширование проблем не словлю? Не получится ли так, что одному пользователю отдадут контент закешированный от предыдущего? При кешировании протокол смотрит на хедеры? В спецификации вроде сказано что смотри только на URI. А если не смотрит то как правильно в таких случая организовывать работу API?
Volodymyr
artalar
Ага, не идеально) По идее завезут асинхронный рендеринг и будет еще быстрее работать
from
Парни привет.
Посоветуйте пожалуйста: делаю SPA. В определенный момент с него на бекэнд идет GET запрос на API. В заголовках запроса есть Header Authorization: Barier token. В токене закодирован ID пользователя. Так я определяю кто обратился к API и отдаю его контент. Вот я думаю, я так с кеширование проблем не словлю? Не получится ли так, что одному пользователю отдадут контент закешированный от предыдущего? При кешировании протокол смотрит на хедеры? В спецификации вроде сказано что смотри только на URI. А если не смотрит то как правильно в таких случая организовывать работу API?
С такими вопросами в бэкенд-чатики
По-хорошему если ты таким вопросом задаёшься, то вероятно ты не должен один писать бэк
Volodymyr
Ага, не идеально) По идее завезут асинхронный рендеринг и будет еще быстрее работать
хотя у меня на бэке стоит пейджинг, я не сразу все в дом выдаю. А все таки по скролу подгружаю.
from
artalar
хотя у меня на бэке стоит пейджинг, я не сразу все в дом выдаю. А все таки по скролу подгружаю.
Смотря чего списки. Бывает есть просто тыща элементов и она более-менее статична и хочется ее сразу показать.
У меня так с автокомплитом как-то было
Volodymyr
Смотря чего списки. Бывает есть просто тыща элементов и она более-менее статична и хочется ее сразу показать.
У меня так с автокомплитом как-то было
ну у меня таблицы, списки футбольных матчей.
from
Смотря чего списки. Бывает есть просто тыща элементов и она более-менее статична и хочется ее сразу показать.
У меня так с автокомплитом как-то было
тысячу строк разом рендерить всё равно идея на грани приличия)
from
а вот в память загрузить можно
artalar
тысячу строк разом рендерить всё равно идея на грани приличия)
Если это 1-2 блока, нет 🤔🤷♂️
from
ага это ты владельцу самснга j1 как пример скажи )
а что тут говорить, тысяча объектов в памяти это лучше, чем тысяча дом-нод в памяти
Volodymyr
а что тут говорить, тысяча объектов в памяти это лучше, чем тысяча дом-нод в памяти
я бы просто не выдавал 1000 нод сразу, я сторонник того что бы догрузить, если пользователю нужно.
from
я бы просто не выдавал 1000 нод сразу, я сторонник того что бы догрузить, если пользователю нужно.
ну мы же специально крайний случай обсуждаем)
from
так-то в идеальном мире грузить не больше чем несколько десятков сущностей, виртуализировать, по скроллу догружать новые и удалять из памяти старые :)
Volodymyr
from
че-то я кстати ни в одном стейт-менеджменте не видел примеров, как старое удалять
Volodymyr
state = [] ?
Volodymyr
))))
Mike
Mike
ну а в редаксе да, сам пиши экшен который при обработке вернет инишиал стейт
from
и потом, ближе к риал-ворлду — задача не всё удалить, а именно какие-то уголки стейта, к которым не обращались дольше всего
Volodymyr
Так сказать консистентный подход )
artalar
Volodymyr
🤔 не понял задачу
ну типо на инфинити скролле, показывать только то что видет пользователь, остальное удалять
Bogdan
from
🤔 не понял задачу
Ну самый простой пример — скроллишь ты пятую тысячу сообщений в чате, старые можно и удалить по-хорошему
Но скажем у тебя cursor-based pagination
Значит, надо не просто удалить первые n-строк массива, а ещё и курсор правильно обновить