Pull to refresh
4
0
Белугин Павел @firstpasha

Пользователь

Send message
Я тут свои ощуения разделяю на 3 части.
1. Апатия: Выбор каждого, как и чем пользоваться, не нравится redux, выбирай что нравится.
2. Смерение: Не будешь сейчас использовать redux, можно даже не расчитывать на достойные предложения о работе, случись то, то что нужнен реальный опыт использования.
3. Страх: Сбербанк задумался над использованием в своих решения. Сколько уже стартануло проектов? Уверены ли мы, как индустрия, что это именно то, что нужно?

Так получилось, что мы самое свободное и децентрализированное сообщество программистов. Наверно это не удивительно, учитывая всю историю web. А с другой стороны наш «frontend» ещё младенец, по сравнению с другими стеками технологий. Значит ли это, что просто нужно подождать и переболеть всеми полурешениями? Лично мне кажется, что стоит заглянуть в родственные стеки используемых в Android, iOS приложених перед которыми стоят похожие проблемы и проанализировать как они решили их.
1, 2, 3.
4 — бось в отсутсвии стандартизации, мы можем под эту гребёнку можем привести всё.
Мне кажется, что вы делаете ошибочные выводы.

Ради этого мой пост и существует, поделиться мнением, возможно дать пищу для ума, возможно узнать для себя что-то новое — изменить мнение.

Управление состояниями, а полноценная база данных не решила бы этот вопрос?
Диспетч событий экшенов, почему бы не использовать шаблон наблюдатель?

А не думаете, что причиной появления надстроек является расширяемость Redux?

Я бы согласился с Вами, если бы эти надcтройки занимались расширением функционала, но по факту, это просто автоматизации рутинных процессов или внесения конструктива в синтаксис, предлагаемый из коробки.

Но чего у redux не отнять — это middleware, вот они просто супер, хоть и нарушают в текущем виде SOLID.

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

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


И вот redux чистом виде, на мой взгляд, не удовлетворяет этому. Redux слишком низкоуровнев.
Да, сообщество уже создало множесто решений для упрощения работы, и коллеги выше привели часть из них, но не делает ли это проблему ещё более насущей?
А если интсрумент плох, имеен ли смысл его использовать только потому что он захайпился?

С таким же успехом можно сравнить и vuejs. (сравнивать с angular1 — это не справедливо)

К сожалению, с vuejs знаком только в формате демок, в реальном приложении ещё не довелось использовать, но то что я для себя вынес — vuejs на одном уровне с react, тогда когда angular1 ~= (react + redux) — (routers + ...). И я не в коем случаи на сравниваю react с angular1, извиняюсь, если ввёл Вас в заблуждение.
Извиняюсь за то что ввёл в заблуждение, равнозначность о которой я говорю — это равнозначность функционала, а не равнозначность архитектуры.
О том и речь, что в чистом виде, работа с redux сложна неэффективна.
Это и является причиной появления надстроек над самим redux, что опять же подчёркивает проблематику.
Пара вопросов, для ответа по желанию:
1. Если инструмент не эффективен, зачем он нужен? Ради себя самого?
2. Как вы пришли к использованию redux? Какие проблемы Вашего приложения он решал?
Зато, привлекает внимание.
Боюсь с Вами не соглашусь
Ваша табличка ну вообще ничего общего не имеет с реальностью.
. Количество действи для достижения успеха явно разнится.

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

А бывало ли у Вас такое, что вместо создания новой цепочки action -> actionCreater -> case in reducer, Вы писали более общий action и универсально его использовали, просто для экономии душевных сил и скорости разработки приложения?
В чём-то с Вами согласен, вот особено с этим — http://xkcd.ru/927/.
К сожалению, не разделяю Вашего оптимизма по поводу redux, единственный и самый важный для меня фактор, это просто, а следовательно скорость разработки решения. С redux это увы не так.

Вопрос, если Вас не затруднит, используете ли Вы придуманные авторами redux способы или используете сторонние решения для:
создания action'ов?
создания actionCreater'ов?
создания бизнес логики?
Как Вы получаете данные из состояния?

Как Вы думаете, чем отличается «событийная система» redux, от скажем EventEmitter, чем она лучше?
Смотрели ли Вы на MobX?
Да, Вы абсолютно правы, это моя истерика, не более того.
Увидел статью и пришла мысль. Так получилось, что я «frontend» разработки, который от скуки поступил на курс по android разработке в Иннополисе. Может пописать блог об ощущениях с полей (начался он вчера)? Будет интересно такое кому?)
а я тут эксперементирую на досуге с разделением управления данными, бизнес логики и отображением: https://www.npmjs.com/package/react-component-redux

Ох, вообще печально это всё.
Я с webpack'ом довольно поверхностно знаком, но как я понял web-server на себя берёт все эти задачи.

Вероятно к нему также можно прикрутить плагины/middleware'ы, или нет?
).
Вообще, за последние дни появилось мнение, не является ли browserSync устаревшим. Возможно стоит портировать на webpack, к его дев серверу?
Благодарю!
А какое у Вас мнение о самом инструменте?
2

Information

Rating
Does not participate
Registered
Activity