• Разбор конкурса-квиза по React со стенда HeadHunter на HolyJs 2018
    0
    Да, действительно, имеется в виду конечное состояние компонента после updating цикла.
  • Разбор конкурса-квиза по React со стенда HeadHunter на HolyJs 2018
    0
    Разбор вопросов по JS — здесь habr.com/post/431698
  • Нянчим проект на React-redux с пелёнок
    0
    Главный поинт в том, что react-helmet решает только работу с head документом. Декораторы же могут использоваться для значительно большего спектра задач (в статье, например, разобрано 4 способа использования).

    Если же вы о декораторе title, который был приведен в качестве одного из примеров, то аналогично вопросу axios vs http — у react-helmet много функций, в которых мы не нуждаемся. В таком случае лучше сделать маленькую «утилиту»\компонент, который решит потребности. А если требования изменятся, и нужен будет больший набор возможностей, то окей, перейдем.
  • Нянчим проект на React-redux с пелёнок
    0
    Способ интересный, спасибо за ссылку!

    Не натыкался на него)
  • Нянчим проект на React-redux с пелёнок
    0
    Кстати, правильно ли я понимаю что судя по коду контейтера, после его отображения и запроса данных через XHR, компонент еще крутит индикатор загрузки?


    Перед его рендерингом, делаем запрос за данными. В этот момент в сторе появляется информация, что нужен прелоадер: https://habrahabr.ru/company/hh/blog/310524/#comment_9820312

    Поэтому, нет, не боролись, так как сейчас нас поведение устраивает
  • Нянчим проект на React-redux с пелёнок
    0
    В HH не используется TypeScript :)

    На es2015 остановились просто потому, что хотим использовать нативный JavaScript. От типизации посчитали, что существенного выигрыша\профита не получим.
  • Нянчим проект на React-redux с пелёнок
    0
    Да, конечно. Начнем с того, что window.fetch — нативная штука.

    Если рассмотреть axios, то в нем немало функционала, в котором мы не нуждаемся сейчас. На текущий момент времени нам более чем хватает нативной реализации\полифила + пары функций, одна из которых checkStatus (который обрабатывает статус ответа, делает throw при ошибке).

    Поэтому нам просто нет нужды нести к себе в проект эту библиотеку.

  • Нянчим проект на React-redux с пелёнок
    +1
    Mobx — это еще один инструмент, где в моделях мы и храним состояние.

    Замечу, что redux больше об идеологии и подходе к разработке. На такой идеологии можно строить и MobX приложение.

    На проекте крупнее среднего, с использованием практически любого фреймворка будет возникать большая часть вопросов, которые мы в статье разобрали.

    Спорить, почему redux\relay\mobx\angular\backbone\super-puper-framework-3000, а не что-то иное можно долго. Каждая из сторон будет в чем-то права, но в чем-то нет.

    Поддержка проекта на redux это совсем не сложно. Головной болью не страдали :) И решили поделиться тем, как можно хорошо построить приложение, избежав лишних телодвижений.

    Выбрав redux в качестве основного инструмента и идеологии по работе с состоянием нашего приложения мы не пожалели.

  • Нянчим проект на React-redux с пелёнок
    0
    Может быть я неточно понял суть вопроса, тогда будет круто, если уточните его.

    Отвечу на тот вопрос, который понял)
    Здесь есть два пути.

    Первый способ: один редьюсер — много разных типов 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.
  • Нянчим проект на React-redux с пелёнок
    0
    Отлично, что статья вам поможет :)

    Да, мы получим матрешку. Поэтому, разделяя компоненты и добавляя декораторы, об этом стоит помнить и не «заигрываться».
  • Нянчим проект на React-redux с пелёнок
    0
    Для статьи такой код, в отличие от использования библиотеки понятен и прост.

    Но да, у нас эта цепочка используется во многих местах, так как у нас нет особой боли от этих трех строк промисов.
  • Нянчим проект на React-redux с пелёнок
    0
    В статье как раз и описывалось, почему мы используем один try-catch на всех :) Поэтому вы абсолютно правы

    В примере два try-catch, чтобы показать, что обрабатывая ошибки рендеринга и серверных запросов раздельно — код обработчика ошибок у нас все равно одинаковый в подавляющем большинстве случаев.
  • Нянчим проект на React-redux с пелёнок
    0
    Relay у меня не зашел, Хотя концептуально очень классная штука, но уж больно неповоротливая и негибкая. Для HelloWorld отлично работает, но шаг влево или вправо и все — удачи в поисках решений


    Это и послужило главной причиной выбора redux. Мы вольны строить архитектуру так, как это будет удобна нам.
  • Нянчим проект на React-redux с пелёнок
    +1
    Спасибо!

    1) А backend данные тоже отдает «нормализированными»? Могли бы вы привести пример данных, которые сервис возвращает SPA


    В hh с бекендом у нас отличные отношения, что позволяет нам для разработки договариваться о нужном формате, который устроит всех. Соответственно при необходимости бекенд отдает данные сразу же нормализованными.

    Например, на странице сотрудников, если ее запрашивать по ajax бек вернет информацию только о сотрудниках:
    [
        {
            id: 1,
            name: "Артем",
            tests: [10]
        }
    ]
    


    На странице тестов получаем тесты в аналогичном формате. Нам остается только преобразовать массив в объект, чтобы иметь быстрый доступ:

    employees: {
    	status: COMPLETE,
    	list: [
    		{
    			id: 1, 
    			name: ‘Георгий’,
    			testResults: [123]
    		}
    	]
    },
    tests: {
    	123: {
    		id: 123,
    		score: 5
    		speed: 146,
    		description: ‘...’
    		...
    
    	}
    }
    


    2) Смотрели ли вы в сторону Relay или других подобных решений? Что о них думаете?


    Да, смотрели. Перед стартом проекта, рассматривали разные библиотеки (redux, flux-овские, relay). Остановились на redux, так как он гибкий, легкий и позволяет подстроить систему под наши нужды.

    3) Разработка с redux требует написания большого количества подобного кода. Используете ли какие-нибудь инструменты, которые упрощают жизнь?


    Да, согласен. Это особенно заметно при написании функционала, задачи которого «возьми с сервера, положи в стор» (и забудь :).
    На текущий момент это у нас не вызывало боли или неудобств при разработке. Мы используем небольшие самописные утилиты, которые немного упрощают написание кода. Из более глобального — пока решили не брать.
  • ReactJS 15.0.2 Tutorial
    +3
    Если нужны ajax запросы и не хочется самому делать XmlHttpRequest, всегда можно воспользоваться window.fetch. А если нужно заполифилить, то https://github.com/github/fetch :-) А то в react приложении видеть jQuery — «так себе идея» (с)

    По статье хочется, чтобы была для начинающих пометка, что React компоненты — это View слой, в нем не должно находиться места бизнес-логики вашего приложения. В Вашем случае — это, например, ajax запросы на сервер. Для того, чтобы унести бизнес логику придумали как раз такие штуки как flux, redux, которые отлично применяются с react =)

  • Приручаем JavaScript или очередной велосипед для frontend-приложений
    +9
    На мой взгляд, статья очень спорная.

    В самом начале, взгляд цепляется за «Отсутствие удобного редактора кода»… Здесь можно привести WebStorm, который от версии к версии обрастает все новыми клевыми «рюшками», да и используя jsDoc проблем с удобной документацией (и отображением в IDE) даже пользовательских функций не возникает.

    Любителям VS — в новых версиях 13,14 года Microsoft тоже весьма неплохо организовали поддержку не только TypeScript, но и чистого JS

    Очень непонятно Ваше стремление превратить JS в AS… Хотите ООП? Можно заиспользовать TypeScript или Dart…

    Плюс очень непонятно:
    1) Что же не так с прототипным наследованием, что оно может просто быть ненавистным (ну ок, привыкли к ООП, можно понять)
    2) Что не так с DOM API?
    3) Какие проблемы с разделением на файлы?
    4) Что не так с событиями?
  • Unit тестирование в js. YATS — поделка для написания юнит тестов
    0
    Если оценивать по возможностям и функциональности — ничем.

    Для чего была создана данная библиотека?

    До создания этой библиотеки я работал с QUnit и Jasmine.

    Для своих задач было решено создать небольшую библиотеку, которая будет организована интерфейсно и возможностями под текущие задачи. Так и родилась затея с данной библиотекой.
    В нее были включены небольшие фичи, которых мне не хватало в QUnit (отдаю должное разработчикам — это прекрасный фреймворк для тестирования).

    К ним можно отнести вывод результатов, создание иерархии тестов, цепочные вызовы.

    Mocha для проектов никогда не применял, но знаком с их документацией.

  • Unit тестирование в js. YATS — поделка для написания юнит тестов
    0
    Поддержка библиотеки полноценного запуска на node.js. Существование форматированного вывода, адаптированного под node.js
  • Unit тестирование в js. YATS — поделка для написания юнит тестов
    0
    да, соглашусь с Вами
  • Unit тестирование в js. YATS — поделка для написания юнит тестов
    0
    Изначально мы видим, что происходит внештатная ситуация. И только затем определяем, что внештатная ситуация произошла по вине некорректного расчета (то есть мы раскручиваем «воронку» с начала)

    И да, добавил вывод stackTrace. Спасибо
  • Unit тестирование в js. YATS — поделка для написания юнит тестов
    0
    1. Метода done() хватило бы, но promises несут большую гибкость

    3. По идее, да, стектрейс желателен бы всегда. Согласен

    4. О чем, в принципе я и говорил. Для большей гибкости вывод теста при запуске в node.js можно сохранять в файл -> получаем доступ к файлам одним кликом. Для работы с DOM в node.js можно прикрутить phantomjs, но это уже вопрос не тестовой системы

    5. Мне все таки кажется, что падение с Exception !== падение, если функция вернула неверные данные.
    В первом случае — это внештатная ситуация, во второй — неверный расчет
  • Unit тестирование в js. YATS — поделка для написания юнит тестов
    0
    1. — Как можно решить задачу с использованием promises — Перед запуском теста создаем объект промиса и запускаем таймер (нам нужно знать — может быть наш запрос отвалится по таймауту). И далее терпеливо ждем, что произойдет далее — либо асинхронный запрос завершится и мы резолвим промис, попутно проверяя данные с которыми произошел резолв (собираем данные теста)
    Либо падаем по reject по таймауту.

    2. — да, можно подумать в этом направлении

    3. — думаю, стоит создать единый конфиг для тестов, куда включить — — отображение стектрейса для падения теста или exception
    — скрывать пройденные тесты (соответсвенно, если группа прошла — не показываем группу)

    4 — картинка не отобразилась =( Но это можно решить, воспользовавшись выводом со стектрейса (например выводить первый элемент, не относящийся к библиотеки)

    5 — мне кажется, что стоит различать два варианта развития событий — 1) падение теста, так как вернулось неожиданное значение
    2) внештатное поведение кода, которое привело к исключению
  • Unit тестирование в js. YATS — поделка для написания юнит тестов
    0
    1. Поддержки асинхронных тестов на данный момент корректной нет. Можно использовать асинхронный запрос и тестирование результата в методе библиотеки.
    В будущем думаю добавить возможность тестирования асинхронных запросов с помощью promises

    2. Не задумывался на данной возможностью, но реализовать такую поддержку можно добавив дополнительный параметр в конфигурацию. Спасибо =)

    3. Информация о пройденных тестах на данный момент не отключается

    4. Код упавшего теста можно найти, например по его описанию + группе

    5. Аналогично не занимался данной проблемой. При необходимости можно немного модифицировать логику работы библиотеки следующим образом —
    Здесь github.com/xnimorz/YATS/blob/master/yats.js#L120 добавляем создание переменной Error и забираем его stackTrace — При необходимости можем удалить ненужные вызовы и представить для пользования корректный stackTrace.
  • Похожие поисковые запросы в hh.ru
    0
    И такое есть ;) hh.ru/article/1175
    В расширенном поиске вакансий
  • Похожие поисковые запросы в hh.ru
    0
    Например так: hh.ru/search/vacancy?only_with_salary=false&specialization=1.221&area=1&clusters=true&text=C+and+not+1c&salary=¤cy_code=RUR
    Можно «поколдовать» еще со специализациями =)

    Разве что будет примесь С\С++ разработчиков
  • В который раз этот класс?
    –19
    (id вообще оставим как и положено для JS).


    id для js — плохая практика. Лучше воспользоваться классами (с префиксом, на которые не накладываем стили), либо data аттрибутами

    Ваше решение — отлично бы подошло для сайтов — одно-двухстраничников.
    1) Чем сложнее сайт, тем сложнее разобраться с такими стилями

    2) Неоднородное поведение элементов. Иногда можно столкнуться со следующими идеями интерфейса — на страницах с какой-то объемной информацией header может «спускаться» за пользователем (быть фиксированным) на других страницах этого не надо (да, вырвиглазно, но присутствует)

    3) «Шаблонность» (по отношению к header\body\footer) это проверенная годами возможность предоставить пользователю удобное понимание сайта. Было б непривычно, если бы каждый из сайтов был построен «как душеньке захотелось»

    Если разобрать Вашу идею можно найти множество проблем данного кода (начиная от пометки выбранного пункта меню и т.д.)
    Сайт уровня usatoday.com на данных «идеях» построить вам не удастся
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Благодарю!
    О данном (не знаю, как точно определить..) ходе не предполагал.
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Если Вы приходите в компанию, где работают без БЭМ и их продуктом является таки веб-сервис, то у них почти всегда есть концепция построения проекта. Иначе держать всю структуру просто-таки невозможно.
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Нет
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Строго следуя БЭМ — да
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Я его выделил как элемент внутри блока. Сам по себе он может быть также блоком.
    Яркий пример — верстка меню — есть блок меню, который включает элементы — пункты меню, которые включают в себя блок — ссылка
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    (извиняюсь, не туда отправил)
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    В таком случае разработчику стоит решить использовать БЭМ или нет. Так как острой необходимости здесь не будет.

    Единственная вещь, которую можно записать в «стоит» — это следование единому стилю оформлению
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Для сайтов, которых цель — бложик или статика, либо форумы (подобное им) БЭМ не нужен.(читать как не является нужным) Так как такие сайты создаются один раз и следующий раз изменятся только при редизайне.
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Прочитайте, пожалуйста, статью. Я привожу пример и рассказываю, что же такое блоки и что такое элементы
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Я думаю, что стоит. Яндекс (могу ошибаться) никогда кардинально не менял всю верстку. Используется как старая, так и новая. (по мере наработки — спасибо независимым блокам)

    Далее, такие сайты как lenta.ru — постоянно дорабатывают сайт -> без независимости постоянно бы вставал вопрос о «переписки»

    hh.ru -использует БЭМ + XSLT — аналогично использование наработок позволяет использовать заново блоки -> сокращается время разработки.
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Инструменты для БЭМ были разработаны много позже методологии.

    БЭМ предлагает правила именования. В этом его прелесть — разработчикам не нужно «искать то какой принцип исопльзовал предыдущий разработчик при именовании»

    Я думаю, Вам будет очень интересна дискуссия в статье здесь — marow.net/archives/161

    Для данного треда вынесу цитату:
    «Каждый их разработчиков, рано или поздно приходит к чему-то подобному БЭМу»

    Возвращаясь к каскадированию — вы вправе использовать его внутри одного блока, например. Все зависит от принятых соглашений для проекта

    Также добавлю, если посмотреть на SMACSS — он очень похож на БЭМ.
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Ответ уже был дан, на самом деле habrahabr.ru/post/203440/#comment_7021936
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    0
    Почитайте историю БЭМ.
    БЭМ == Независимые блоки.

    Изначальное название БЭМ: Верстка на независимых блоках (точное название не припомню, но суть эта)
  • Верстка для самых маленьких. Верстаем страницу по БЭМу
    +2
    Вы сейчас говорите о шаблонизаторах. Однако БЭМ это не шаблонизатор. Это методология написания html\css кода.
    Это такая же методология, как, например, SMACSS или OOCSS (весьма популярные технологии разработки html\css кода)

    Многие компании используют XSLT шаблонизатор + БЭМ методологию.

    БЭМ описывает то, как организовывать структуру HTML кода, чтобы добиться ее переносимости и плавного расширения.

    В проектах без БЭМ (а если быть более точным — без методологии разработки), зачастую случается следующего рода проблема — создан сайт. Затем появляется необходимость поправить расположение блока меню, блок регистрации поменять местами с лого. Используя БЭМ вы отлично знаете, что, чтобы поменять местами достаточно сменить стили у элементов блока хедер (если говорить о примере в статье) Если необходимо сменить цвет — Вам не надо лезть в код и менять что-то там. Достаточно лишь добавить нужный модификатор. Код становится гибким.

    Отказ от наследования…
    В статье писал, что может случиться, если Вы в блок добавите вложенный элемент с тем же названием, что и для тех, кои были раньше. БЭМ это учитывает, а в проекте построенном на каскаде может потребоваться переписать код (пример есть в статье)