Кстати, правильно ли я понимаю что судя по коду контейтера, после его отображения и запроса данных через XHR, компонент еще крутит индикатор загрузки?
Перед его рендерингом, делаем запрос за данными. В этот момент в сторе появляется информация, что нужен прелоадер: https://habrahabr.ru/company/hh/blog/310524/#comment_9820312
Поэтому, нет, не боролись, так как сейчас нас поведение устраивает
На es2015 остановились просто потому, что хотим использовать нативный JavaScript. От типизации посчитали, что существенного выигрыша\профита не получим.
Да, конечно. Начнем с того, что window.fetch — нативная штука.
Если рассмотреть axios, то в нем немало функционала, в котором мы не нуждаемся сейчас. На текущий момент времени нам более чем хватает нативной реализации\полифила + пары функций, одна из которых checkStatus (который обрабатывает статус ответа, делает throw при ошибке).
Поэтому нам просто нет нужды нести к себе в проект эту библиотеку.
Mobx — это еще один инструмент, где в моделях мы и храним состояние.
Замечу, что redux больше об идеологии и подходе к разработке. На такой идеологии можно строить и MobX приложение.
На проекте крупнее среднего, с использованием практически любого фреймворка будет возникать большая часть вопросов, которые мы в статье разобрали.
Спорить, почему redux\relay\mobx\angular\backbone\super-puper-framework-3000, а не что-то иное можно долго. Каждая из сторон будет в чем-то права, но в чем-то нет.
Поддержка проекта на redux это совсем не сложно. Головной болью не страдали :) И решили поделиться тем, как можно хорошо построить приложение, избежав лишних телодвижений.
Выбрав redux в качестве основного инструмента и идеологии по работе с состоянием нашего приложения мы не пожалели.
Может быть я неточно понял суть вопроса, тогда будет круто, если уточните его.
Отвечу на тот вопрос, который понял)
Здесь есть два пути.
Первый способ: один редьюсер — много разных типов action (которые относятся к разным объектам)
В редьюсерах (в импортах) прописываем список action types, на которые реагирует редьюсер.
Например, есть редьюсе progress, который отображает статус загрузки страницы (прелоадер по сути)
В этом редьюсере мы подписываемся на большое количество событий — это и загрузка сотрудников (FETCH_EMPLOYEES) и загрузка тестов (FETCH_TESTS) и т. д. Соответственно по COMPLETE_EMPLOYEES, COMPLETE_TESTS прелоадер завершается.
Второй способ: один редьюсер === один тип action (который относится только к одному объекту)
На примере того же прогресса — заводим отдельные события START_PROGRESS\END_PROGRESS. И перед загрузкой сотрудников\тестов и после их загрузки диспатчатся в том числе и эти action.
Мы у себя в разработке приняли первый вариант.
1) Он избавляет от последовательного вызова лишнего набора action.
2) Проблем между неявной связностью не получаем, так как зависимости явно прописываются в импортах (а если нужны для редьюсера кастомные данные, то тогда создаем отдельные action, да)
Второй способ от связности данных нас все равно не спасает, так как связность будет или на уровне action types, либо в логике action creators.
В статье как раз и описывалось, почему мы используем один try-catch на всех :) Поэтому вы абсолютно правы
В примере два try-catch, чтобы показать, что обрабатывая ошибки рендеринга и серверных запросов раздельно — код обработчика ошибок у нас все равно одинаковый в подавляющем большинстве случаев.
Relay у меня не зашел, Хотя концептуально очень классная штука, но уж больно неповоротливая и негибкая. Для HelloWorld отлично работает, но шаг влево или вправо и все — удачи в поисках решений
Это и послужило главной причиной выбора redux. Мы вольны строить архитектуру так, как это будет удобна нам.
1) А backend данные тоже отдает «нормализированными»? Могли бы вы привести пример данных, которые сервис возвращает SPA
В hh с бекендом у нас отличные отношения, что позволяет нам для разработки договариваться о нужном формате, который устроит всех. Соответственно при необходимости бекенд отдает данные сразу же нормализованными.
Например, на странице сотрудников, если ее запрашивать по ajax бек вернет информацию только о сотрудниках:
[
{
id: 1,
name: "Артем",
tests: [10]
}
]
На странице тестов получаем тесты в аналогичном формате. Нам остается только преобразовать массив в объект, чтобы иметь быстрый доступ:
2) Смотрели ли вы в сторону Relay или других подобных решений? Что о них думаете?
Да, смотрели. Перед стартом проекта, рассматривали разные библиотеки (redux, flux-овские, relay). Остановились на redux, так как он гибкий, легкий и позволяет подстроить систему под наши нужды.
3) Разработка с redux требует написания большого количества подобного кода. Используете ли какие-нибудь инструменты, которые упрощают жизнь?
Да, согласен. Это особенно заметно при написании функционала, задачи которого «возьми с сервера, положи в стор» (и забудь :).
На текущий момент это у нас не вызывало боли или неудобств при разработке. Мы используем небольшие самописные утилиты, которые немного упрощают написание кода. Из более глобального — пока решили не брать.
Если нужны ajax запросы и не хочется самому делать XmlHttpRequest, всегда можно воспользоваться window.fetch. А если нужно заполифилить, то https://github.com/github/fetch :-) А то в react приложении видеть jQuery — «так себе идея» (с)
По статье хочется, чтобы была для начинающих пометка, что React компоненты — это View слой, в нем не должно находиться места бизнес-логики вашего приложения. В Вашем случае — это, например, ajax запросы на сервер. Для того, чтобы унести бизнес логику придумали как раз такие штуки как flux, redux, которые отлично применяются с react =)
В самом начале, взгляд цепляется за «Отсутствие удобного редактора кода»… Здесь можно привести WebStorm, который от версии к версии обрастает все новыми клевыми «рюшками», да и используя jsDoc проблем с удобной документацией (и отображением в IDE) даже пользовательских функций не возникает.
Любителям VS — в новых версиях 13,14 года Microsoft тоже весьма неплохо организовали поддержку не только TypeScript, но и чистого JS
Очень непонятно Ваше стремление превратить JS в AS… Хотите ООП? Можно заиспользовать TypeScript или Dart…
Плюс очень непонятно:
1) Что же не так с прототипным наследованием, что оно может просто быть ненавистным (ну ок, привыкли к ООП, можно понять)
2) Что не так с DOM API?
3) Какие проблемы с разделением на файлы?
4) Что не так с событиями?
Если оценивать по возможностям и функциональности — ничем.
Для чего была создана данная библиотека?
До создания этой библиотеки я работал с QUnit и Jasmine.
Для своих задач было решено создать небольшую библиотеку, которая будет организована интерфейсно и возможностями под текущие задачи. Так и родилась затея с данной библиотекой.
В нее были включены небольшие фичи, которых мне не хватало в QUnit (отдаю должное разработчикам — это прекрасный фреймворк для тестирования).
К ним можно отнести вывод результатов, создание иерархии тестов, цепочные вызовы.
Mocha для проектов никогда не применял, но знаком с их документацией.
Изначально мы видим, что происходит внештатная ситуация. И только затем определяем, что внештатная ситуация произошла по вине некорректного расчета (то есть мы раскручиваем «воронку» с начала)
1. Метода done() хватило бы, но promises несут большую гибкость
3. По идее, да, стектрейс желателен бы всегда. Согласен
4. О чем, в принципе я и говорил. Для большей гибкости вывод теста при запуске в node.js можно сохранять в файл -> получаем доступ к файлам одним кликом. Для работы с DOM в node.js можно прикрутить phantomjs, но это уже вопрос не тестовой системы
5. Мне все таки кажется, что падение с Exception !== падение, если функция вернула неверные данные.
В первом случае — это внештатная ситуация, во второй — неверный расчет
1. — Как можно решить задачу с использованием promises — Перед запуском теста создаем объект промиса и запускаем таймер (нам нужно знать — может быть наш запрос отвалится по таймауту). И далее терпеливо ждем, что произойдет далее — либо асинхронный запрос завершится и мы резолвим промис, попутно проверяя данные с которыми произошел резолв (собираем данные теста)
Либо падаем по reject по таймауту.
2. — да, можно подумать в этом направлении
3. — думаю, стоит создать единый конфиг для тестов, куда включить — — отображение стектрейса для падения теста или exception
— скрывать пройденные тесты (соответсвенно, если группа прошла — не показываем группу)
4 — картинка не отобразилась =( Но это можно решить, воспользовавшись выводом со стектрейса (например выводить первый элемент, не относящийся к библиотеки)
5 — мне кажется, что стоит различать два варианта развития событий — 1) падение теста, так как вернулось неожиданное значение
2) внештатное поведение кода, которое привело к исключению
1. Поддержки асинхронных тестов на данный момент корректной нет. Можно использовать асинхронный запрос и тестирование результата в методе библиотеки.
В будущем думаю добавить возможность тестирования асинхронных запросов с помощью promises
2. Не задумывался на данной возможностью, но реализовать такую поддержку можно добавив дополнительный параметр в конфигурацию. Спасибо =)
3. Информация о пройденных тестах на данный момент не отключается
4. Код упавшего теста можно найти, например по его описанию + группе
5. Аналогично не занимался данной проблемой. При необходимости можно немного модифицировать логику работы библиотеки следующим образом —
Здесь github.com/xnimorz/YATS/blob/master/yats.js#L120 добавляем создание переменной Error и забираем его stackTrace — При необходимости можем удалить ненужные вызовы и представить для пользования корректный stackTrace.
Перед его рендерингом, делаем запрос за данными. В этот момент в сторе появляется информация, что нужен прелоадер: https://habrahabr.ru/company/hh/blog/310524/#comment_9820312
Поэтому, нет, не боролись, так как сейчас нас поведение устраивает
На es2015 остановились просто потому, что хотим использовать нативный JavaScript. От типизации посчитали, что существенного выигрыша\профита не получим.
Если рассмотреть axios, то в нем немало функционала, в котором мы не нуждаемся сейчас. На текущий момент времени нам более чем хватает нативной реализации\полифила + пары функций, одна из которых checkStatus (который обрабатывает статус ответа, делает throw при ошибке).
Поэтому нам просто нет нужды нести к себе в проект эту библиотеку.
Замечу, что redux больше об идеологии и подходе к разработке. На такой идеологии можно строить и MobX приложение.
На проекте крупнее среднего, с использованием практически любого фреймворка будет возникать большая часть вопросов, которые мы в статье разобрали.
Спорить, почему redux\relay\mobx\angular\backbone\super-puper-framework-3000, а не что-то иное можно долго. Каждая из сторон будет в чем-то права, но в чем-то нет.
Поддержка проекта на redux это совсем не сложно. Головной болью не страдали :) И решили поделиться тем, как можно хорошо построить приложение, избежав лишних телодвижений.
Выбрав redux в качестве основного инструмента и идеологии по работе с состоянием нашего приложения мы не пожалели.
Отвечу на тот вопрос, который понял)
Здесь есть два пути.
Первый способ: один редьюсер — много разных типов action (которые относятся к разным объектам)
В редьюсерах (в импортах) прописываем список action types, на которые реагирует редьюсер.
Например, есть редьюсе progress, который отображает статус загрузки страницы (прелоадер по сути)
В этом редьюсере мы подписываемся на большое количество событий — это и загрузка сотрудников (FETCH_EMPLOYEES) и загрузка тестов (FETCH_TESTS) и т. д. Соответственно по COMPLETE_EMPLOYEES, COMPLETE_TESTS прелоадер завершается.
Второй способ: один редьюсер === один тип action (который относится только к одному объекту)
На примере того же прогресса — заводим отдельные события START_PROGRESS\END_PROGRESS. И перед загрузкой сотрудников\тестов и после их загрузки диспатчатся в том числе и эти action.
Мы у себя в разработке приняли первый вариант.
1) Он избавляет от последовательного вызова лишнего набора action.
2) Проблем между неявной связностью не получаем, так как зависимости явно прописываются в импортах (а если нужны для редьюсера кастомные данные, то тогда создаем отдельные action, да)
Второй способ от связности данных нас все равно не спасает, так как связность будет или на уровне action types, либо в логике action creators.
Да, мы получим матрешку. Поэтому, разделяя компоненты и добавляя декораторы, об этом стоит помнить и не «заигрываться».
Но да, у нас эта цепочка используется во многих местах, так как у нас нет особой боли от этих трех строк промисов.
В примере два try-catch, чтобы показать, что обрабатывая ошибки рендеринга и серверных запросов раздельно — код обработчика ошибок у нас все равно одинаковый в подавляющем большинстве случаев.
Это и послужило главной причиной выбора redux. Мы вольны строить архитектуру так, как это будет удобна нам.
В hh с бекендом у нас отличные отношения, что позволяет нам для разработки договариваться о нужном формате, который устроит всех. Соответственно при необходимости бекенд отдает данные сразу же нормализованными.
Например, на странице сотрудников, если ее запрашивать по ajax бек вернет информацию только о сотрудниках:
На странице тестов получаем тесты в аналогичном формате. Нам остается только преобразовать массив в объект, чтобы иметь быстрый доступ:
Да, смотрели. Перед стартом проекта, рассматривали разные библиотеки (redux, flux-овские, relay). Остановились на redux, так как он гибкий, легкий и позволяет подстроить систему под наши нужды.
Да, согласен. Это особенно заметно при написании функционала, задачи которого «возьми с сервера, положи в стор» (и забудь :).
На текущий момент это у нас не вызывало боли или неудобств при разработке. Мы используем небольшие самописные утилиты, которые немного упрощают написание кода. Из более глобального — пока решили не брать.
По статье хочется, чтобы была для начинающих пометка, что React компоненты — это View слой, в нем не должно находиться места бизнес-логики вашего приложения. В Вашем случае — это, например, ajax запросы на сервер. Для того, чтобы унести бизнес логику придумали как раз такие штуки как flux, redux, которые отлично применяются с react =)
В самом начале, взгляд цепляется за «Отсутствие удобного редактора кода»… Здесь можно привести WebStorm, который от версии к версии обрастает все новыми клевыми «рюшками», да и используя jsDoc проблем с удобной документацией (и отображением в IDE) даже пользовательских функций не возникает.
Любителям VS — в новых версиях 13,14 года Microsoft тоже весьма неплохо организовали поддержку не только TypeScript, но и чистого JS
Очень непонятно Ваше стремление превратить JS в AS… Хотите ООП? Можно заиспользовать TypeScript или Dart…
Плюс очень непонятно:
1) Что же не так с прототипным наследованием, что оно может просто быть ненавистным (ну ок, привыкли к ООП, можно понять)
2) Что не так с DOM API?
3) Какие проблемы с разделением на файлы?
4) Что не так с событиями?
Для чего была создана данная библиотека?
До создания этой библиотеки я работал с QUnit и Jasmine.
Для своих задач было решено создать небольшую библиотеку, которая будет организована интерфейсно и возможностями под текущие задачи. Так и родилась затея с данной библиотекой.
В нее были включены небольшие фичи, которых мне не хватало в QUnit (отдаю должное разработчикам — это прекрасный фреймворк для тестирования).
К ним можно отнести вывод результатов, создание иерархии тестов, цепочные вызовы.
Mocha для проектов никогда не применял, но знаком с их документацией.
И да, добавил вывод stackTrace. Спасибо
3. По идее, да, стектрейс желателен бы всегда. Согласен
4. О чем, в принципе я и говорил. Для большей гибкости вывод теста при запуске в node.js можно сохранять в файл -> получаем доступ к файлам одним кликом. Для работы с DOM в node.js можно прикрутить phantomjs, но это уже вопрос не тестовой системы
5. Мне все таки кажется, что падение с Exception !== падение, если функция вернула неверные данные.
В первом случае — это внештатная ситуация, во второй — неверный расчет
Либо падаем по reject по таймауту.
2. — да, можно подумать в этом направлении
3. — думаю, стоит создать единый конфиг для тестов, куда включить — — отображение стектрейса для падения теста или exception
— скрывать пройденные тесты (соответсвенно, если группа прошла — не показываем группу)
4 — картинка не отобразилась =( Но это можно решить, воспользовавшись выводом со стектрейса (например выводить первый элемент, не относящийся к библиотеки)
5 — мне кажется, что стоит различать два варианта развития событий — 1) падение теста, так как вернулось неожиданное значение
2) внештатное поведение кода, которое привело к исключению
В будущем думаю добавить возможность тестирования асинхронных запросов с помощью promises
2. Не задумывался на данной возможностью, но реализовать такую поддержку можно добавив дополнительный параметр в конфигурацию. Спасибо =)
3. Информация о пройденных тестах на данный момент не отключается
4. Код упавшего теста можно найти, например по его описанию + группе
5. Аналогично не занимался данной проблемой. При необходимости можно немного модифицировать логику работы библиотеки следующим образом —
Здесь github.com/xnimorz/YATS/blob/master/yats.js#L120 добавляем создание переменной Error и забираем его stackTrace — При необходимости можем удалить ненужные вызовы и представить для пользования корректный stackTrace.
В расширенном поиске вакансий