Pull to refresh
108
0
Кирилл Коншин @dfuse

Principal Software Developer

По итогам работы с Cypress и Playwright был сделан вывод, что:

Cypress это такой самопальный мега-велосипед, выдумавший собственные стандарты, которые надо изучать как следствие, странно работающий очень во многих аспектах, и имеющий кучу странных ограничений вроде запуска двух браузеров. Вот нельзя и все. Или работы с Shadow Dom / фреймами. При этом крайне навороченный и в чем-то даже удобный, с GUI и тд. Но главное — безбожно тормозные авторы, которые игнорируют тренды, имеют странные приоритеты и плохо слышащие коммьюнити. Без обид. Продукт то хороший, но свернул не туда, в 2021 это уже более чем очевидно.

Playwright это по сути Puppeteer на стероидах, правильно обернутый в очень удобную, стандартную и понятную легковесную конструкцию, пользоваться которой легко и просто. С типизацией и прочим. Чего-то может не хватать, по сравнению с Cypress, но это с лихвой компенсируется коммьюнити, всякими плагинами и наворотами. А главное — скоростью разработки, отсутствием странностей (все как правило "просто работает"), и скоростью самих тестов.

FoMO был больше связан с кавказцами, чем с расовыми меньшинствами

Господи, какие кавказцы? Caucasian это БЕЛЫЕ.

Мобильный телефон в обычной сети видно, можно отслеживать позицию и факт передачи трафика, а в отдельной нет.

Статье 3 года, в документации к библиотеке все актуально описано

SPA на то и SPA, что на сервере должен происходить лишь первый рендеринг

Это ошибочное заключение, т.к. страниц на сервере множество. Например блог, где каждый пост рендерится на сервере. И при навигации надо это учитывать.


рендер должен лежать на клиенте

Вы в таком случае будете писать логику дважды. Один раз для первого захода, и второй раз для клиентской навигации. Архитектура Next.js заточена чтоб все было написано один раз и аккуратно доставлялось на клиент вне зависимости от последовательности действий.


Если бы вас там была целая компания, которая заточена на разработку этой либы

Вам не угодишь. Повторюсь, библиотека решает проблемы, люди пользуются и довольны. Вам не нравится — не пользуйтесь.


А как у вас реализована поддержка getServerSideProps? Вы оборачиваете App в свой HOC?

https://github.com/kirill-konshin/next-redux-wrapper#getserversideprops через HOC + обертку для getServerSideProps

А зачем переходить по страницам во время рендеринга страницы на сервере?

Вы, очевидно, не понимаете механизм работы. Пользователь зашел на страницу, она отрендерилась на сервере, redux state был доставлен на клиент, пользователь взаимодействует со страницей, меняя стейт, и затем уходит на другую страницу, которая тоже рендерится на сервере, новый стейт с сервера нужно правильно объединить с клиентским.


до тех пор пока левая пятка мэйнтейнеров не захочет это исправить

Я мейнтейнер, пока таких проблем не возникало и не думаю что возникнут. Опять таки, это опенсорс, вам надо — идете и меняете, PR принимается, все довольны, или делаете форк, и вообще никого ни о чем не спрашиваете.


я считаю что сторонние библиотеки, влияющие на архитектуру нужно привлекать с крайней осмотрительностью

И Next и Redux тоже когда то были значительно менее распространены. У библиотеки сейчас 11 тыс использований и 105 тыс скачиваний в неделю, люди активно пользуются и довольны. Повторяю, не хотите — не используйте, пишите все сами. Авторы Next в каждом релизе вносят что-то несовместимое со старым, это по-вашему тоже опасная завязка и тупиковый путь?

достаточно чуть-чуть модифицировать файл в котором создаётся store и просто импортировать экземпляр хранилища напрямую из этого файла

Это не так, все гораздо сложнее, т.к. store надо правильно гидрировать, не пересоздавать стор на переходах страниц и тд. Посмотрите код библиотеки, там много edge cases которые вы будете решать самостоятельно, и по сути просто перепишете ее заново.


На данный момент годы идут, все продукты развиваются и библиотека развивается вместе с ними. Если вас смущает vendor lock — не пользуйтесь, но вы тогда останетесь со всеми проблемами один на один. Если по такой логике действовать — то вы ни одну библиотеку не должны использовать. Ни next, ни redux. А чтоб подлить масла в огонь еще грядут server side components в самом реакте.

Ага, они вместо устаревшего getInitialProps ввели два getStaticProps и getServerSideProps. Описанная выше библиотека все это поддерживает. В чем тупиковость?

Это 50 китайцев и там как раз MobX. Вот и верь в совпадения — вы в точности угадали к чему были мои доводы ;) справедливости ради, там часть многостаночники, и тесты пилят и инфраструктуру, но людей реально много задействовано. И темпы разработки высокие. Да и сам Slack не так уж мал, 5ю точно не обойтись, там много фич, которые не сразу видны.

Соглашусь. В командах часто смешанный состав, есть мидлы, есть синьоры, есть новопришедшие, которые в глаза проект не видели, есть текучка, и когда набирается человек 50 — выбор инструмента критически важен, т.к. если выбор верный, люди будут быстрее вникать и меньше создавать случайных проблем.


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


Я не теоретизирую, а сужу по практике — у нас в компании два продукта: грубо говоря аналоги Slack и Zoom. Там и там по много людей. Один на MobX, другой на Redux. Оба весьма неплохо справляются со своими задачами. У обоих есть сложности.


Не нужно всех подряд винить в кривых руках. Инструмент надо выбирать так, чтоб плыть в потоке, а не бороться с ним на каждом шагу.

И? В чем проблема то? Причем тут Apollo или GraphQL?

При том что он под это заточен, т.к. это хранилище структурированных связанных данных, а не просто клиентский стейт (который туда тоже можно положить, но я не только про это).


батчинг без костылей

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


Это же элементарщина

А если добавить в уравнение наличие БД на клиенте для оффлайн режима? А если пагинация бесконечная и по миллионам записей, с прыжками в любое место? И сначала данные надо забирать из одного места, и подтягивать из другого. Data retention писать надо...


большое приложение вы не построите. — серьезно?

Ну, попробуйте построить приложение размером со Slack (и с функциональностью как в Slack), и вы поймете. У меня такое в наличии есть, 50 разработчиков обслуживают. На MobX написано. И не дураки писали. Но проблемы есть в любом туле.


Вы меня не совсем слышите, похоже. Я говорю про то, что Apollo это, конечно, в первую очередь решение для работы с данными с сервера и локальными. И туда, в принципе, можно добавить и часть клиентского стейта, он переварит. Мой посыл в том, что не надо тащить MobX куда ни попадя, местами и редакс и плейн-ванилла и хуки справятся ничуть не хуже. Дифференцированный подход надо применять.

Вы зря за меня додумываете. "мысля по Redux'овски и передавая в компоненты ID'шники и потом выцепляете из стейта объекты по айдишника" — это дичь и я не знаю, зачем это пропагандировалось…


Просто если вы вынимаете из сервера объекты, особенно со связями, то вам волей не волей придется их складывать в хранилище. Это не имеет, конечно, смысла для простого сайтика, но если появляются серверные подписки (хотя и без них тоже, после определенной сложности UI) — надо чтобы UI был всегда консистентен, то вы переизобретете Apollo через MobX так же как парень в презентации переизобрел MobX через Redux.


Добавлю, что помимо консистентных апдейтов, когда не важно откуда пришел объект (пуш или загрузился с очередным фетчем), допустим, с юзером, у которого онлайн статус сменился — этот статус обновится на всем сайте везде, где видно, Apollo еще умеет оптимистичные апдейты, пагинацию, батчинг без костылей, и много чего еще, без чего по-настоящему большое приложение вы не построите.


Для синхронизации состояний клиента и сервера я лучше тула не видел. Чтоб вот взять и пользоваться без доделок.


Каждому интсрументу свое применение. Не стоит возводить какой-то один тул на пьедестал.

Зря вы так. Чем MobX — человеческое место, а Apollo Cache нет? Нормализованный, удобный, с подписками. Это не стейт менеджмент, это хранилище объектов в первую очередь. Барахло из REST туда класть тоже весьма удобно. Вы перед укладкой в MobX данные нормализуете же? Чтоб при получении с сервера нового объекта везде юайчик обновился и вот это все?


Так почему бы не использовать сразу два инструмента? Объекты, нуждающиеся в синхронизации с сервером (REST/GraphQL не важно) — в Apollo, а клиентский стейт — в MobX. Только в таком случае правда велика вероятность, что все, что может MobX можно сделать на хуках и контексте...

Я прямо удивлен, что и в статье и в комментариях нет ни слова про Apollo Client (хотя комментаторы упомянули GraphQL).


Да, это GraphQL и самые большие бонусы будут именно когда надо данные с сервером синхронизировать и сервер на GraphQL, но тем не менее — Apollo Client это же по сути и есть набор нормализованных сторов с подписками и кучей магии для упрощения работы...


https://www.apollographql.com/blog/the-future-of-state-management-dd410864cae2/ вот статья. В 3ей версии особый упор на работу без сервера. А учитывая, насколько несложно можно написать GraphQL обертку над REST — настоятельно рекомендую в эту сторону посмотреть.

А как насчет сравнить с конкурентами GoPro Max, Insta 360 One X, Insta 360 One R?

Прошу прощения, но это у вас неверные сведения. Web Components — это Living Standard, реализованный на уровне браузера. Import Maps — not a W3C Standard nor is it on the W3C Standards Track. На сайте красным написано Unofficial Draft. В Бабеле все вещи минимум в драфте.


Более того, использование WC опционально, фреймворк и без них работает.

Самая главная проблема с импорт-мапами, даже со скоупами, в том, что хост обязан все знать про все модули, приложения, по всей видимости, могут догружать свои импорт-мапы но кто будет следить за чистотой, чтоб не было коллизий, и за оптимальным использованием версий и тд. Федерация поддерживает семвер например.

Tobias Sokra, если честно больше похожа на выкрик, импорты плохо, а вот наша штука лучше

Полифил непринятого стандарта — это стремно. Вебпак давно зарекомендовавший себя инструмент, так что автор прав, ни одна серьезная компания на импорт-мапы пока не подпишется.


Использование es модулей подразумевает под собой использование http2, server push и тому подобное

Про HTTP2 я еще у себя в статье писал.


худшее сжатие, вы про tree shaking?

Крупные куски сжимаются лучше чем много мелких.


если я правильно понял как работает Module Federation

Не правильно, см презентацию https://github.com/sokra/slides/blob/master/content/ModuleFederationWebpack5.md — это живая система, а не "хоровой деплоймент".


да читал, и решения засорять глобальную область видимость через сервисворкер так себе

Это ж эксперимент, в котором по условиям нельзя было применять никакую сборку.


в вашем случае получаеться аффектиться сборка основного приложения с зависимостями

Вовсе нет. Хост разглашает, что у него есть, приложения — что нужно им и что есть у них, все это максимально развязано. В крайнем случае скачается несколько раз.

Процитирую разработчика Webpack — Tobias Sokra:


No billion or trillion dollar company will use that. Import maps will realistically take 5 years to gain enough browser support to be used. It's like depending on polyfills to things that do not exist. Production code depends on a shim ultimately worse perf. Even when import maps come out, so what. Something still needs to append them to the page. Who cares if its script or something else, webpack will still need to manage it at scale and you still need tree-shaking. Plus import maps only “share”code if the path is exactly the same. Making it still no good and not near a replacement.

Еще добавлю отсутствие версионирования зависимостей, поддержку только JS модулей (без CSS и тд), повышенную нагрузку на сеть по кол-ву запросов и худшее сжатие. У меня была статья https://habr.com/ru/post/474672/ — import maps еще очень далеко до реального применения.

Я и говорю, повезло. А может и не повезти. Я регулярно встречаю странные поставки без ES6 и в UMD без бандла...


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

Information

Rating
Does not participate
Location
San Francisco, California, США
Date of birth
Registered
Activity