Корзунов Антон
@kashey
javascript, webgl, maps, react, орфография(нет)
Information
- Rating
- Does not participate
- Location
- Sydney, New South Wales, Австралия
- Date of birth
- Registered
- Activity
javascript, webgl, maps, react, орфография(нет)
Information
Главное эти опционы получить.
PS: и про фиговину для Jira (и почему не для StarTrack?)
Еще есть 100500 различных redux обвязок, которые берут этот «стор», что-то с ним делают, и кладут обратно. Простейщий пример — habr.com/post/346116, и таких десятки, на все-все случаи в жизни.
«Обычный» redux поддерживает это из коробки. Rematch, react-copy-write и другие — этот принцип ломают.
— старый добрый MVC, где все будет готово до «реакта», он сам будет renderToString
— микс, где мы используем Реакт чтобы инициализировать данные, а потом renderToString
— «новый», с renderToStream и «suspence» под капотом.
Асинхронность на сервер-сайде, и использованием lifecycle Реакта — нычне стало легко и удобно. Но любой глобал это дело пресекает на корню.
Круто и удобно для клиентсайда.
Круто и удобно для старого доброго синхронного серверсайда.
Вообще никак не работает с новым кленовым асинхронным SSR. Потому что стор не паралелиться.
Выход тут только один, и многие по нему идут – один рендер == 1 процесс.
Прощай nodejs, привет Apache prefork!
«Такой» TypeScript сеет панику и ошибки в в рядах падаванов.
Так и тут — — «без проблем» может узнать тип события из переданного компонента.
Да, всегда можно сказать — это чтобы перепроверить входящие значения, но имхо, лучше доверится типам.
* — в конце или точка, так как «ну что поделать то», или восклицательный знак (гори оно все огнем), или вопросительный знак (И что делать?). Никак не могу решить.
Вы хотели сказать — используют любую классическую библиотеку на основе промисов?
А про stateless — MemoizedFlow сам то stateful, но никак не регламентирует чем должны быть «вы».
— все думаю перенести все дела из getDeviredStateFromState в componentDidUpdate, потому что второй представляет и данных побольше, и сайдэффекты «разрешает».
— зачем писать свой getDeviredStateFromProps если он вам не нужен, и вообще у вас Stateless компонент?
Но на самом деле — почему бы и не использовать прямо в render. Проблем нет.
В принципе все так называемые «code smells» и антипатерны примерно об этом — оно вообще работает, но рано или поздно все сломается. Когда новый джун выйдет, например.
У меня за джуна выступает жена, для которой до сих пор составляет проблему написать js, c правильным reselect она 100% не справится, в то время как такая вот развесистая конструкция у нее проблем не вызывает.
Вся проблема в том как это написать так чтобы было просто, удобно и всем понятно. В случае с reselect или обычной мемозаиций — каждый шаг понятен, но не понятно как они сочетаются.
Тут — сильно понятнее и короче. И декларативнее.
WeakMapов тут нет, это какой-то ботаник начал их городить непонятно зачем и почему. И proxy тут нет, так как работать должно под IE11/React Native. (на самом деле есть и то и другое, но не всегда)
А скорость? memoize-state просто знает какие ключи были использованы для формирования результата и проверяет их. При этом достаточно умно, понимая вложеность обьектов и как вообще «современная иммутабельность» работает. Я к тому, что при холостой работе там будет те же самые два ===, под одному на каждую функцию. В общем perf тесты часть репозитория, согластно измерениям там сотни тысяч, а то и миллионы мемоизированных операций в секунду. Чуть чуть медленее reselect или memoize-one.
Он вроде как должен помогать решать сложные задачи работы со стейтом, но тут нет стейта — только результат который надо показать на основе текущего стейта.
Всегда и везде это было в mapStateToProps, на стороне view(в react-redux), но никак не в redux-core.
Reselect composition в mapStateToProps сделает тоже самое, что и Reselect composition описанная в этой статье, только в возможно более «правильном» месте и будет болеть теми же самыми проблемами. Заменить reselect на memoize-state(он для того и был придуман) — и дело в шляпе.
Чтобы правильно (и оптимально, что важно) все посчитать redux должен по некому события сделать «что должен», после чего как-то тригернуть следуйщий этап. В редьсерах такого не сделать.
Быть может сага? В принципе она может ожидать прихода событий и вызывать функции обработчики, а они уже будут вызывать известные им этапы и будет все работать просто и удобно. (надо будет написать хелпер для такого, спасибо за идею)
А что делать если послали два события? Тогда все посчитается два раза, чтобы этого избежать, то прийдется «для расчета следуйщего этапа» тоже кидать событые, и надется что takeLatest сделает все правильно.
В общем я постарался решить задачу без redux, потому что не redux-ом единым. В нем хорошо хранить данные, но переключение направления сортировки или страницы — личное дело компонента отображения.