Можно так же поднять для фронта маленький сервачок на node.js — использовать как проксю(отпадает необходмость в CORS) и, если нужно, ддя серверного рендеринга.
Хотя если все на одно домене то ни прокси, ни CORS вообще не нужны.
Первую схему мы юзаем для dev окружения, то есть мне как фронтеннд разработчику не нужно поднимать локально бекенд, вторая схема для production
Мы уже сами пол года разрабатываем фронт как отдельный проект, по апи получаем все нужные данные, если нужен серверный рендеринг — запускаем сервер на ноде, который если нужно используем еще и как прокси для запросов к api(если все крутится на одном домене то можно этого и не делать, но для dev окружения необходимо)
Бекендеры рады — работают с чистыми данными, не парятся за html и прочие фронтедреские штуки
Мы(фронтендеры) тоже рады — от проекта к проекту работаем в привычном для себя окружении в независимости от того, что крутится на бекенде
Статья называется «Изоморфное Приложение с React и Redux», а не «Изучаем Redux»
Изоморфное — подразумевает серверную и клиентскую части, вот вам и expressjs
ES6 — минимум для react-комьюнити, уже вроде как стандарт (babel позволяет), да и если начинать писать приложении с нуля, то сегодня не вижу смыла писать его на ES5
Роутинг есть почти в любом приложении, поэтому обойти этот вопрос было бы странно
immutable, да можно было не включать сюда =) Но тоже не вижу особых проблем, не так уж его и много
Идея поддерживать весь зоопарк устройств, конечно, отличная.
Но проблема в том, что мало кто захочет платить за доработки дизайна и функционала для старых устройств.
Кто-то сейчас и ie7 пользуется, процент не велик, но все же, а поддерживать версию сайта под него могут позволить себе только очень крупные ресурсы
И замечание по переводу
Слово «полизаполнения» лучше не переводить, а так и оставить — «полифилы» =)
Давно присматриваюсь к Redux, а времени пока что-то нет(сейчас проект на flummox), а тут все по полочкам разложено.
У меня вопрос, есть ли красивое решение для проблемы связанных запросов?
Пример:
У нас есть два action creators: getCurrentUser и getFriendsByUserId
Получается, что первый выполнит запрос на получение id текущего пользователя, а второй по этом id получит список его друзей.
Как при этом можно организовать тот же рендер на сервере?
(Возможно, что цепочка может быть и длиннее двух запросов)
Да дело не в маркетинге, просто на тот момент, насколько я помню, ваш продукт не позволял описывать шаблоны в декларативном стиле, но здорово, что вы пришли к этому
Когда то рассматривал вариант перехода с angular на Catberry, но в выбрал React.
Но я рад что проект развивается.
Правда меня смущает, что вы все еще предлагаете писать на ES5, в то время когда уже все уже переходят на ES6+. У вас нет в планах сделать реализацию на ES6+?
Но допустим static методы так же не утверждены, и не вошли в ES6. Но в этой статье описаны. Так что, думаю, и декораторы заслуживают внимания уже сегодня.
Я представляю себе реализацию примерно следующей.
Декоратор проверяет если в прототипе (например) метод componentWillMount. Если нет, то просто добавляет. Если есть то добавляет свой внутри которого уже вызывается существующий
Один из способов заменить миксины — использовать декораторы. Декораторами так же можно подмешивать в класс какие-нибудь методы.
Правда чтобы подмешивать несколько так называемых «lifecycle methods» уже придется повозиться. Сам решения не видел, но слышал что на просторах интернета уже есть много реализаций.
Сейчас как раз интересуюсь БЭМ и АНБ. Полный стек не интересует — интерес вызывает наименования классов и файловая структура.
Вроде кажется что все просто и понятно, но потом решаешься попробывать на большом проекте, и вот тогда начинаются вопросы.
1) По метолологии все блоки, лежат в папке blocks. Но что делать, если блоков становится слишком много? Я конечно понимаю, что можно их ка кто разбить на модули по типу
А как все таки с точки зрения БЭМ решать эту проблему?
2) Такие инструменты как SASS дают хорошую возможность. использовать, например, переменные, различного вида хелперы, миксины, наследование. Но, если мы с блоке начинаем юзать что-то из этого, но он же перестает быть независимым и становиться зависимым от контекста. То есть, либо мы нарушаем АНБ, либо пишем кучу повторяющегося кода.
Как БЭМ смотрит на эту проблему?
Если вы выбираете какою-либо методологию для разработки проекта, то все кто этот проект пилят, сначала знакомятся с ней, а уже потом начинают работать над проектом. В принципе в этом главный плюс любой методологии — единый стиль для всех.
Добавьте к этому код-ревью(чтобы избежать отклонений от методологии) и вы получите ваш «идеальный мир».
При выполнении какого либо действия в любом из подключившихся браузеров, будь то прокрутка, набор текста, отправка формы или клик, все эти действия повторятся на всех клиентах. Что, по моему мнению, позволит изрядно сэкономить время при тестировании.
Интересно как это работает для прокрутки на разных устройствах? Ведь допустим на десктопе весь сайт может помещаться в два скрола, а на телефоне в 10.
Пример с видео я тоже не понял. Меняем стили в отладчике, стили применяются только на выбранном девайсе. Дак где тогда профит то?
Вот уже в этот момент, автор должен понять, что что-то он делает не так
Хотя если все на одно домене то ни прокси, ни CORS вообще не нужны.
Первую схему мы юзаем для dev окружения, то есть мне как фронтеннд разработчику не нужно поднимать локально бекенд, вторая схема для production
ИМХО но если кто-то не сталкивался с AngularJs (1.x) то может уже и не стоит? Вакансии если и есть, то по большей части «поддержка старого проекта»
Мы уже сами пол года разрабатываем фронт как отдельный проект, по апи получаем все нужные данные, если нужен серверный рендеринг — запускаем сервер на ноде, который если нужно используем еще и как прокси для запросов к api(если все крутится на одном домене то можно этого и не делать, но для dev окружения необходимо)
Бекендеры рады — работают с чистыми данными, не парятся за html и прочие фронтедреские штуки
Мы(фронтендеры) тоже рады — от проекта к проекту работаем в привычном для себя окружении в независимости от того, что крутится на бекенде
Изоморфное — подразумевает серверную и клиентскую части, вот вам и expressjs
ES6 — минимум для react-комьюнити, уже вроде как стандарт (babel позволяет), да и если начинать писать приложении с нуля, то сегодня не вижу смыла писать его на ES5
Роутинг есть почти в любом приложении, поэтому обойти этот вопрос было бы странно
immutable, да можно было не включать сюда =) Но тоже не вижу особых проблем, не так уж его и много
Я конечно уверен всего лишь на 99%, но если хотя бы один из ..promises отклонен то Promise.all тоже будет отклонен
Но проблема в том, что мало кто захочет платить за доработки дизайна и функционала для старых устройств.
Кто-то сейчас и ie7 пользуется, процент не велик, но все же, а поддерживать версию сайта под него могут позволить себе только очень крупные ресурсы
И замечание по переводу
Слово «полизаполнения» лучше не переводить, а так и оставить — «полифилы» =)
Давно присматриваюсь к Redux, а времени пока что-то нет(сейчас проект на flummox), а тут все по полочкам разложено.
У меня вопрос, есть ли красивое решение для проблемы связанных запросов?
Пример:
У нас есть два action creators: getCurrentUser и getFriendsByUserId
Получается, что первый выполнит запрос на получение id текущего пользователя, а второй по этом id получит список его друзей.
Как при этом можно организовать тот же рендер на сервере?
(Возможно, что цепочка может быть и длиннее двух запросов)
Но я рад что проект развивается.
Правда меня смущает, что вы все еще предлагаете писать на ES5, в то время когда уже все уже переходят на ES6+. У вас нет в планах сделать реализацию на ES6+?
Но допустим static методы так же не утверждены, и не вошли в ES6. Но в этой статье описаны. Так что, думаю, и декораторы заслуживают внимания уже сегодня.
Декоратор проверяет если в прототипе (например) метод componentWillMount. Если нет, то просто добавляет. Если есть то добавляет свой внутри которого уже вызывается существующий
Правда чтобы подмешивать несколько так называемых «lifecycle methods» уже придется повозиться. Сам решения не видел, но слышал что на просторах интернета уже есть много реализаций.
Вроде кажется что все просто и понятно, но потом решаешься попробывать на большом проекте, и вот тогда начинаются вопросы.
1) По метолологии все блоки, лежат в папке blocks. Но что делать, если блоков становится слишком много? Я конечно понимаю, что можно их ка кто разбить на модули по типу
А как все таки с точки зрения БЭМ решать эту проблему?
2) Такие инструменты как SASS дают хорошую возможность. использовать, например, переменные, различного вида хелперы, миксины, наследование. Но, если мы с блоке начинаем юзать что-то из этого, но он же перестает быть независимым и становиться зависимым от контекста. То есть, либо мы нарушаем АНБ, либо пишем кучу повторяющегося кода.
Как БЭМ смотрит на эту проблему?
Добавьте к этому код-ревью(чтобы избежать отклонений от методологии) и вы получите ваш «идеальный мир».
а за пример
отдельное спасибо, не знал, что так можно =)
Интересно как это работает для прокрутки на разных устройствах? Ведь допустим на десктопе весь сайт может помещаться в два скрола, а на телефоне в 10.
Пример с видео я тоже не понял. Меняем стили в отладчике, стили применяются только на выбранном девайсе. Дак где тогда профит то?