Вот действительно подтверждение того, что для расцвета безумия нужно лишь чтобы умные молчали.
Скоро, наверное, кино снимут, как была придумана «архитектура» Redux и как она повлияла на мир…
Если честно, то статья является лучшей, которую я читал на хабре (в моей ветки) за очень долгое время.
И не смотря на то, что её уровень сравним с начальным, она легко читается и очень информативна.
Если человек работающий с данными не знает что их можно фильтровать, то ему действительно будет очень полезна эта статья. А в остальном объектно реактивное программирование, это настолько же глупо звучит, как например объектно событийное программирование. Но если второе уже все понимают, то это не значит что более понятно было бы объяснять это как парадигму, максимум архитектура. Зачем все усложнять. Это всего-навсего несколько шаблонов проектирования, которые выполняют команды, которые теперь называют операторами, которые в свою очередь выполняю задачи, которые здесь называют просто функции.
И на мой взгляд если действительно понимать о чем идет речь, то за подобный объем можно четыре раза рассказать ИСЧЕРПЫВАЮЩЕ что это такое.
И о чем статья-то? Мне нужно отфильтровать данные, но это вообще невозможно и все ужасно! Поэтому я применяю реактивный подход, фильтрую и все здорово! Резюме — реактивное программирование, это спасение. Вопросы?
Вот что такое реактивный подход в однопоточном js программировании?
Когда человек только приходит в frontend, особенно, если это его первый язык, который работает с ui, то он удивляется, как просто с помощью html тегов сделать список, добавить картинки и кнопки и при просмотре уроков уже прикидывает, что он скоро сделает. И вот он содится писать свое первое творение и застывает с глупым выражением на лице, ведь он даже не знает с какой стороны подступить раздувающемуся коду (события, подписка-отписка и прочие), а в конце ещё приходит осознание что нет ни единой мысли, как сделать слайдер или карусель.
Тогда на помощь приходит jQ, которая делает реально огромную работу за программиста, а главное делает её легкой.
Потом, уже закореннелые новички читают о фраймворках и выбирают реакт! Молодцы! Искренне. Они его открывают и точно так же как и в первые моменты своего начала, они сидят с отрешенным выражением лица не зная что делать. И тут приходит человек, говорящий и показывающи-тыкающий носом, как нужно написать приложение с помощью Redux. Все обожествляют творца вначале, а тех кто его критикует — минусуют и банят!
И вот пролетает ещё полтора года и человек пишет подобное.
Но это не из-за того что создатель Redux плохой, или из-за того что реакт кривой или ещё что-то…
Дело в том что ДАЛЬШЕ никто носом не тыкает! Ведь если разобраться, редакс, это только малая часть архитектуры, которая нужна в реальности. Просто те кто это знает не говорит об это из-за тог что их когда-то за подобное забанили или по каким-то другим причинам. а в большинстве случае и не знают, так как реакт вообще не очень полюбили те, кто реально знаком с архитектурой.
Поэтому остается только ждать, пока подрастет коммунити реакта и начнет учит-вести за ручку, погружая в архитектуру, в которой редак является лишь одним кирпичиком огромного minecraft.
Это получается что учить js друзьям не советовать? Если такие разговоры пошли, то лет через пять, после внедрения wasm js просто уйдет в небытия, ведь на любом языке можно будет писать программы для браузера и самое главное, что это будет легально и более того, знать нативный js, как в случаи с препроцессорами, уже не нужно. Кто тогда лидирует, c#?
Когда делаешь интерфейсы с сотней items в массиве, то может показаться забавным, что алгоритмы по изменению массивов с данными о пикселях с применением цикла for могут дать ну очень существенный прирост. Так к примеру на минимальном разрешении 1024х768 массив имеет длину в 786432 элементов, а итераций для изменения может достигать тоже очень много. поэтому заявления что for это ошибка, ошибочно! Ну а использовать рекурсию вместо циклов, если даже рекурсию сделают по скорости выполнения равной циклам, то лично мне было ну очень сложно начать программировать с использованием рекурсий. К слову, кто-нибудь замерял скорость хвостовых рекурсий vs циклы?
И я думаю что не у меня одного так, но у меня не бывает ошибок с this. Да когда-то были, но из-за отсутствия статической типизации ошибки, опечатки и прочее бывают до сих пор. Поэтому this ну не самая страшная ошибка.
Если честно то вчера я не особо всматривался в код, а сегодня пробежал и могу сказать что это вполне нормальный код. Если бы Вы писали на react или angular2 (Вы на них пишите?) то подобный код лицезрели бы в каждом своем продакшен проекте. Это результат сборщиков, которые призваны имитировать пока ещё недоступные вэб компоненты, а именно области видимости. Так же подобные классы отражают суть бэм хоть и не полной мере, но основная цель ускоренная загрузка сохранена. Я подобными сервисами не пользуюсь, но Вы пользовались и должны знать, это код для продакшен или у подобных сервисов нет разделения на продакшен и дев?
Ну по поводу технологий В ыглубоко ошибаетесь, но забудем об этом, это уже дело религии.
А вот сервис реально классно выглядит. Не увидел английского, но он наверное есть, ведь кто будет на русском стили писать :) И больше не знаю что сказать… Реально удачи и развития. Мне кажется что он может принести людям счастье.
К сожалению ничего нет по данному запросу, но и ладно… А Вы как кто делаете сервис? Я видел редакторы от дизайнеров и от программистов серверного кода, а вот от программиста ui нет. Даже самый лучший верстальщик не сможет сделать такой сервис, ведь он его будет делать как верстальщик. Вы когда-нибудь писали на c#, java ui-component? Это нужно обязательно чтобы понимать что такое и подобные элементы и как их нужно воспринимать в контексте компонентного построения доменных компонентов, которые отличаются от ui компонентов. Вы же это все знаете?
Представьте что Вы пишите сайты на bootstraз3. Вы из проекта в проект пишите один и тот же код и он никого не напрягает. А теперь представьте что Вы не руками набираете слово button, а перетаскиваете картинку с кнопкой, а вместо нужных атрибутов, ставите галочки в редакторе. Абсолютно ничего не меняет. Хотите сменить цвет, бордер или что-то ещё — изменяйте это в визуальном редакторе.
Видите, сложного вообще ничего нет, кроме как провести анализ имеющихся редакторов, выявить основные ошибки, понять почему они были допущены и на основе собранных данных собрать команду. Я уже много думал над этой темой и реально знаю решение, только это огромные затраты по времени, на которое нужны деньги. Ну а если в двух словах, то причиной отсутствия таких редакторов, это неправильно подобранные люди. Но совсем скоро эту проблему решат, по сути атмосфера уже сформировалась и возможно кто-то уже делает это.
Однозначно, причина плохого кода получаемого при конструировании сайтов плохие программисты.
Посудите сами, ведь многие пользуются компонентными фраймворками bootstra4, material-ui и им подобные и в них тоже код уже готовый, но они же хорошие, созданы правильными программистами. А в случаи с кодом показанный Вами программисты даже не знали о сборщиках и оптимизаторах, которые такой код превращают в правильный.
Но я уверен что рано или поздно правильная команда возьмется и сделает правильный и очень крутой редактор интерфейсов, это возможно и даже не очень сложно.
В java и c# классы принято называть как, если Page, то MainPage или SomePage, если Model, то UserModel или PostModel. Не понятно чем руководствовался автор, надеюсь что не css стилем.
Так же не совсем понятна мотивация складывать компоненты в папку components. Ведь все созданное на react по своему определению является компонентами. А желание привести код к повторному использованию должно подтолкнуть на объединение представления-реакт-компонента с логикой этого компонента. Только при таком раскладе можно перенести компонент без боли.
Так же личный опыт подсказывает, что все проекты уникальны и по сути из проекта в проект мигрируют только ui, которые и следует выносить в отдельный модуль или в случаи со сборщиками в отдельный бандл. А вот компоненты MainPage или PostPage, хотя я называю их MainRoute и PostRoute будут состоять из тех самый ui, а так же будут являться уникальными для конкретного проекта и даже не стоит забивать себе голову чтобы сделать их переиспользуемыми.
Компоненты React трудно использовать повторно в сложных веб-проектах.
Говоря о легком переиспользовании компонентов построенных с помощью полноценных архитектурных фраймворках, мы не берем во внимание что компонент является фасадом для маленькой-полноценной программы.
В случаи с реакт-компонентом это всего-лишь один маленький кирпичик, который если и будет являться частью некой архитектуры, то скорее всего она не будет заточена под переиспользование. По крайней мере мне известны лишь архитектуры для реакта, а не с использованием реакта. Ведь у того же angular именно компонент или ранее директива является точкой входа.
Исходя из этого было бы не оскорбительным сравнения компонентов архитектурных фраймворков с букетом, а реакт-компонентов с маленькой клумбой.
Я только и занимаюсь разработкой очень сложных интерактивных интерфейсов, поэтому могу не кривя душой сказать что реакт не предел мечтания, но у меня не хватило бы фантазии провести параллель между реактом и асинхронных запросов к серверу. И раз уж заговорили о асинхронности, которая видимо сложно кому-то дается, то лично для меня она не представляет какой-либо сложности, так как для меня этот диагноз врожденный.
Что касается известных мне архитектур, то как наверное большинство я начинал с обычной архитектуры на подобие mvc своими руками, затем перешел на redux, не всегда был им доволен и часто ворчал. В последнем, очень сложном проекте, я встал перед выбором либо вообще отказаться от redux либо поностью нарушить все его принципы. Я выбрал первое и это избавило меня от проблем которые и привели к отказу, но сам не верю что говорю эти слова, именно после отказа я по настоящему полюбил redux. Мне было с ним не всегда хорошо, но и без него мне лучше не стало.
Скоро, наверное, кино снимут, как была придумана «архитектура» Redux и как она повлияла на мир…
И не смотря на то, что её уровень сравним с начальным, она легко читается и очень информативна.
И на мой взгляд если действительно понимать о чем идет речь, то за подобный объем можно четыре раза рассказать ИСЧЕРПЫВАЮЩЕ что это такое.
Вот что такое реактивный подход в однопоточном js программировании?
Тогда на помощь приходит jQ, которая делает реально огромную работу за программиста, а главное делает её легкой.
Потом, уже закореннелые новички читают о фраймворках и выбирают реакт! Молодцы! Искренне. Они его открывают и точно так же как и в первые моменты своего начала, они сидят с отрешенным выражением лица не зная что делать. И тут приходит человек, говорящий и показывающи-тыкающий носом, как нужно написать приложение с помощью Redux. Все обожествляют творца вначале, а тех кто его критикует — минусуют и банят!
И вот пролетает ещё полтора года и человек пишет подобное.
Но это не из-за того что создатель Redux плохой, или из-за того что реакт кривой или ещё что-то…
Дело в том что ДАЛЬШЕ никто носом не тыкает! Ведь если разобраться, редакс, это только малая часть архитектуры, которая нужна в реальности. Просто те кто это знает не говорит об это из-за тог что их когда-то за подобное забанили или по каким-то другим причинам. а в большинстве случае и не знают, так как реакт вообще не очень полюбили те, кто реально знаком с архитектурой.
Поэтому остается только ждать, пока подрастет коммунити реакта и начнет учит-вести за ручку, погружая в архитектуру, в которой редак является лишь одним кирпичиком огромного minecraft.
И я думаю что не у меня одного так, но у меня не бывает ошибок с this. Да когда-то были, но из-за отсутствия статической типизации ошибки, опечатки и прочее бывают до сих пор. Поэтому this ну не самая страшная ошибка.
А вот сервис реально классно выглядит. Не увидел английского, но он наверное есть, ведь кто будет на русском стили писать :) И больше не знаю что сказать… Реально удачи и развития. Мне кажется что он может принести людям счастье.
Видите, сложного вообще ничего нет, кроме как провести анализ имеющихся редакторов, выявить основные ошибки, понять почему они были допущены и на основе собранных данных собрать команду. Я уже много думал над этой темой и реально знаю решение, только это огромные затраты по времени, на которое нужны деньги. Ну а если в двух словах, то причиной отсутствия таких редакторов, это неправильно подобранные люди. Но совсем скоро эту проблему решат, по сути атмосфера уже сформировалась и возможно кто-то уже делает это.
Посудите сами, ведь многие пользуются компонентными фраймворками bootstra4, material-ui и им подобные и в них тоже код уже готовый, но они же хорошие, созданы правильными программистами. А в случаи с кодом показанный Вами программисты даже не знали о сборщиках и оптимизаторах, которые такой код превращают в правильный.
Но я уверен что рано или поздно правильная команда возьмется и сделает правильный и очень крутой редактор интерфейсов, это возможно и даже не очень сложно.
Так же не совсем понятна мотивация складывать компоненты в папку components. Ведь все созданное на react по своему определению является компонентами. А желание привести код к повторному использованию должно подтолкнуть на объединение представления-реакт-компонента с логикой этого компонента. Только при таком раскладе можно перенести компонент без боли.
Так же личный опыт подсказывает, что все проекты уникальны и по сути из проекта в проект мигрируют только ui, которые и следует выносить в отдельный модуль или в случаи со сборщиками в отдельный бандл. А вот компоненты MainPage или PostPage, хотя я называю их MainRoute и PostRoute будут состоять из тех самый ui, а так же будут являться уникальными для конкретного проекта и даже не стоит забивать себе голову чтобы сделать их переиспользуемыми.
Говоря о легком переиспользовании компонентов построенных с помощью полноценных архитектурных фраймворках, мы не берем во внимание что компонент является фасадом для маленькой-полноценной программы.
В случаи с реакт-компонентом это всего-лишь один маленький кирпичик, который если и будет являться частью некой архитектуры, то скорее всего она не будет заточена под переиспользование. По крайней мере мне известны лишь архитектуры для реакта, а не с использованием реакта. Ведь у того же angular именно компонент или ранее директива является точкой входа.
Исходя из этого было бы не оскорбительным сравнения компонентов архитектурных фраймворков с букетом, а реакт-компонентов с маленькой клумбой.
Я только и занимаюсь разработкой очень сложных интерактивных интерфейсов, поэтому могу не кривя душой сказать что реакт не предел мечтания, но у меня не хватило бы фантазии провести параллель между реактом и асинхронных запросов к серверу. И раз уж заговорили о асинхронности, которая видимо сложно кому-то дается, то лично для меня она не представляет какой-либо сложности, так как для меня этот диагноз врожденный.
Что касается известных мне архитектур, то как наверное большинство я начинал с обычной архитектуры на подобие mvc своими руками, затем перешел на redux, не всегда был им доволен и часто ворчал. В последнем, очень сложном проекте, я встал перед выбором либо вообще отказаться от redux либо поностью нарушить все его принципы. Я выбрал первое и это избавило меня от проблем которые и привели к отказу, но сам не верю что говорю эти слова, именно после отказа я по настоящему полюбил redux. Мне было с ним не всегда хорошо, но и без него мне лучше не стало.