• Всё дело в Agile — 1: популярные мифы о гибкой разработке
    0
    Вспомнился отличный ролик по теме :))
  • Операторы ?., ?? и |>: будущие возможности JavaScript, которые вам понравятся
    0
  • Операторы ?., ?? и |>: будущие возможности JavaScript, которые вам понравятся
    0
    Вполне все «четко» выглядит, даже на Ретине.
  • Операторы ?., ?? и |>: будущие возможности JavaScript, которые вам понравятся
    0
    Поддерживаю полностью, первые два — приятный синтаксический сахар, а пайплайн — это прямо новая парадигма, по сути, API библиотек будут создаваться с учетом него, это круто.
  • Restate — или как превратить бревно Redux в дерево
    0
    Ну вы, по сути, на Redux и делаете фрактальный стейт (можно было об этом, собственно, явно в статье указать). Концептуально очень похоже на Fractal или cycle-onionify.
  • Фронтенд-2017: о самом важном
    0
    В отличие от Redux, MobX использует наблюдаемые объекты состояния, и API, основанное на принципах функционального реактивного программирования

    Ага, особенно «функционального» — в то время как MobX до мозга костей ООП (очень уж полагается на `this`) и предполагает больше императивный стиль, нежели функциональный :)
  • Фронтенд-2017: о самом важном
    0
    OCaml же, причем тут кофескрипт?
  • Анализ шести веб-фреймворков: плюсы, минусы и особенности выбора
    0
    И не просто можно — а нужно :)
  • Как библиотека MobX помогает управлять состоянием веб-приложений. Лекция в Яндексе
    +1

    Ну, MobX вообще не завязан на React технически — его можно хоть с Angular использовать или еще чем-нибудь. Если речь про официальный байндинг mobx-react — то он официально поддерживает React 16. Да ну и там нечему особо сломаться-то.

  • Angular vs. React vs. Vue: Сравнение 2017
    0
    Нет, все правильно, Redux — синхронный. Но вот экшены могут как угодно запускаться — это уже просто за пределами ответственности Редакса.

    Однако где-то это делать все же надо и тут — вариантов масса и тут VladVR неправ, что действие не может порождать действие — может (оба действия с соответствующим изменением стейта), вполне себе распространенный паттерн «process manager»/«saga», как раз для асинхронности. Везде есть свои нюансы, но совсем без асинхронщины/эффектов — никак в реальном приложении.
  • Как я перестал любить Angular
    0
    И еще более чем достойная альтернатива: github.com/FormidableLabs/freactal

    Вообще, тренд к «фрактальному стейту» идет — Freactal, Mobx State-Tree, cycle-onionify, Elm Architecture.
  • N причин, чтобы использовать Create React App
    +2
    Да вообще как здрасьте. Как вывести космический корабль на орбиту? Да все банально при любом раскладе — определить траекторию, спроектировать корабль (незначительная мелочь), построить его, запустить двигатели и произвести взлет.

    Конечно, Redux — не «rocket science», но за этим вот «выполнить экшены» — куча тех еще компромиссов и ухищрений.
  • N причин, чтобы использовать Create React App
    0
    Поддерживаю :) Ну, на самом деле велосипедов там нет, поскольку поддержка нулевая.
  • Введение в React и Redux для бекенд-разработчиков
    +1
    DOM является функцией от `props` компонента — в ней может быть намешано все, что угодно, хотя обычно бОльшая часть — да, из глобального стора. Вы так говорите, будто это что-то плохое :)

    P.S. Совершенно верно, редьюсеры можно использовать на любом уровне для любого стейта.
  • Введение в React и Redux для бекенд-разработчиков
    0
    Ну, скажем так, его задача наметить паттерн для этого (dispatch, actions, middlewares, reducers), но не обязательно предлагать непосредственный механизм для этого (вместо него — предлагается подключать что-то свое как middleware).

    UPDATE: Не то, чтобы это хорошо или плохо — с одной стороны, это дает больше гибкости, но с другой — все делают кто во что горазд :) Особенно когда сложность приложения выходит за пределы разумности применения простых вещей вроде redux-thunk (который, вроде как стартовая точка и он же — первый middleware, с которым все сталкиваются).
  • Введение в React и Redux для бекенд-разработчиков
    +1
    «Как минимум, MobX нормально оперирует привычными многим бэкендерам полноценными объектами, инкапсулирующими данные и поведение.»

    А кто сказал, что всем нужно именно это? Это просто другой подход. Просто mobx как решение и хранит состояние, и имеет весь инструментарий для его управления. Плюс реактивность MobX, но это немного другая тема.

    Redux же очень прост, но, по сути, действительно, умеет только хранить состояние, да и все. Ему нужно что-то, что будет поддерживать весь его (потенциально) навороченный стейт в порядке и согласованности. Причем, с ростом проекта, таких сценариев становится все больше, а они сами становятся все сложнее. Нужна асинхронность, опять же. Отсюда и появляются redux-saga, redux-observable (реактивные «саги»), сам я предпочитаю вообще Cycle.js использовать для подобного рода логики.

    Так что, тут просто разница подходов и, по сути, дело вкуса. Но почему то мне кажется, что Redux придется по душе многим, или даже большинству, именно из за своей прямолинейности и простоты.
  • Введение в React и Redux для бекенд-разработчиков
    0
    Это не редьюсер решает, а как раз тот самый «код композиции».
  • Введение в React и Redux для бекенд-разработчиков
    0
    Redux вообще не должен ничего «знать, чтобы диспетчеризовать». Его задача — только хранить состояние. У вас должен быть отдельный кусок программы, ответственный за перехват тех или иных action'ов и за то, чтобы на это как-то отреагировать (в том числе взять текущий стейт, проанализировать его и, вероятно, запустить какие то экшены).

    Ну нужно пытаться вешать на Redux то, что выходит за рамки его ответственности.
  • Введение в React и Redux для бекенд-разработчиков
    0
    Страница может быть какая угодно. Вопрос в том, какая именно, и какой уровень отзывчивости и интерактивности ваши пользователи ожидают. Оба подхода имеют право на жизнь, очень зависит от конкретного сайта/приложения и того, какие действия с его помощью производят ваши пользователи. Просто не надо все под одну гребенку и говорить, что перезагрузка страницы — единственный тру-способ работы с веб-приложениями.
  • Введение в React и Redux для бекенд-разработчиков
    0
    Ну, я именно это имел в виду под «хранением и управлением состояния». Надо было добавить «и корректному отображению всего этого на UI». И тут становится понятно, что и virtual DOM не просто так придумали и всякие другие штуки для этого — чтобы была возможна концепция «UI — это функция от состояния». Но автор комментариев выше настаивает на том, что все это не нужно, и я, наравне со многими другими, с этим несогласен :)
  • Введение в React и Redux для бекенд-разработчиков
    +2
    Ну, вы как-то даже и не хотите видеть каких-то преимуществ SPA-приложений (а люди с вами зачем-то спорят). Если вам хватает ваших инструментов — у вас же их никто не отбирает. У всех задачи опять же разные. Всякие чисто «хайповые» штуки со временем уходят или находят свою нишу, а вот полезные паттерны — остаются. Неужели вы думаете, что все и каждый вокруг вас — хипстер, которому нравятся модные словечки и использует такой подход только из за своей хипстеровости (есть такое слово?) :)

    Возьмем тот же Реакт и его серверный рендеринг — и вот вам вполне себе альтернативный вариант написать чисто серверный UI (можете даже не подрубать React на клиенте). Кому-то удобнее, кому-то нет, но это еще один полезный паттерн.

    document.querySelectorAll('.js-user-name').forEach(x => x.textContent = newName)
    

    Ну очень уж притянутый за уши пример. Вывести какой-то текст во все элементы с таким-то классом — элементарно. Во фронтенде реально сложно — хранить и управлять состоянием. Рендерить — чем угодно и как угодно — просто.
  • Введение в React и Redux для бекенд-разработчиков
    +1
    Ну, этот паттерн, который называют то «saga», то «process manager» — как раз об этом. Он описывает чистую логику, результатом которой являются те или иные «action»-ы. Тем самым хранилище состояния (Redux) только тупо хранит состояния и меняет его с помощью редьюсеров, а сама логика обрабатывается специализированными функциями.

    Тут не нужно придумывать отдельный паттерн для «бизнес-логики», чтобы как-то технически отделить ее от логики приложения. Просто не надо в кучу мешать (разные «саги», разные ключи в хранилище стейта, все такое).
  • Введение в React и Redux для бекенд-разработчиков
    +1
    А кто мешает применять DDD? Просто данные будут в сторе, а логика — отдельно — в функциях, сагах, и всяких таких штуках. Разделение ответственности же, до сих пор же идут споры о «правильном DDD» — никто не говорит, что для этого нужен один мутабельный объект модели для каждой сущности с методами поведения. Концептуально DDD никто не мешает использовать.

    P.S. На практике немного сложнее, в сторе обычно находятся не только данные «domain model», а куча разного рода другого состояния приложения.
  • Введение в React и Redux для бекенд-разработчиков
    +1
    Ну она синхронизирует текущую позицию в store и обратно — полезно для Time Travel, доступа к данным метонахождения через Redux, что позволяет компоненту в ряде случаев не зависеть от роутера. Но это совершенно точно не «альтернатива» :)

    (Более чем) реальная альтернатива react-router-у — junctions.js.
  • Опять асинхронщина на колбэках. В массивах
    0
    Они работают с единичными значениями «over time» — то есть, с течением времени. Вот и асинхронность. Никто не мешает сделать поток из массива и разом пустить его через цепочку операторов стрима. Получится своего рода «асинхронный массив» (хотя и не совсем, но результат, как мне кажется, будет именно тот, что нужен).

    Тут, собственно, весь вопрос сводится к тому, что именно вы хотите делать с массивами с практической точки зрения?
  • Опять асинхронщина на колбэках. В массивах
    0
    А какова должна быть практическая польза от этого дела. Еще не совсем понятно само определение «утечек», что это?

    P.S. Что-то мне подсказывает, что на самом деле вам нужны Observables — действительно мощнецкий инструмент для борьбы с асинхронностью. Посмотрите в сторону RxJS/xstream/most.js. Или я что-то упустил? :)
  • Управляем состоянием приложения с помощью Vuex
    0
    Совершенно верно. Только для этого вовсе не обязательно представлять экшены именно в виде стрима — просто последовательность экшенов, неважно каким образом запущенных. Стрим удобен для контекста (если хотите реактивный стиль), редьюсеру ж по барабану, как он там вызывается.
  • Управляем состоянием приложения с помощью Vuex
    +1
    Мутации — синхронные и чистые, редьюсеры, так сказать, или транзакции.

    А что значит «чистые»? В примере в статье меняется переданный в качестве аргумента объект — или под чистотой вы не имеете в виду «pure function»?

    И плюс, между мутациями и редьюсерами фундаментальная разница. Редьюсеры как раз-таки «pure», это чисто функции, они ничего не меняют, а возвращают новый стейт.
  • Умер ли MVC для фронтенда?
    0
    Есть альтернативное мнение, что модель должна быть исключительно тупой и в идеале вообще генериться автоматом на базе некого формального описания структуры данных.

    Так это и будут голые данные, зачем тут еще что-то «генерить»? (кроме как чисто какие-либо объекты ORM или вроде того — но это уже детали реализации).

    Придерживаюсь точки зрения, что модель — это данные плюс поведение (бизнес-логика), а не только данные.
  • Не убивайте свою мотивацию: осваивайте Ruby on Rails на интересных примерах
    0
    Rails вполне подходит для создания API, так что, пожалуй, и правда дело вкуса. В Штатах полно компаний и стартапов, которые сидят именно на Рельсовом стеке и вполне себе счастливы, даже несмотря на производительность Ruby (субъективное мнение — производительности бы Ruby, конечно, побольше, особенно учитывая, что здесь же под боком есть node.js, Golang, да и связка Elixir/Phoenix весьма активно набирает обороты). «Виной» тому как раз удобство и огромное количество наработок для всего и вся.
  • Async/await это шаг назад для JavaScript'a?
    +6
    У статьи, конечно, несколько громкий заголовок — async/await — вовсе не шаг назад, особенно если программировать в императивном стиле (а он именно для этого и появился — не все пишут в функциональном и/или реактивном стиле). Аргумент автора лишь в том, что когда привыкаешь к функциональному подходу, он сам по себе уже кажется чище и элегантнее.

    У меня async/await был самой ожидаемой фичей ES-Next, пока не пришлось столкнуться с Observables :) Теперь async/await, в общем-то, не у дел, но это и не значит, что он плох.

    Ну и, к слову, несмотря на то, что код выглядит как синхронный, он именно что только «выглядит» так — асинхронность все равно надо держать в уме, и, поскольку await разворачивается в Promise, все равно нужно понимать, как именно он это делает.
  • React Redux. Получение доступа к state из функции mapDispatchToProps()
    +1
    А, в таком случае — вообще никаких нареканий, так можно и это, в общем-то, не bad practice. Тут скорее наоборот — иметь в props экшены с уже «прошитыми» props бывает просто удобно, чтобы каждый раз не прокидывать их внутри компонента. Я сам тоже предпочитаю эту логику убирать за его пределы, оставляя презентационному (presentational/dumb) компоненту минимум простора для принятия подобных решений.
  • React Redux. Получение доступа к state из функции mapDispatchToProps()
    0
    Я думал, что речь о том, что стейт разбирается внутри, скажем, togglePlay(). Если myState — это уже нужный компоненту кусок стейта — это неплохо. Однако bad practice тут в том, что ваш компонент вообще знает, что что-то хранится в каком-то там стейте, вы его передаете туда-cюда. В этом плане еще лучше, если компонент вообще не будет знать, откуда берутся props (из стейта, переданы вручную, и так далее), это позволяет его легко переиспользовать. А ко всему прочему это проще тестировать.

    Ну можно же передавать туда и просто свои props
    Куда «туда»? :)

    Кстати, как у вас в примере 'myState' оказывается аргументом обработчика onClick? Там же SyntheticEvent.
  • React Redux. Получение доступа к state из функции mapDispatchToProps()
    0
    Bad practice, потому что тогда компонент должен знать о структуре стейта слишком много — больше, чем ему полагается для своей функциональности. То же касается и селекторов. В простых приложениях это может работать, но с ростом количества фич это становится все сложнее поддерживать (при изменении структуры state'а приходится вносить изменения в компоненты, селекторы и так далее).
  • Redux-form. Когда работать с формами просто
    0
    Ну тут считайте, что формы просто используют Redux как хранилище состояния, вместо хранения его в компонентах. Там отдельный редьюсер, и эта часть state ничего не знает про остальные. С этой частью стейта обычно не работают напрямую (однако иногда это бывает удобно, например, вручную залить серверной валидации ошибки в стейт в обход того, что предлагает redux-form).
  • Дайджест свежих материалов из мира фронтенда за последнюю неделю №230 (26 сентября — 2 октября 2016)
    +1
    Вы знаете, что ваш сайт — отстой, когда…

    В оригинале — «You know a site has its shit together when…». Тут смысл прямо противоположный, особенно в контексте самой статьи :)
  • JSX: антипаттерн или нет?
    0
    Да кстати на сайте JSX все правильно (ссылка на 357) — а вот сайт Ecma почему-то автоматом редиректит с 357 на 375 O_o
  • Redux Action Creators. Без констант и головной боли
    0
    Ну да, не уточнил. Под «другое» я имел в виду, что это не способ как-то особенно писать код, это не какая-то библиотека сама по себе, просто паттерн. Действительно, близко к тому, о чем говорится по ссылке выше (A New Approach for Managing Redux Actions). Пропустил этот момент, думал сравнивается с либой из топика.
  • Redux Action Creators. Без констант и головной боли
    0
    Это не велосипед, а паттерн организации проекта на Redux. И это совсем другое.
  • Паттерны React
    +2
    По поводу Children pass-thru:

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

    return React.Children.only(this.props.children)
    


    Это лишь способ указать, что children железно должен быть одним элементом в любом случае. Иначе React бросит исключение. Это никак не возможность вернуть несколько дочерних элементов напрямую, без оборачивающего элемента. Пример выше лишь проверит, что потомок один и вернет его.