Напоминает статью про дичайшую востребованность телеграфистов 100 лет назад и про последующие сдвиги в отрасли, которые произошли с течением времени (с развитием техники)
Да, вы совершенно правы в своих подозрениях, я остался в каменном веке касаемо html-валидаторов :) Ознакомился со статьёй по вашей ссылке сразу же, но комментарий мой был написан ранее, одобрили его только сегодня.
Ничего не имею против адекватных линтеров, а тем более автоматизированно применяемых :)
Из статьи появилось ощущение, что под SSR автор имеет ввиду генерацию статических страниц? Есть ли поддержка собственно универсальных/изоморфных приложений?
Зачем минус) Совершенно справедливый вопрос, учитывая дикую сферичность этого (и любых других) валидаторов. А также то, что html в наши дни практически всегда сгенерированный.
Ну почему же, мазохизма тут не более, чем использовать babel (что уже не первый год стандарт де-факто) — и то и то парсер+трансформер вместе с огромным выбором плагинов, которые в обоих случаях работают с предоставленным AST.
И само собой есть браузерные ограничения, как и в случае с babel.
Кастомные css-свойства и css-переменные всё-таки разные понятия.
И замечательно все используют, PostCSS в помощь (postcss-custom-properties), с соответствующими ограничениями, конечно. Маловероятно, что спека со статусом с 2015 года "Candidate Recommendation" изменится. А с выходом Edge 15 переменные и кастомные свойства стали реализованными во всех основных браузерах без всяких флагов.
Глобальная поддержка у них (судя по caniuse) 69%, а на проектах нашей компании значительно выше (порядка 85%) из-за отличий в аудитории. Как только поддержка станет достаточной, можно будет включить опцию "preserve" и получить полность работоспособные динамические кастомные css-свойства.
Цель использования кастомных css-свойств у нас — темизация общей библиотеки компонентов для разных проектов компании.
P.S. надеюсь мой коммент не сильно устареет, прежде чем будет одобрен))
Интересное применение, не знал об этом :) Есть только один нюанс: в рамках ECMAScript 6 многие функции работы с числами, которые в предыдущих версиях были глобальными функциями, постепенно переезжают в статические методы Number. Чтобы в светлом будущем упорядочить хаос в JavaScript и пометить как устаревшие глобальные isNaN, parseInt, ...you name it.
Number.isNaN при этом не повторяет точь-в-точь поведение window.isNaN (в новой версии отсутствует неявное приведение типов), так что трюк из статьи не прокатит :( Но спасибо, всё равно интересно было почитать.
Почему вы решили, что reduceReducers «раскомбинирует» в плоскую структуру? Это же обычный функциональный fold всех редьюсеров. В моём примере никакого раскомбинирования в плоскую структуру не происходит, это просто slice reducer, который отвечает не за ветки info и credentials, а за весь их родительский узел profile.
А зачем так делать — спросите у автора. Я лишь предложил более простой (по моему скромному мнению) вариант решения проблемы, который проще, чем предложенный автором. Тоже считаю, что где-то тут у автора неправильно сформирована структура данных.
Конечно, может быть полезен :) Просто мы обсуждали решение проблемы более «проторенным» путём. Как видите, такой путь есть. Возможно поэтому в опросе подавляющее большинство голосов «нет» и «скорее всего нет»?
Насчёт родного API: redux не даёт такого апи вообще. Всё, что есть — это набор соглашений и полная свобода делать что угодно с корневым редьюсером (кто во что горазд — как было с классическим Flux до появления Redux, который стал стандартом де-факто). CombineReducers был введён лишь чтобы дать похожую на классический Flux возможность разделения общего стейта на отдельные «домены». И в работе с составной логикой в редьюсерах тоже есть стандарт де-факто: обычный функциональный подход.
Конечно же isUsed — это просто чистая функция, как и любой редьюсер, и вы можете делать с ней всё, что захотите. Например в привычном виде (у вас в примерах это switch, у меня — createReducer) сделать обработку по нужным actionTypes, а вместо spread-оператора использовать Ramda, Immutable и так далее. Не придумывая дополнительные соглашения по нотации «объекта комбинаций».
Документация Redux как раз и предлагает не писать все редьюсеры кучей в руте. Более того, прямым тестом сказано, что combineReducers — просто пример, что каждый может сам себе режиссёр реализовать свой вариант combineReducers. Так что формально ваше предложение не нарушает заветы авторов Redux.
Но для декомпозиции редьюсеров обычно используют функциональный подход, и это оказывается намного удобнее. А для работы с вложенным деревом — нормализацию стейта.
А что скажете про компанию Odin?
Напоминает статью про дичайшую востребованность телеграфистов 100 лет назад и про последующие сдвиги в отрасли, которые произошли с течением времени (с развитием техники)
Ничего не имею против адекватных линтеров, а тем более автоматизированно применяемых :)
Из статьи появилось ощущение, что под SSR автор имеет ввиду генерацию статических страниц? Есть ли поддержка собственно универсальных/изоморфных приложений?
Зачем минус) Совершенно справедливый вопрос, учитывая дикую сферичность этого (и любых других) валидаторов. А также то, что html в наши дни практически всегда сгенерированный.
И само собой есть браузерные ограничения, как и в случае с babel.
Кастомные css-свойства и css-переменные всё-таки разные понятия.
И замечательно все используют, PostCSS в помощь (postcss-custom-properties), с соответствующими ограничениями, конечно. Маловероятно, что спека со статусом с 2015 года "Candidate Recommendation" изменится. А с выходом Edge 15 переменные и кастомные свойства стали реализованными во всех основных браузерах без всяких флагов.
Глобальная поддержка у них (судя по caniuse) 69%, а на проектах нашей компании значительно выше (порядка 85%) из-за отличий в аудитории. Как только поддержка станет достаточной, можно будет включить опцию "preserve" и получить полность работоспособные динамические кастомные css-свойства.
Цель использования кастомных css-свойств у нас — темизация общей библиотеки компонентов для разных проектов компании.
P.S. надеюсь мой коммент не сильно устареет, прежде чем будет одобрен))
Number.isNaN при этом не повторяет точь-в-точь поведение window.isNaN (в новой версии отсутствует неявное приведение типов), так что трюк из статьи не прокатит :( Но спасибо, всё равно интересно было почитать.
React vs. Vue vs. Angular :(
А зачем так делать — спросите у автора. Я лишь предложил более простой (по моему скромному мнению) вариант решения проблемы, который проще, чем предложенный автором. Тоже считаю, что где-то тут у автора неправильно сформирована структура данных.
Браво, чистосердечное признание. Зачем все остальные слова?
Насчёт родного API: redux не даёт такого апи вообще. Всё, что есть — это набор соглашений и полная свобода делать что угодно с корневым редьюсером (кто во что горазд — как было с классическим Flux до появления Redux, который стал стандартом де-факто). CombineReducers был введён лишь чтобы дать похожую на классический Flux возможность разделения общего стейта на отдельные «домены». И в работе с составной логикой в редьюсерах тоже есть стандарт де-факто: обычный функциональный подход.
Btw, у вас могут быть проблемы с мутацией стейта.
Хозяин — барин. Обсуждение, зачем именно это понадобилось — непродуктивно. Но если я правильно вас понял, то вот простой пример решения:
Конечно же isUsed — это просто чистая функция, как и любой редьюсер, и вы можете делать с ней всё, что захотите. Например в привычном виде (у вас в примерах это switch, у меня — createReducer) сделать обработку по нужным actionTypes, а вместо spread-оператора использовать Ramda, Immutable и так далее. Не придумывая дополнительные соглашения по нотации «объекта комбинаций».
режиссёрреализовать свой вариант combineReducers. Так что формально ваше предложение не нарушает заветы авторов Redux.Но для декомпозиции редьюсеров обычно используют функциональный подход, и это оказывается намного удобнее. А для работы с вложенным деревом — нормализацию стейта.
Расскажите, чем ваш подход лучше использования вложенных combineReducers (https://github.com/reactjs/redux/issues/738) вместе с reduce-reducers от Эндрю Кларка?