Как стать автором
Обновить
14
Карма
0
Рейтинг
Иван Ганев @IvanGanev

Веб разработчик

  • Подписчики 25
  • Подписки 16

Инженер Google раскритиковал Apple за торможение развития веб-технологий

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

Flutter вот-вот завоюет Web

+ к тому же сам по себе современный подход к разработке — при помощи Компонентов, концептуально очень схож с подходом по разработке при помощи Виджетов.

React Server Components — что это?

Реакт это библиотека для разработки интерфейса. Это не фреймворк, это не генератор сайтов, на одном реакте даже PWA не сделать — нужен хотя бы react-dom, хотя если посмотреть на зависимости create-react-app — там еще куча всего для того что бы сделать веб приложение (это при том что в cra даже нет роутера).

Требовать от реакта что бы он решал проблему обхода приложения ботами — это в целом требовать кардинальной смены подхода того как реакт и его экосистема вообще устроены. С такими предложениями вам не в комментариях на хабре нужно писать, а писать более чем обоснованные предложения команде реакта на гитхабе.

React Server Components — что это?

Проблема индексации это не та проблема которую реакт вообще должен решать. Если нужна «классическая» индексация поисковиками — юзайте next, gatsby и тд.

Как управлять состоянием React приложения без сторонних библиотек

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

Как управлять состоянием React приложения без сторонних библиотек

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

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

Как управлять состоянием React приложения без сторонних библиотек

1) во первых, почему вы хотите юзать для этого именно глобальное состояние? Почему бы не юзать состояние более высокого уровня?

Но важно да же не это — если вы хотите сохранять данные юзера, то не надо юзать для этого стейты — они вообще не для этого созданы. Стейт это состояние интерфейса, а не инструмент для сохранения данных.

В данном случае — сохранения данных при рефреше логичнее было бы заюзать localStorage браузера.

Как управлять состоянием React приложения без сторонних библиотек

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


В каких стилях? Можно задавать стили через пропсы, передавая в эти компоненты что нам нужно. Но вообще, в любом случае зачем:

А если бы у них был глобальный стейт типа `elements: [{ left, right, width, height }, ...]`, то это можно было бы сделать динамической формулой и гибко задавать условия взаимного расположения и интеракций.


вообще нужно делать этот стейт глобальным? Почему не обернуть в контекст провайдер компоненты? Хотя в данном случае вообще было бы достаточно сделать компонент со стейтом, внутри которого и использовать эти элементы. Вообще не понятно для чего тут нужна глобальность.

Чтобы наглядней — эта управляющая кнопка далекооо, в компонент Notifications / Gallery ее не поместить.
ну и не помещайте, данный способ не запрещает использовать любой уровень иерархии, включая глобальный.

Так что «чем более независимыми являются компоненты — тем, как правило, лучше» — однозначно нет, не лучше.


Документация Реакта: «Компоненты позволяют разбить интерфейс на независимые части, про которые легко думать в отдельности.»

«Вам не нужно состояние какой-то отдельной формы на глобальном уровне» — в основном как раз нужно.
Зачем? Конечно такие кейсы возможны, но было бы интересно узнать при каких типовых сценариях это может пригодиться.

Нет, только в одном, никакой синхронизации не требуется.
Вы же сами и говорили что: «а вот для фронтенда это — антипаттерн, так как интерфейс в каждый момент времени — цельная система, а синхронизация состояний — ключевой момент.»

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

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

И думать о каждом из них можно как об изолированном блоке, просто не надо думать об иерархии и делать массу импортов.
Да, так можно делать, но на мой взгляд это просто путь к описанному в статье варианту. Единый стор -> много централизованных сторов -> сторы разнесенные по приложению в соответствии с его бизнес логикой. Ментально это более простой способ мыслить о таком подходе если до этого приходилось работать только с централизованными состояниями.

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

Как управлять состоянием React приложения без сторонних библиотек

а вот для фронтенда это — антипаттерн, так как интерфейс в каждый момент времени — цельная система,


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

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


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

Что мешает сделать один StateProvider, и внутри компонентов выбирать нужную его часть?


Ну, так сейчас большая часть Реакт разработчики и живет — ведь это же все тот же Редакс без редакса. При едином стейте вам нужно применять какой-то подход к центральному состоянию, и каким будет этот подход? Скорее всего это будет что-то редаксо-подобное. Если не применять никакого подхода то очень скоро этот стейт превратиться в ад.

Импортов и кода меньше, возиться с уровнями и отсутствием проброшенного не нужно. А внутри стора можно как угодно скомпоновать логику и методы, удобно разбив по нескольким файлам.


Идея в том чтобы разделять код с большим соответствием бизнес логике — думать не о том что это редюсер, это экшен и тд, а думать о конкретных стейтах. Это провайдер меню, это провайдер формы и тд, прописывая именно в них нужную логику, а не разделять по разным файлам. Это очень похоже на компонентный подход, но вместо компонентов — стейты. Веб разработка не просто так ушла от разделения на html/css/js к компонентному подходу, где у каждого компонента свои стили, логика и тд.

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

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


Что значит «обкладывать» — нам нужно заюзать тот же useMemo (или что угодно еще) в одном месте — в файле контекста, и мы оптимизируем это везде где используется этот контекст.

И да, сам по себе такой подход и приводит к оптимизации — разделяя контексты, вызовы ререндеров будут происходить только при изменении на уровне этого контекста или ниже, Реакт не вызывает ререндер на более высоких уровнях иерархии если изменения произошли на более низких (не важно юзаем мы контексты или проп дриллинг) — нужно стремиться размещать провайдеры/контексты/стейты как можно ниже по иерархии, благодаря чему Реакт, частично, оптимизирует это все сам. А вот если мы запихнем все состояние в один глобальный стейт — у нас начнутся проблемы с оптимизаций. Вот другой мой перевод Кента где подробнее про вопросы оптимизации — habr.com/ru/post/485032

Как управлять состоянием React приложения без сторонних библиотек

А если все делать через кучу провайдеров — так зачем заменять единый стор и SSOT на кучу разных «сервисов». А если они ещё друг от друга будут зависеть, уххх.


Чем больше провайдеров, тем, следовательно, и альтернативный вариант с единым стором будет сложнее. Единый стор не будет проще просто из-за того что это единый стор.

Типа как в примере автора — прилетит «хотим при логине показывать нотификацию». Оу, сорян, у нас нотификейшн провайдер ниже аутентификационного.


Поднять провайдер не проблема. Хотя в этом случае можно сделать новый провайдер (специально для этого нотификейшена) или добавить это в логику самого аутентификационного провайдера. Почему бы и нет? Сами по себе провайдеры могут иметь внутри сложную логику.

Form design patterns. Обзор книги

Проблема в том что такие формы уж очень сильно зависят от контекста. Формы регистрации везде примерно одно и тоже делают, а вот какими должны быть формы с специфической внутренней SaaS системы? Какова вероятность того что то что работает в одной сложной форме, будет работать в другой? Тут не обойтись книгой/статьей где просто показывают два примера и говорят «делай так, а не так». Это больше про подход к дизайну в целом, про проведение исследований (о том как и зачем вводиться информация в эти формы) и тд.

10 популярных вопросов на собеседовании по TypeScript (с краткими ответами)

Совершенно рандомные вопросы. Почему именно они были выбраны? Как будто кто-то просто наугад брал темы из ts документации.

Как сделать React приложение быстрее при помощи совместного размещения состояний

Смотря что вы имеете в виду под удобством. Давайте вообще забудем про производительность, оптимизацию и тд, и посмотрим на это исключительно с точки зрения удобства разработки. Есть у нас глобальный стейт который нужен везде, ну там, имя юзера, например — имя юзера отображается во всем приложении. Он глобален и его место, следовательно, в глобальном стейте. Мы просто не можем положить его куда-то ниже.

А есть какая-нибудь форма, значения которой вообще больше нигде не нужны. Зачем делать ее глобальной? Почему бы не держать ее стейты там же где находиться эта форма? Это не «размазывание» стейтов, мы просто держим стейты там где они и нужны. Стейты это же не какая-то абуза, это часть приложения, часть наших компонентов.

Это очень да же в логике самого по себе компонентного подхода, когда мы все держим «ближе к телу». Лично я предпочитаю всегда держать все что относиться к определенному компоненту как можно ближе к нему — стили, тесты, что угодно. Таким образом и работать с этим компонентом проще, ведь все что имеет отношение к этому компоненту не “размазано” по приложению.

Как сделать React приложение быстрее при помощи совместного размещения состояний

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

Как сделать React приложение быстрее при помощи совместного размещения состояний

Описанный в статьей метод прост в применении и не требует ничего кроме самого реакта.

Как использовать Инверсию Управления в JavaScript и в Reactjs для упрощения работы с кодом

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

Как использовать Инверсию Управления в JavaScript и в Reactjs для упрощения работы с кодом

Раз уж оставили ссылку, то поясните в чем ее смысл.

Карма — это отчуждение от авторства

Если бы тот кто ставит минус действительно хотел кого либо чему-то научить, он бы вместо этого написал сообщение. Ничего вменяемого в текстах с указанием причин минуса не будет.

Да же может хуже — там будут «вредные советы». Минус в карму это явный способ сказать — «уходи с хабра ты здесь не нужен», это же не способ чему-то научить, это легальный способ выжить человека с хабра, так что советы там буду те еще.

Главные технологии десятилетия по версии Хабра

В дополнительном списке есть GitHub, но нигде нет непосредственно open source, хотя в промежутке в десять лет именно опенсорс из чего-то второстепенного стал для мира ит ключевым аспектом. Да сам по себе опенсорс это не технология, а скорее подход, но тот же шеринг это то же не непосредственно технология.

В целом конечно составление подобных список задача Очень не благодарная, тут куча проблем еще на уровне определений. Лично я не представляю как и из чего можно составить подобный список. Можно было бы сузить все до уровня корпораций, условно говоря список компаний повлиявших на мир сильнее всего (не обязательно основанных в это время) — тут и для амазона с его aws место было бы, и для гитхаба и тд.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность