Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.
Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.
Мысли о том, какие требования выдвигает Redux, как задумано использование Redux и что возможно с Redux.
Я потратил много времени, обсуждая онлайн паттерны использования Redux, была ли это помощь тем, кто изучает Redux в Reactiflux каналах, дискуссии о возможных изменениях в API библиотеки Redux на Github'е, или обсуждение различных аспектов Redux'а в комментариях к тредам на Reddit'е или HN (HackerNews). С течением времени, я выработал свое собственное мнение о том, что представляет собой хороший, идиоматичный Redux код, и я хотел бы поделиться некоторыми из этих мыслей. Несмотря на мой статус мейнтейнера Redux'а, это всего лишь мнения, но я предпочитаю думать, что они являются достаточно хорошими подходами :)
Redux, в своей сути, невероятно простой паттерн. Он сохраняет значение, выполняет одну функцию для обновления значения когда это необходимо, и уведомляет любых подписчиков о том, что что-то изменилось.
Несмотря на эту простоту, или, возможно, вследствие ее, существует широкий спектр походов, мнений и взглядов о том, как использовать Redux. Многие из этих подходов широко расходятся с концепциями и примерами из документации.
В то же время, продолжаются жалобы на то, как Redux «заставляет» вас делать вещи определенными способами. Многие из этих жалоб на самом деле включают концепции связанные с тем, как Redux обычно используется, а не фактическими ограничениями наложенными самой библиотекой Redux. (Например, только в одном недавнем HN треде я видел жалобы: «слишком много шаблонного кода», «константы action'ов и action creator'ы не нужны», «я вынужден редактировать слишком много файлов чтобы добавить одну фичу», «почему я должен переключаться между файлами чтобы добраться до своей логики?», «термины и названия слишком сложны для изучения или запутанны», и слишком много других.)
Мы хотим создать пакет, который позволит нам избавиться от постоянного создания однотипных reducer'ов и action creator'ов для каждой модели, получаемой по API.
Первая часть — вот эта вот статья. В ней мы создали конфиг для нашего будущего пакета и выяснили, что он должен содержать action creator, middleware и reducer. Приступим к разработке!
Лишнее подтверждение тому, как стремителен мир JavaScript: всего лишь полгода назад, когда конференция HolyJS проходила в Москве, актуален был Angular 2, а теперь к петербургской успел выйти Angular 4. Будем считать, что существовал ещё и третий, но мы моргнули и пропустили его!
Раз всё так быстро меняется, то что было на самой конференции по сравнению с предыдущей? Как выступил именитый Дуглас Крокфорд? О чём были другие заметные доклады? Всё это — под катом.
Читать полностью »
Дмитрий Карловский из SAPRUN представляет… ммм...
Это — текстовая версия одноимённого выступления на FrontendConf'17. Вы можете читать её как статью, либо открыть в интерфейсе проведения презентаций.
Надоело.. | Чем поможет ОРП? |
---|---|
… писать много, а делать мало? | Пиши мало, делай много! |
… часами дебажить простую логику? | Реактивные правила обеспечат консистентность! |
… асинхронщина? | Синхронный код тоже может быть неблокирующим! |
… что всё по умолчанию тупит? | ОРП оптимизирует потоки данных автоматом! |
… функциональные головоломки? | Объекты со свойствами — проще некуда! |
… что приложение падает целиком? | Позволь упасть его части — само поднимется! |
… жонглировать индикаторами ожидания? | Индикаторы ожидания пусть сами появляются, где надо! |
… двустороннее связывание? | Двустороннее связывание нужно правильно готовить! |
… пилить переиспользуемые компоненты? | Пусть компоненты будут переиспользуемыми по умолчанию! |
… вечно догонять? | Вырывайся вперёд и лидируй! |
Сто тринадцать раз в секунду оно тянется, и достает все дальше. Если бы пришло подтверждение, сигнал — оно могло бы остановиться, и оно не останавливается. Оно тянется и находит всё новые способы. Оно импровизирует, оно изучает. Оно не сознает, что делает…
Джеймс Кори «Пожар Сиболы»
Вообще говоря, «сильный» игровой AI не является моим приоритетом. Глупо соревноваться со специализированными игровыми движками, занимаясь универсальным и имея лишь однопоточный JavaScript, встроенный в браузер, в качестве вычислительного ресурса. Кроме того, есть целый ряд игр, в которых потребности в сложном AI просто не возникает. Вот здесь, например, весь AI сводится к поиску кратчайшего пути, а в этой игре с задачей прекрасно справляется рандом. Увы, такие игры скорее исключение чем правило. Гораздо чаще, приходится изрядно потрудиться, чтобы программа делала ходы, которые не казались бы попросту идиотскими.
Читать полностью »
На дворе 2017 год, а это значит, что я уже как полтора года занимаюсь мазохизмом.
Два года назад я был весел и жизнелюбив, сейчас не хочется ни шутить ни развлекаться. За два года redux сделал меня фаталистом. Моя уверенность в ужасном будущем так называемого “frontend” увеличивается с каждым днём. В конце концов, сбербанк сделал redux основой своего стека, а эти ребята хорошего не выберут. Шутка! Я уверен, там работают замечательные специалисты.
Читать полностью »
Здравствуйте, дорогие читатели! В этом посте я хочу рассказать о том, как и в какую цену я заказывал сайт у фрилансеров, в какие сроки я получил результат и что из этого сделал сам. Задача была создать “лендинг-магазин”: одностраничный сайт для двух товаров, с возможностью сразу же сделать заказ через полнофункциональную корзину.
Этот пост содержит совсем немного технических подробностей и рассказывает больше о рабочем процессе и взаимодействии с людьми.
Я начал изучать React и Redux не так давно, но он уже успел изрядно потрепать мне нервы. Буквально над каждым действием приходится задумываться — почти никакие изменения в коде невозможны без того, чтоб что-то оторвать. Чтоб просто получить список постов по API и вывести их, надо, пожалуй, написать не меньше сотни строк кода — создать корневой контейнер, создать store, добавить action для запроса к API, для успешного результата запроса, для неудачного результата запроса, создать action-creators, сматчить action-creators и props, сматчить dispatch и props, написать reducer на каждый action… Ух, продолжать не хочется. И все это мы должны делать заново для каждого веб-приложения — крайне нерациональная трата сил программиста.
Да, можно сказать новичку: "Смотри, тут десяток пакетов, которые могут сделать каждое действие из этого списка вместо тебя. Выбирай и пользуйся!" Но проблема в том, что надо разобраться в настройке и воспользоваться десятком пакетов, позаботившись о том, чтоб они совпадали с версией, которая описана в документации и не вступали друг с другом в конфликты… Слишком сложно. Хочется чего-то проще, такого же простого, как в мире Django, из которого я пришел. Какой-то один пакет, после установки которого в store сами по волшебству складываются все нужные данные — бери и пользуйся.
Ну, я и решил — если такого решения нет, напишу-ка я его сам.
Убирая всю лирику из первого абзаца, получаю задачу — нам нужно создать инструмент, который будет:
По описанию выходит, что состоять пакет будет из action creator'а, middleware и reducer'а.
Речь в данной статье пойдет о довольно необычном сочетании технологий: Vue.js + TypeScript + Webpack, в разрезе single-file компонентов. Решение данной задачи отняло у меня приличное количество времени с первого захода, поскольку исчерпывающее объяснение того, как использовать все это вместе, да и еще с рядом ограничений (NPM предоставляет нам runtime-only build Vue.js), найти в цельном виде практически невозможно. Если вас заинтересовала данная тема, то приглашаю к дальнейшему чтению.
Читать полностью »