Pull to refresh
108.7
Karma
0
Rating
Кирилл Коншин @dfuse

Principal Software Developer

  • Followers 41
  • Following 19

FoMO — Fear of Missing Out: определение конструкции, теоретические обоснования и обзор литературы

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

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

Как не спалить закладку полиции?

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

Создаем изоморфное/универсальное приложение на Next.JS + Redux

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

Создаем изоморфное/универсальное приложение на Next.JS + Redux

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

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


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

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


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

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


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

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

Создаем изоморфное/универсальное приложение на Next.JS + Redux

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

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


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

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


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

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

Создаем изоморфное/универсальное приложение на Next.JS + Redux

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

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


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

Создаем изоморфное/универсальное приложение на Next.JS + Redux

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

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

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

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

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


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


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


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

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

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

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


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

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


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

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


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

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


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

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

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


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


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


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


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

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

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


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

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

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


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


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

Камера RICOH Theta Z1 — панорамная съёмка на профессиональном уровне

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

Web Apps: Micro Frontend фреймворк с поддержкой Module Federation

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


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

Web Apps: Micro Frontend фреймворк с поддержкой Module Federation

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

Web Apps: Micro Frontend фреймворк с поддержкой Module Federation

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

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


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

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


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

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


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

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


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

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


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

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

Web Apps: Micro Frontend фреймворк с поддержкой Module Federation

Процитирую разработчика 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 еще очень далеко до реального применения.

React и Vue без npm и сборки

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


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

React и Vue без npm и сборки

Да, читаю, я отредактировал коммент, вы правы, а я нет (по части переписывания путей)


Во-вторых, UMD — это формат самодостаточного бандла, готового к подключению на страницу тэгом script

Это не так. UMD — обертка, она может иметь прописанные package identifiers и обращения к global scope в качестве фоллбэка.


UMD не равно bundle со всеми зависимостями. Реакт же не отрезолвился вообще https://unpkg.com/react@16.12.0?module (ссылка сгенеренная Unpkg). А Вы читаете, что вам пишут? )))

Information

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