Pull to refresh
54
0
Корзунов Антон @kashey

javascript, webgl, maps, react, орфография(нет)

Send message
А где-то слышал, что после пары лет в Яндексе на одних опционах выходит 200+ в месяц.
Главное эти опционы получить.
А можно сильно поподробнее про logic review?
PS: и про фиговину для Jira (и почему не для StarTrack?)
Проблема про сервер сайд — _Одновременно_ генерятся страницы для _разных_ клиентов.
Тот «стор» с которым работать можно, лежит в контексте и для каждого инстанса свой. Только протяни руки в контекст и возьми.
Еще есть 100500 различных redux обвязок, которые берут этот «стор», что-то с ним делают, и кладут обратно. Простейщий пример — habr.com/post/346116, и таких десятки, на все-все случаи в жизни.
Потому что две разные страницы будут шарить один глобальных «store», в то время как должны быть полностью изолированы друг от друга.
«Обычный» redux поддерживает это из коробки. Rematch, react-copy-write и другие — этот принцип ломают.
В случае с реактом есть 3 варианта рендеринга на сервер сайде:
— старый добрый MVC, где все будет готово до «реакта», он сам будет renderToString
— микс, где мы используем Реакт чтобы инициализировать данные, а потом renderToString
— «новый», с renderToStream и «suspence» под капотом.
Асинхронность на сервер-сайде, и использованием lifecycle Реакта — нычне стало легко и удобно. Но любой глобал это дело пресекает на корню.
На сервере может выполнять множество рендеров одновременно. Кто-то все еще считает, что Js это только фронтенд, 1 процесс и ровно 1 задача на исполнение — и из-за этого этот самый Js все еще именно такой.
Кстати — одно из самых главный ограничений «всех этих библиотек»(убийц редакса) — они делает вещи простыми, делают «стор» доступным из любого места, и все такое.
Круто и удобно для клиентсайда.
Круто и удобно для старого доброго синхронного серверсайда.
Вообще никак не работает с новым кленовым асинхронным SSR. Потому что стор не паралелиться.
Выход тут только один, и многие по нему идут – один рендер == 1 процесс.

Прощай nodejs, привет Apache prefork!
Особая боль возникает когда от использования «старых» вариантов TS, когда заместо простого `connect` пишут `connect<StateProps, ComponentMappedProps, PublicComponentProps>`, при том что часть PublicComponentProps могут быть перекрыты ComponentMappedProps.

«Такой» TypeScript сеет панику и ошибки в в рядах падаванов.

Так и тут —
withOnChangeString<InputProps>(SimpleInput)
— «без проблем» может узнать тип события из переданного компонента.
Да, всегда можно сказать — это чтобы перепроверить входящие значения, но имхо, лучше доверится типам.
Так можно IP в логах хранить или нельзя?
Я понял, что мы все умрем. Но что делать *
* — в конце или точка, так как «ну что поделать то», или восклицательный знак (гори оно все огнем), или вопросительный знак (И что делать?). Никак не могу решить.
это try/catch hell с бесконечными unhandled promise rejection, который может возникнуть, например, если разработчики не договорились на каком уровне эти ошибки обрабатывать.


Вы хотели сказать — используют любую классическую библиотеку на основе промисов?
Ну вот потому и не переношу :)
А про stateless — MemoizedFlow сам то stateful, но никак не регламентирует чем должны быть «вы».
Основых идей две:
— все думаю перенести все дела из getDeviredStateFromState в componentDidUpdate, потому что второй представляет и данных побольше, и сайдэффекты «разрешает».
— зачем писать свой getDeviredStateFromProps если он вам не нужен, и вообще у вас Stateless компонент?

Но на самом деле — почему бы и не использовать прямо в render. Проблем нет.
Это тут все понятно. А если вы приходите на готовый проект (или уходите с такого) — было бы хорошо иметь совсем-совсем понятную логику.
В принципе все так называемые «code smells» и антипатерны примерно об этом — оно вообще работает, но рано или поздно все сломается. Когда новый джун выйдет, например.
У меня за джуна выступает жена, для которой до сих пор составляет проблему написать js, c правильным reselect она 100% не справится, в то время как такая вот развесистая конструкция у нее проблем не вызывает.
Нить нигде не потеряна, и поворот не пройден. Только кода получилось примерно в 6 раз больше чем в первом примере на мемоизацию.
  getSortedData = (lodash)memoize(magic)
  getPagedData = memoize(anotherMagic)

  render() {
    const sorted = this.getSortedData(this.props.data, this.props.sort);
    const pages = this.getPagedData(sorted, this.props.page);
  }

Вся проблема в том как это написать так чтобы было просто, удобно и всем понятно. В случае с reselect или обычной мемозаиций — каждый шаг понятен, но не понятно как они сочетаются.
Тут — сильно понятнее и короче. И декларативнее.
memoizedFlow([
    ({data, sort}) => ({ data: magic(data, sort)}),
    ({data, page}) => ({ data: anotherMagic(sorted, page)});
])

WeakMapов тут нет, это какой-то ботаник начал их городить непонятно зачем и почему. И proxy тут нет, так как работать должно под IE11/React Native. (на самом деле есть и то и другое, но не всегда)

А скорость? memoize-state просто знает какие ключи были использованы для формирования результата и проверяет их. При этом достаточно умно, понимая вложеность обьектов и как вообще «современная иммутабельность» работает. Я к тому, что при холостой работе там будет те же самые два ===, под одному на каждую функцию. В общем perf тесты часть репозитория, согластно измерениям там сотни тысяч, а то и миллионы мемоизированных операций в секунду. Чуть чуть медленее reselect или memoize-one.
state.visible — это копипаст конкретной боли конкретного человека из конкретного issue. Разговор переходит на задачу с таблицей парой абзацев ниже.
Мне казалось, что вопрос о том что React не является view layer давно закрыт. Как и вопрос об уместности постоянного использования redux.
Он вроде как должен помогать решать сложные задачи работы со стейтом, но тут нет стейта — только результат который надо показать на основе текущего стейта.
Всегда и везде это было в mapStateToProps, на стороне view(в react-redux), но никак не в redux-core.
Reselect composition в mapStateToProps сделает тоже самое, что и Reselect composition описанная в этой статье, только в возможно более «правильном» месте и будет болеть теми же самыми проблемами. Заменить reselect на memoize-state(он для того и был придуман) — и дело в шляпе.
Счастливые вы люди.
Это, как не странно, может быть сложная задача. Проблема в именно в «Flow».
Чтобы правильно (и оптимально, что важно) все посчитать redux должен по некому события сделать «что должен», после чего как-то тригернуть следуйщий этап. В редьсерах такого не сделать.
Быть может сага? В принципе она может ожидать прихода событий и вызывать функции обработчики, а они уже будут вызывать известные им этапы и будет все работать просто и удобно. (надо будет написать хелпер для такого, спасибо за идею)
А что делать если послали два события? Тогда все посчитается два раза, чтобы этого избежать, то прийдется «для расчета следуйщего этапа» тоже кидать событые, и надется что takeLatest сделает все правильно.

В общем я постарался решить задачу без redux, потому что не redux-ом единым. В нем хорошо хранить данные, но переключение направления сортировки или страницы — личное дело компонента отображения.

Information

Rating
Does not participate
Location
Sydney, New South Wales, Австралия
Date of birth
Registered
Activity