Comments 80
Жаль VueJS не добавили, учитывая какая у него хорошая документация, в этом состязании легко бы занял первое место.
Из вопросов не понравились вопросы касающиеся "угадай кто этот человек", и вопросы "почему удалили такую возможность". т.к. в первом случае — не все запоминают личностей, во втором нужно иметь длительный опыт и следить за комитами, чтобы понимать, почему убрали какую-то функциональность.
Какой бы у vue не было документации, я не думаю, что хороший разработчик будет руководствоваться хипсторскими трендами, скорее, он будет использовать адекватные решения проверенные временем.
Точно, лучше кроме jQuery ничего не использовать, ибо хипстота!
(сарказм)
Когда хипсторские тренды навязывают неудобный инструмент — это да, плохо. Но когда дают крутой фреймворк, который может также легко использоваться как jQuery, который осваивается за пару вечеров, у которого есть крутой cli, который создаст тебе сборщик в одну команду и несколько нажатий клавиш up/down и eneter. И в тоже время, он имеет такой же функционал как и ReactJS — это хорошо.
Да и я не заметил, чтобы Vue был хипстерскее чем тот же ReactJS, статьями про которого завалин медиум.
правда хз, почему он выбрал redux, а не ангуляровские сервисы…
этож заново сборку ваять
А не надо новую сборку валять. cli сам создает сборку с typescript/babel/scss/jest/vuex/linter/e2e и.т.д. в зависимости от того, что вы выберите. Вот, посмотрите https://cli.vuejs.org/guide/creating-a-project.html#vue-create
Просто, https://sapper.svelte.technology мало известен
"Как отрендерить строку в React компоненте?"
Вы просите отрендерить конкретно строку, но считаете, что вариант с оберткой в другой элемент тоже верный? Да, визуально все три варианта — строки. Но те что в спане в понятии реакта — это ноды.
2) запрещено вызывать несколько setState подряд — всё можно вызывать, это нормально
3) при вызове setState несколько раз подряд порядок выполнения не гарантирован — функциональные setState вызовутся в по порядку (я выбрал этот вариант, помечен неправильным)
4) обновленя будут поставлены в очередь, а затем выполнены в том порядке, в котором они были вызваны — да, всё верно
И вопрос «что тут не так с кодом?». Единственное, что тут не так, это отсутствие prop-types/flow/ts для описания props.value. Все остальные варианты никак не отвечают на поставленный вопрос.
// EDIT
Я не работал с Angular 2+, ответил на 28/30. Но зато работаю с React с бета версии и ответил на 25/30. Много косяковых вопросов…
Да. Много спорных вопросов про React. Ну и вопросы с фотографиями людей, с годами релизов тех или иных библиотек — это немного за гранью… На мой вкус и цвет. Ну вот зачем мне знать из какой страны автор MobX? Ну вот правда, нафига? Или скажем вопрос про то, по какой причине отделили ReactDOM от React. Его отделили уже после того, как я пришёл в React. Зачем эта вся история? :)
В Ангуляр тоже ответы так себе местами. Например
1) "какую библиотеку библиотеку включает в себя ангуляр 6 по-умолчанию?" Подумал с заковыркой вопрос, ответил ни какую, но там rxjs. Так насколько я понимаю ничто не мешает не добавлять ее в package.json.
Просто добавь jquery, забудь про Http service. И фигач без rxjs. Или это имеется ввиду anuglar-cli генерированный "пустой" проект?
2) Что обеспечивает ngModel… ответ я правильный выбрал two-way binding, но он не верен имхо. Двойной байндинг обеспечивает syntax sugar, а ngModel только one-way binding (reading), ngModelChange это функция (эмиттер) для приема изменений в обратном направлении (writer). По сути ангуляром можно смело пользоваться как реактом, если подключить еще redux или ngrx.
3) Главный разрабочик вообще не по теме вопрос (это уже какая-то история философии). Я только Савкина знаю по его блогу, и Мишко только звякнуло (возможно неправильно) как разработчик Meteor.js который как раз ругал ngrx в пользу redux.
В реакт из теста узнал что Редукс русский разработчик сделал =)
Оба говно. Vue рулит.
Не работаю но с тем, ни с другим. Ответил правильно на 16 в Angular и 13 в React. Пойти, что ли, в разработчики ?))
Проходил оба теста.
По React:
- Считать, что PureComponent обеспечивает лучшее быстродействие, чем Component — неверно.
- Считать, что в react есть только jsx — неверно. Что забавно, есть два вопроса: в одном это учитывается, в другом нет.
- Функция, которая соединяет react и redux необязательно называется connect. Даже в том же react-redux есть connectAdvanced. А вообще юзер может написать свою функцию, если есть нужда.
По Angular меньше вопросов с реально неправильными ответами.
Сейчас я буду материться. Сука, как же вы заебали, тупорылые ебланы. Ваши говенные тестики нихуя блять не тестируют, они не способны этого сделать. Потому что их составитель умственно отсталая макака. Если вы хотите проверить знание какого-то стека, то проверяйте это, а не в каком году выпустили ебланскую либу. Перед тем как тестировать чьи-то знания сначала проверьте свои знания.
Уфф, высказался. Уж извините, но низкокачественные тесты это большая подстава.
Считать, что PureComponent обеспечивает лучшее быстродействие, чем Component — неверно.
Обоснуй.
Об этом сказано даже в оффициальных доках: you can use React.PureComponent for a performance boost in some cases.
Начнем с того, что пока вроде как не подвезли магических оптимизаций для PureComponent, поэтому PureComponent не может быть быстрее правильно написанного shouldComponentUpdate.
Во-вторых, сама проверка на неизмененность props/state может быть бесполезной в случае, если контейнер этого компонента перерисовывается только тогда, когда перерисовывается этот компонент. Или функция render может быть сама по себе достаточно быстра.
В третьих, вы можете написать свой собственный shouldComponentUpdate, который будет более эффективно отсекать перерисовки.
Они отличаются только наличием shouldComponentUpdate. Стало быть вот вам несколько вариантов:
- у вас свой shouldComponentUpdate, который из-за особенности бизнес-логики может быстрее решить — нужно ли ререндерить компонент или нет, нежели это делает shallowComparison
- у вас стандартный pure-shouldComponentUpdate в 95+% случаев выдаёт true. Или даже в 100%. Лишняя проверка производительность не повысит
- у вас необычный компонент, который в render возвращает, скажем, 1 простой
<span/>text</span>, но на входе имеет множество props. В этом случае может статься так, что shallowComparison будет по времени сопоставима с render method + reconcile + dom. Хотя тут конечно пример сильно надуманный - у вас не immutable-props-ы, и вы в принципе не можете использовать shouldComponent без багов
Ну и бонусом — вместо pureComponent или Component вы можете вообще inline сделать. Т.е. Вместо того чтобы писать <MyComp .../> вы можете написать {MyComp(props)}. В рамках экономии на спичках у народа получалось на этом что-то сэкономить, т.к. полностью игнорируется react life-cycle.
Считать, что PureComponent обеспечивает лучшее быстродействие, чем Component — неверно.
Позволяет отрезать ветку рендеринга, все очень даже верно.
А тест действительно шикарен. Кто на фотографии, Что было в 15ом году, почему чего то там в отдельную библиотеку вынесли. Отвечает Александр Друзь…
Позволяет [периодически] отрезать [лишнюю] ветку рендеринга, [за счёт дополнительных проверок, при условии, что вы оперируете immutable-данными].
Я поправил ;) На самом деле сий вопрос куда хитрее, чем в тесте указано. It depends.
И shallow-comparision, хоть и дополнительная, но дешевая проверка. И дело не в отрезании рендеринга конечного компонента, который спан рисует. Отрезается половина рендеринга страницы, так как не изменился объект состояния, соответствующий этой половине. Дело до shouldComponentUpdate конечных компонентов даже не дойдет. Я бы даже сказал наоборот, на конечных компонентах, где один спан, не имеет смысла использовать чистый компонент, да и реакт-компонент вообще, надо определять компоненты этого уровня как функции.
И даже если начать заморачиваться с тем, чтобы руками начать писать shouldComponentUpdate с мутабельной моделью — это реально делать для конечных компонентов, и нереально делать до компонентов верхнего уровня, потому что на верхнем уровне надо «знать» реализацию всего что внутри. И каждый раз когда внутри что то меняется, лезть наверх и обновлять эту сложную перенагруженную функцию shouldComponentUpdate. А с immutable моделью это «бесплатно».
Я в курсе всех этих вещей. И nsinreal, я полагаю, тоже в курсе. Собственно о том и речь, что pureComputed не серебрянная пуля, и это, как говорится, it depends. Надо рассматривать конкретный случай, чтобы судить о производительности. А вопрос поставлен абстрактно. Оттого к нему и претензии.
Пожалуй самая упоротая статья, что я когда либо видел, от этих тестов вытекли мои глаза. З. Ы. После Ализара конечно
По Angular только читал книгу почти год назад, ни одного проекта на нём не сделал.
Тесты ничего не показывают, любой тест это просто игра.
Камооон. «Лидер команды», «любой вызов». Вопросы, на которые ответит любой джун.
Ребятам стоит самим подучить React как мне кажется...
26 из 30 в ангуляре. Ангуляр не изучал)
Вопросы явно сделаны просто для фана.
Спасибо авторам за весёлый тест!
Angular vs React: битва за фронтенд