Не думаю, что минус частоты обновления документации реакта объективен. Более того, как разработчик более 20 проектов на реакт за последние 4 года минусы производительности виртуального дом существенно снизились, нивелируются стандартными техниками рекомпозиции компонентов, а также возможностью всегда перейти на ванилу жс минуя реакт абстракции в критических для производительности местах. При этом, вы не будете страдать от такого перехода. Поэтому светлу нужно что-то больше чем сейчас, чтобы на него смотрели серьёзно. Для бизнеса с огромными деньгами важна надёжность — это не только инструменты, но и люди. Чем большее количество людей вовлечены в развитие и поддержку — тем охотнее бизнес внедряет такие инструменты. Если же такими инструментами владеют только самые «гики» — это риск, на который никто не пойдёт. Вопрос доверия остаётся открытым
я сперва усиленно педалировал стрелочные для байдинга к инстансу. а теперь вот могу сказать: если вам важна отладка вашего кода в хром девтулс, не делайте так. при использовании сорсмаппов хром не понимает стрелочные функции и говорит что this не существует, а следовательно typeerror тебе а не значения в инстансе. в том же stage0 есть новый bind syntax :: — он куда лучше, так как транслируется в обычный bind. другой подход это определение методов в конструторе или использование замыканий вместо this… и еще — это не такой уж уникальный список — половина описанного есть в учебниках по es5 — остальное в учебниках по еs6+, а некоторые его пунткты вроде замены ветвления на или — отстой. в программировании число символов не главное, главное чтобы всем было понятно, что ты делаешь и зачем, а для минификации есть инструменты.
Я не выискиваю. Вы просто твердите одно и то же, и поверьте я вас услышал. Я написал вам, почему реакт и редакс.
Повторяю: есть реальные приложения, которые приносят прибыль. Они живут годы, появились тогда, когда лучшими были реакт и редакс. Они работают так, как хотят того пользователи, а аналогов нет. Работают хорошо! Переписывать что-то с инструмента на инструмент, потому что прошлый инструмент "устарел" или в нем есть недостатки, которые при должном мышлении и подходе нивелируются — чушь. это как айфон покупать каждый год, просто потому что вышел новый, а не потому что старый сломан. Коммерческое ПО так не разрабатывают. У нас есть продукты на вью — они новые, потому что вью появился недавно. А по поводу уродца из Фейсбука — да, вы правы. Этот инструмент — продукт жизнедеятельности конкретной компании, хотя впрочем как и большинство профессиональных инструментов. Он покрывает нужды той компании, откуда произошел, а не нужды всех и каждого. Но для большинства приложений его хватает. Тут дело в разработчиках скорее всего уже — на какой бы классный инструмент вы не посадили человека, ему все не то и не так. Это инфантильный подход: выбрасывать работающие вещи, потому что они не модные или их выпустил не Иван Ю. Любой продукт со временем переписывают, учитывая прошлые недостатки, но не потому что так сказал человек в интернете. Ощущение, что я должен объяснять всем и каждому одни и те же прописные истины.
Ну вот смотрите: я делаю как сказал винтаж. бросаю все и бегу от реакта с редаксом, как от чумы. беру самый новый фреймворк из возможных, основываясь на бенчах в интернете. И начинаю пилить. Происходит следующее — меня спрашивают почему вместо нового функционала, который хочет видеть потенциальный крупный покупатель в нашем ПО, я переписываю страничку авторизации? Почему я заново делаю эти панели и окна, которые заморозили как стабильные еще в позапрошлом году? А я говорю: реакт отстой, а вот убер-вафля, которую написал спутник19103(ник вымышлен), — будущее интернета и срочно надо все переписать. На меня смотрят как на идиота и просят вернуться к разработке проекта и не страдать фигней. Это в лучшем случае.
В итоге, я, человек потративший больше 10 лет на карьеру программиста и 4 года на совершенствование программных решений, солью весь свой авторитет, карьеру и прочее в унитаз, потому что кто-то в интернете считает, что нужно все переписать.
Вы правы, это стоит того. А последствия — да пёс с ними.
Что вы злой такой? При чем тут костыли? Любая библиотека имеет недостатки и требует затрат для изучения, правильного использования и оптимизации, а все разработчики допускают ошибки в планировании и разработке — они люди, разработчики библиотек тоже, как ни странно. Непогрешимых нет. Другое дело делают ли они работу над ошибками и учатся новому, или нет. Вы тут хейтите по чем зря. Вашу позицию выяснили — мы глупые, жрем кактус, однако по щелчку только в комиксах мир меняется. Такое ощущение, что вы существуете в отрыве от реальности. Не надо так.
Я написал какие проблемы. Хотите еще? Окей, допустим вы вынесли локальное состояние и получение данных выше, чтоб наверняка, в контейнер страницы. У вас появилась необходимость прокидывать пропсы через иерархию. Это приводит к связанности компонентов и ререндеру для прокидывания нового состояния. То есть компоненты, которые организуют передачу будут вызывать рендер, чтобы ваш список получил данные, а не чтобы перерисоваться. Все начинает притормаживать — реакт в фоне делает пересчеты. Как итог, вы получаете свои данные, а пользователь — тормозящий интерфейс.
Расскажу вам кулстори 2х летней давности. Попал я на проект одной иностранной соцсети. И был там чатик. Все бы хорошо, но чат был просто отвратительно написан. я тут в комментариях писал про редьюсер в 1600+ строк — это как раз редьюсер чата. рефакторинг занял у меня 4 дня, я удалил более 11000 строк суммарно из кода чата и связанных модулей.
В чем с ним была проблема? Ну кроме спагетти кода, написанного крайне небрежно, мутаций и прочего.
Если открыть чатик в хроме — он работал, притормаживал, но вполне жил, скрепя байты, делал свою работу. Турбофан все же делает свое дело...
Если открыть в фф и попытаться написать — символы появляются с задержкой до 6 секунд. А если пишут тебе — то интерфейс становился еще мертвее.
Проблема была в посылке статуса тайпинг, хотя это и не единственная проблема. Просто кто-то жмет клавишу — а у тебя окно чата 627 раз зовет рендер (я написал простенький счетчик вызовов, чтоб разобраться). И вот если у тебя не мощный комп, а тогда я ради эксперимента пересел на ноут из днс с пентиумом, ты превращаешься в хатико. Ты резко ненавидишь разрабов, которые сидят на своих компах с топовым железом и не думают про планшеты и дешманские ноуты. А ведь если думать о пользователях соцсетей — они выходят в сеть с чего угодно, но не с компа с 6-ядерным intel восьмого поколения и 32 гигами оперативки.
Так вот, оказалось, что этот самый "user typing..." (а точнее флаг) пропс дриллингом прокидывался через иерархию компонентов к месту вывода. Ну и получается суммарно 627 рендеров на нажатие клавиши у твоего оппонента. Стоило вынести тайпинг в стор и конектнуть именно строку которой нужен флаг, и лаг снизился раз в 5. а количество ререндеров стало 1.
Поэтому я все понимаю, подход ваш тоже, но использование редакс, как и неиспользование, может привести к страшным последствиям, если не думать.
Согласен с вами, организация роутинга в приложении с редакс вызывает проблемы. Конечно стало несколько проще с появлением 4 версии роутера, но проблем это не решило.
Так статья не для начинающих(о чем я в начале написал). Это не призыв, а проблемы я описал. Но видимо каждый замечает то, что хочет и не смотрит на остальное… Это хорошо, что вы приводите ссылку на комментарий в issue, но хотелось бы пояснений в документации или более популярных источниках.
Проблема, которую я описал, а именно конфликт состояний и поломку таймтревела описана в документации redux тремя строками. Локальный стейт используют не думая и не разбирая. Редакс используют так же не разборчиво. в цитате, которую вы приводите, есть уточнение, которое как по мне снимает претензии
При логауте нужно всю страницу перезагружать, чтобы гарантировать, что ничего не останется в памяти, ни в каком замыкании.
зачем? может еще и старый комп сжигать, чтоб наверняка?
как только вы выгружаете страницу из памяти, например, делаете логаут, и очищаете стейт у вас не останется ничего… это конечно, если вы не злой буратино и не пишите специально сохранение всяких левых данных…
mam — сборщик, использующий библиотеку $mol_atom, аналог MobX.
супер! но тем не менее, это не mobX… Вопрос то был про то, зачем редакс если есть mobX. Ответ был про заточенность на серверный рендеринг, и про отсутствие примеров серверного рендеринга с mobX. И опять же, пусть мы берем mam в расчет: 12 звезд против 18.9k у mobX, 47.8k у redux. $mol — 200 звезд… Библиотека может быть сколько угодно хорошей, но пока нет сообщества, экосистемы — нет и специалистов, не спроса у продуктовых и аутсорс компаний… Вам лучше пиарить эти инструменты на митапах, вебинарах и конференциях, написать больше статей, примеров и прочего. Собрать сообщество и экосистему…
Давайте свернем это обсуждение. А то получается такой диалог:
я: мне нужна ложка, у вас есть?
вы: есть вилка!
я: но мне нужна ложка!
вы: есть вилка и палочки, они совсем как ложка, удобные! зачем вам ложка?
я: хорошая вилка и палочки для суши наверно удобные, но мне нужна ложка — я ем суп!
Пользователю с медленным 3g придется ждать вечность, пока подгрузится список. он закроет окошко не дождавшись...
Как поведет себя ваше приложение? Упадет при резолве ответа, ведь компонента больше нет? При повторном открытии выкинет данные и пошлет опять запрос и пользователь опять не дождется?
У компонента всегда есть родитель, который может сказать вашему компоненту "до свидания". Тем самым весь прогресс теряется и начнется проделывать все заново. Чтобы сделать актуальность — достаточно запрашивать не чаще чем 5-10 секунд с прошлого ответа.
При этом стор как правило живет, пока живет приложение. Соответственно: если запрос был секунду назад или еще в процессе вы и так получите актуальные данные. И не важно сколько раз тапнет пользователь. При этом сам компонент не будет отвечать ни за что кроме рендеринга — это основное назначение компонента, а не запросы к серверу.
Есть понятие зона ответственности, ее не нужно нарушать, тогда приложение будет поддерживаемым, простым, тестируемым и более надежным.
Поймите, у меня вопросов к редакс, наверное, больше, чем у многих, и я его не выгораживаю, но я имею четкое понимание, что если не разделять ответственность, не выделять абстракции, слои — приложение превращается в кучу кода, а не в ПО.
Можно подумать, я 200 лет проспал, зашел на хабр, а тут опять плоскую землю развенчивают. чур меня, пошел я обратно в криокамеру, разбудите, когда шароземельщики снова победят.
Еще раз повторюсь: предмет статьи в том, что 1й постулат редакса не работает с react internal state. Отсюда вытекают дополнительные сложности.
Вы в своем первом комментарии написали про получение данных с сервера и сохранение его в локальный стейт — это уже противоречит локальному состоянию, которое вы описываете дальше. Так по вашему нормально данные с сервера сохранять через замыкание в state? Вам не кажется такой подход противоречивым и требующим пересмотра?
Чищу. Извините, это был ответ, симметричный вашим:
Да.
Да запросто.
Есть сборщики
Очистка стора делается просто. Вместо того, чтобы в объединенный редьюсер передавать предыдущее состояние, при определенных экшенах подаем undefined. в итоге получаем исходное состояние.
Ну вот mam сборщик использует похожую штуку на сервере
именно mobX? или просто обсерверы? Мне нравится, что вы продвигаете инструменты eigenmethod, но это все равно не mobX на сервере в продакшене.
Спасибо, постараюсь лучше
Эм… это был пример про связанность) да, на редаксе можно многое наворотить, не спорю
Ваши утверждения мало согласуются с действительностью.
Я не выискиваю. Вы просто твердите одно и то же, и поверьте я вас услышал. Я написал вам, почему реакт и редакс.
Повторяю: есть реальные приложения, которые приносят прибыль. Они живут годы, появились тогда, когда лучшими были реакт и редакс. Они работают так, как хотят того пользователи, а аналогов нет. Работают хорошо! Переписывать что-то с инструмента на инструмент, потому что прошлый инструмент "устарел" или в нем есть недостатки, которые при должном мышлении и подходе нивелируются — чушь. это как айфон покупать каждый год, просто потому что вышел новый, а не потому что старый сломан. Коммерческое ПО так не разрабатывают. У нас есть продукты на вью — они новые, потому что вью появился недавно. А по поводу уродца из Фейсбука — да, вы правы. Этот инструмент — продукт жизнедеятельности конкретной компании, хотя впрочем как и большинство профессиональных инструментов. Он покрывает нужды той компании, откуда произошел, а не нужды всех и каждого. Но для большинства приложений его хватает. Тут дело в разработчиках скорее всего уже — на какой бы классный инструмент вы не посадили человека, ему все не то и не так. Это инфантильный подход: выбрасывать работающие вещи, потому что они не модные или их выпустил не Иван Ю. Любой продукт со временем переписывают, учитывая прошлые недостатки, но не потому что так сказал человек в интернете. Ощущение, что я должен объяснять всем и каждому одни и те же прописные истины.
Ну вот смотрите: я делаю как сказал винтаж. бросаю все и бегу от реакта с редаксом, как от чумы. беру самый новый фреймворк из возможных, основываясь на бенчах в интернете. И начинаю пилить. Происходит следующее — меня спрашивают почему вместо нового функционала, который хочет видеть потенциальный крупный покупатель в нашем ПО, я переписываю страничку авторизации? Почему я заново делаю эти панели и окна, которые заморозили как стабильные еще в позапрошлом году? А я говорю: реакт отстой, а вот убер-вафля, которую написал спутник19103(ник вымышлен), — будущее интернета и срочно надо все переписать. На меня смотрят как на идиота и просят вернуться к разработке проекта и не страдать фигней. Это в лучшем случае.
В итоге, я, человек потративший больше 10 лет на карьеру программиста и 4 года на совершенствование программных решений, солью весь свой авторитет, карьеру и прочее в унитаз, потому что кто-то в интернете считает, что нужно все переписать.
Вы правы, это стоит того. А последствия — да пёс с ними.
Что вы злой такой? При чем тут костыли? Любая библиотека имеет недостатки и требует затрат для изучения, правильного использования и оптимизации, а все разработчики допускают ошибки в планировании и разработке — они люди, разработчики библиотек тоже, как ни странно. Непогрешимых нет. Другое дело делают ли они работу над ошибками и учатся новому, или нет. Вы тут хейтите по чем зря. Вашу позицию выяснили — мы глупые, жрем кактус, однако по щелчку только в комиксах мир меняется. Такое ощущение, что вы существуете в отрыве от реальности. Не надо так.
Я написал какие проблемы. Хотите еще? Окей, допустим вы вынесли локальное состояние и получение данных выше, чтоб наверняка, в контейнер страницы. У вас появилась необходимость прокидывать пропсы через иерархию. Это приводит к связанности компонентов и ререндеру для прокидывания нового состояния. То есть компоненты, которые организуют передачу будут вызывать рендер, чтобы ваш список получил данные, а не чтобы перерисоваться. Все начинает притормаживать — реакт в фоне делает пересчеты. Как итог, вы получаете свои данные, а пользователь — тормозящий интерфейс.
Расскажу вам кулстори 2х летней давности. Попал я на проект одной иностранной соцсети. И был там чатик. Все бы хорошо, но чат был просто отвратительно написан. я тут в комментариях писал про редьюсер в 1600+ строк — это как раз редьюсер чата. рефакторинг занял у меня 4 дня, я удалил более 11000 строк суммарно из кода чата и связанных модулей.
В чем с ним была проблема? Ну кроме спагетти кода, написанного крайне небрежно, мутаций и прочего.
Если открыть чатик в хроме — он работал, притормаживал, но вполне жил, скрепя байты, делал свою работу. Турбофан все же делает свое дело...
Если открыть в фф и попытаться написать — символы появляются с задержкой до 6 секунд. А если пишут тебе — то интерфейс становился еще мертвее.
Проблема была в посылке статуса тайпинг, хотя это и не единственная проблема. Просто кто-то жмет клавишу — а у тебя окно чата 627 раз зовет рендер (я написал простенький счетчик вызовов, чтоб разобраться). И вот если у тебя не мощный комп, а тогда я ради эксперимента пересел на ноут из днс с пентиумом, ты превращаешься в хатико. Ты резко ненавидишь разрабов, которые сидят на своих компах с топовым железом и не думают про планшеты и дешманские ноуты. А ведь если думать о пользователях соцсетей — они выходят в сеть с чего угодно, но не с компа с 6-ядерным intel восьмого поколения и 32 гигами оперативки.
Так вот, оказалось, что этот самый "user typing..." (а точнее флаг) пропс дриллингом прокидывался через иерархию компонентов к месту вывода. Ну и получается суммарно 627 рендеров на нажатие клавиши у твоего оппонента. Стоило вынести тайпинг в стор и конектнуть именно строку которой нужен флаг, и лаг снизился раз в 5. а количество ререндеров стало 1.
Поэтому я все понимаю, подход ваш тоже, но использование редакс, как и неиспользование, может привести к страшным последствиям, если не думать.
Согласен с вами, организация роутинга в приложении с редакс вызывает проблемы. Конечно стало несколько проще с появлением 4 версии роутера, но проблем это не решило.
Так статья не для начинающих(о чем я в начале написал). Это не призыв, а проблемы я описал. Но видимо каждый замечает то, что хочет и не смотрит на остальное… Это хорошо, что вы приводите ссылку на комментарий в issue, но хотелось бы пояснений в документации или более популярных источниках.
Проблема, которую я описал, а именно конфликт состояний и поломку таймтревела описана в документации redux тремя строками. Локальный стейт используют не думая и не разбирая. Редакс используют так же не разборчиво. в цитате, которую вы приводите, есть уточнение, которое как по мне снимает претензии
Ну кто в здравом уме оставляет в продакшене девтулс? таймтревел доступен только оттуда. не выдумывайте...
зачем? может еще и старый комп сжигать, чтоб наверняка?
как только вы выгружаете страницу из памяти, например, делаете логаут, и очищаете стейт у вас не останется ничего… это конечно, если вы не злой буратино и не пишите специально сохранение всяких левых данных…
при логауте, например.
супер! но тем не менее, это не mobX… Вопрос то был про то, зачем редакс если есть mobX. Ответ был про заточенность на серверный рендеринг, и про отсутствие примеров серверного рендеринга с mobX. И опять же, пусть мы берем mam в расчет: 12 звезд против 18.9k у mobX, 47.8k у redux. $mol — 200 звезд… Библиотека может быть сколько угодно хорошей, но пока нет сообщества, экосистемы — нет и специалистов, не спроса у продуктовых и аутсорс компаний… Вам лучше пиарить эти инструменты на митапах, вебинарах и конференциях, написать больше статей, примеров и прочего. Собрать сообщество и экосистему…
Давайте свернем это обсуждение. А то получается такой диалог:
я: мне нужна ложка, у вас есть?
вы: есть вилка!
я: но мне нужна ложка!
вы: есть вилка и палочки, они совсем как ложка, удобные! зачем вам ложка?
я: хорошая вилка и палочки для суши наверно удобные, но мне нужна ложка — я ем суп!
Я, если честно, вижу тут следующее:
Пользователю с медленным 3g придется ждать вечность, пока подгрузится список. он закроет окошко не дождавшись...
Как поведет себя ваше приложение? Упадет при резолве ответа, ведь компонента больше нет? При повторном открытии выкинет данные и пошлет опять запрос и пользователь опять не дождется?
У компонента всегда есть родитель, который может сказать вашему компоненту "до свидания". Тем самым весь прогресс теряется и начнется проделывать все заново. Чтобы сделать актуальность — достаточно запрашивать не чаще чем 5-10 секунд с прошлого ответа.
При этом стор как правило живет, пока живет приложение. Соответственно: если запрос был секунду назад или еще в процессе вы и так получите актуальные данные. И не важно сколько раз тапнет пользователь. При этом сам компонент не будет отвечать ни за что кроме рендеринга — это основное назначение компонента, а не запросы к серверу.
Есть понятие зона ответственности, ее не нужно нарушать, тогда приложение будет поддерживаемым, простым, тестируемым и более надежным.
Поймите, у меня вопросов к редакс, наверное, больше, чем у многих, и я его не выгораживаю, но я имею четкое понимание, что если не разделять ответственность, не выделять абстракции, слои — приложение превращается в кучу кода, а не в ПО.
По вашему вопросу не понятно, совсем чистить или не совсем.
Другая библиотека? MobX стейт менеджер, а mam — нет? MobX является частью экосистемы, а mam или просто обсерверы — нет? Достаточно принципиально?
Можно подумать, я 200 лет проспал, зашел на хабр, а тут опять плоскую землю развенчивают. чур меня, пошел я обратно в криокамеру, разбудите, когда шароземельщики снова победят.
Простите, если понял вас неправильно.
Еще раз повторюсь: предмет статьи в том, что 1й постулат редакса не работает с react internal state. Отсюда вытекают дополнительные сложности.
Вы в своем первом комментарии написали про получение данных с сервера и сохранение его в локальный стейт — это уже противоречит локальному состоянию, которое вы описываете дальше. Так по вашему нормально данные с сервера сохранять через замыкание в state? Вам не кажется такой подход противоречивым и требующим пересмотра?
Спасибо за уточнение
Чищу. Извините, это был ответ, симметричный вашим:
Очистка стора делается просто. Вместо того, чтобы в объединенный редьюсер передавать предыдущее состояние, при определенных экшенах подаем undefined. в итоге получаем исходное состояние.
именно mobX? или просто обсерверы? Мне нравится, что вы продвигаете инструменты eigenmethod, но это все равно не mobX на сервере в продакшене.