Serg

мне кажется, это решение не очень хорошее из-за указания конкретного имени (phoneValues)

Выглядит не "не очень хорошим", а просто отвратительным - типа, не буду я разбираться с потенциальным багом, а вместо этого соответствующее предупреждение просто замету под ковёр. Ну, сделали вы slice - от этого в компоненте Card обращение к несуществующим элементам phoneValues никуда не делось.

React.PureComponent реализует метод shouldComponentUpdate таким образом, что он делает поверхностное сравнение props и state (не глубокое). Вот собственно код:
https://github.com/facebook/react/blob/c8fbdac2271...

shouldUpdate =
            !shallowEqual(prevProps, nextProps) ||
            !shallowEqual(inst.state, nextState);

Что такое shallowEqual? Это по сути сравнение оператором === каждого элемента из prevProps с каждым элементом из nextProps. На всякий случай дам ссылку на реализацию для полного понимания: https://github.com/facebook/react/blob/6963ea4bfcd...

В итоге всё зависит от структуры ваших props. Если в props вы передаёте объекты которые иногда мутируются, т.е. по ссылке они равны ===, но внутри какие-то данные поменялись (что само по себе выглядит странно в экосистеме redux + reselect, но вполне возможно технически), тогда использование PureComponent вам всё поломает, т.к. на экране какие-то компоненты перестанут перересовываться!

Если же у вас всё по уму, данные которые передаются через props являются скалярными типами (string, int, float, bool) или immutable объектами, тогда смело используйте PureComponent - в некоторых случаях он поможет избавиться от лишних вызовов render.

Важное замечание: PureComponent нужно использовать только для так называемых presentational components, т.е. для тех компонент, которые НЕ обёрнуты в вызов redux connect().

Для container components (т.е. тех компонент, которые обёрнуты в redux connect()) нет смысла наследоваться от PureComponent, т.к. метод connect() оборачивает ваш компонент своей реализацией shouldComponentUpdate, которая также использует shallowEqual. Если вы по недосмотру унаследуете container component от PureComponent - ошибок не будет, но это не имеет никакого смыла, т.к. ваш код по сути будет дважды делать shallowEqual, а зачем делать лишнюю работу?

Подводя итог, рецепт такой:
- presentational components наследуем от React.PureComponent
- container components (которые обёрнуты в redux connect()) наследуем от старого доброго React.Component

В общем у меня уйдёт на это 2 - 2.5 месяца. Только на основы!

Ну обосраться. Два грёбаных месяца!!!1
До чего докатилась индустрия, что 2 месяца воспринимаются как огромный срок. И всё чаще натыкаешься на статьи, где пишут о годовалых якобы мидлах и трехлетних якобы сеньорах.
Лично я считаю, нужно потратить от 2-3 лет, чтобы начать более-менее прилично и системно ориентироваться в теме. В течении этих лет неоднократно будут возникать моменты, когда тебе кажется, что ты уже достаточно крут - но это только кажется.
Нормальный специалист средней руки формируется около 3 лет. Не гуру, не сенсей, не сеньор - просто крепкий линейный боец. Это много где так, не обязательно в JS. И это нормально.
Хочешь за несколько недель - иди установщиком пластиковых окон, как раз строительный сезон начался.

Не забудьте "Дизайн привычных вещей" Дональда Нормана. Это конечно не тренд этого года, но это та классика, которая вечна.

Изучаю эту:
https://www.ozon.ru/context/detail/id/135199296/

linux

Ну, это и фрондендеру нужно часто знать.

ЯП

Я сомневаюсь, что он сейчас сильно проще питона или php, JS очень довольно быстро развивается. А если взять в расчет TypeScript, то тем более.

В целом, если его очень хорошо протестировать, то разработчик уверен на 99.9%

Совсем нет. Не получится протестировать на всех браузерах, на всех операционных системах и на всех устройствах с разным экраном, с разным способом ввода.

то в случае с frontend все гораздо проще

Ну вот просто вообще не правда. Я также могу сказать, что в бэке учить нечего, изучил язык, изучил laravel, а sql даже учить не надо, используй ORM. Справедливое высказывание?

Теперь в общем. Во front-end много чего можно изучить
1) Верстка. Хороший front-end'ер должен хорошо верстать, вопреки частому мнению, что этим должен заниматься верстальщик. А верстка это отдельная широкая тема.
2) SVG, для многих интерактивных приложений, очень полезно использовать svg, а там куча своих особенностей, хаков и.т.д.
3) Webgl - довольно сложная тема, не знаю, есть ли в бэке что-то аналогичное по сложности.
4) Canvas - не просто знать, а уметь рисовать то, что желаешь.
5) Фрейморки, а там тебе для каждого свое разветвление.
6) Асинхронное программирование, которое для многих php-шников кажется непонятным.
7) ООП, т.к. в JS завезли классы, да и TypeScript часто нужно использовать.
8) Шаблоны проектирования - не только для бэкенда.
9) Webpack+gulp - ну это было.

Буду дополнять, если что-то еще в голову придет.

Расскажите о минусах и плюсах

Из плюсов - идея интересная, выглядит симпатично.
Из минусов (в самом посте):

• Шрифт мелкий, строки длинные. На 15-дюймовом FullHD - сложно читать. Я бы увеличил хотя бы до 16-18px.
  
• Контрастность тоже не самая лучшая. Серый текст по белому фону заставляет напрягать глаза.
  
• Вертикальный ритм немного странный. Может быть над заголовками добавить отступы?
  
• Картинки хочется сделать побольше. Хотя может быть и нет. Но отделить их отступами точно стоит.
  
• Не хватает информации об авторе, даты написания статьи (может все уже устарело на 10 лет).
  
• Иконки для расшаривания в социальных сетях тоже можно добавить.
  
• Так и хочется внизу увидеть теги, комментарии, похожие посты и.т.д. Их там нет, а очень хочется.
  
• Эффекты при наведении мыши и фокусе на элементы нужно добавить.
  

Скролл очень сильно лагает, так что навигацию оценить сложно. Адаптивность отсутствует. Определенно стоит подумать про сценарии взаимодействия с сайтом в целом. Если это - блог, то там точно должно быть (люди к этому привыкли и ждут этого):

• Список статей, который можно быстро пролистывать.
  
• Поиск по статьям. Если материалов мало, то по крайней мере поиск по тегам или категориям.
  
• Страницы авторов, или по крайней мере хоть какая-то о них информация, контакты.
  

и.т.д.

Красивые анимации - это уже вторичное, начинать нужно со сценариев взаимодействия, а то получается красивое, но не удобное.

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

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

Да нет, там как раз все просто. Грубо говоря есть три уровня:

• "Делает ли эта функция то, что должна?": Мы (как тестировщики) знаем, что функция делает внутри себя, и убеждаемся, что она продолжает это делать и в будущем. Это именуют модульным или юнит-тестированием. В маленьких проектах обычно его не делают или покрывают такими тестами только определенные части проекта. Помогает оперативно находить изменения в поведении существующих модулей, которые так могут долго оставаться незамеченными и потом не понятно, что вызвало поломку. По идее такие тесты должны в автоматическом режиме проходить перед сборкой кода для продакшена.
  
• "Работают ли несколько модулей вместе так, как задумано?": Мы не знаем, что происходит внутри связки, но знаем, что есть на входе и что должно быть на выходе. Это именуют интеграционным тестированием. По идее оно помогает находить проблемы на стыке модулей, когда поведение одного модуля поменяли, а про другой забыли. В реальном мире встречается не так часто, т.к. требует включения мозгов для написания тестов.
  
• "Решает ли система задачи пользователя?": Это по-разному называют. Тут идет работа от ТЗ. Мы знаем, что должен получить пользователь от готовой системы в ответ на свои действия, но как она работает внутри нам фиолетово. Наиболее понятный сценарий такого тестирования - заранее написать кейсы, примеры того, как пользователь решает какую-то задачу, а потом перед каждым релизом "прокликивать" нужные последовательности кнопок или что-то вроде того. Это могут делать руками (студенты-обезьянки) или можно автоматизировать. Посмотрите примеры использования CodeceptJS и все станет ясно. По-хорошему это стоит делать на проектах любого размера, но на практике...
  

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

1) Mobx лучше использовать когда вы не хотите использовать монструозные конструкуции чтобы обновить какой-то объект который находится где-то глубоко внутри дерева состояния, например когда вам нужно обновить комментарий который находится внутри массива комментария объекта "задачи", которая находится внутри массива задач объекта "проекта" (схема примерно такая

store = {
   projects: [
    ... , 
   {id: 'project1', tasks: [
       ... , 
       {id: 'task1', comments: [
           {id: 'comment1', text: 'some text'}
       ]} 
   ]}
]}

и где-то в компоненте комментария получив через пропсы объект {id: 'comment10', text: 'some text'} в обработчике ввода текста с mobx-ом вам достаточно будет обновить только одно свойство - comment.text = e.target.value, когда же с redux вам нужно создавать отдельный редюсер и там писать конструкцию которая сначала создаст новый объект коментария потом скопирует старые свойства и дальше запишет при этом свойство text с новым текстом, дальше создает объект задачи и также скопирует его свойства и создаст при этом новый объект массива комментариев и скопирует все комментарии которые были плюс наш новый объект комментария, и дальше все это нужно повторить с проектом и задачами и так с каждым родителем пока не доберемся до верхушки дерева состояния. Есть правда spread-оператор который облегчает этот процесс копирования свойств и элементов массива но конструкции все равно получаются монструозные и чем глубже объект тем они больше.

2) Mobx лучше использовать когда вы хотите чтобы какие-то объекты ссылались друг на друга. Например хотим создать todo-приложение но чтобы там можно было создавать подзадачи к задаче и подзадачи к подзадачам в общем чтобы получилось некое дерево подзадач. Со стороны реакта будет один компонент который рекурсивно будет вызвать себя для всех подзадач.

const Task = ({task})=> (
  <div>{task.children.map(subtask=><Task task={subtask}>)}</div>
  )

И теперь допустим вы решили ограничить количество подзадач к одной задачи. И хочется в обработчике написать примерно такое условие - if(this.props.task.parent.children.length > 10) return; то есть попросту говоря обратиться к объекту родительской задаче через свойство .parent. C mobx это возможно прямо как в этом примере а вот c redux это невозможно (потому что из-за того что объекты ссылаются друг на друга и необходимость возвращать новый объект состояния вызовет рекурсивное пересоздание всех объектов) и там для написания древовидных интерфейсов нужно делать нормализацию стора и передавать айдишник и писать еще кучу лишнего кода. И при этом не получится в обработчике обратится к объекту родителя так как this.props.task.parent будет айдишником и значит нам еще нужно обращаться к стору чтобы вытащить объект по его айдишнику (например через thunk - dispatch((_, getState)=>getState().tasks[this.props.task.parent]).children.length. А если нужно обратится к еще более родительской задачи - то нужно уже два раза вытаскивать объект из стора по его айдишнику. А в случае когда у нас большое приложение где у юзер может создавать папки, у папках проекты, у проектах задачи, у задачи комментарии то чтобы в компоненте комментария обратится к папке в котором находится комментарий c mobx достаточно просто написать comment.task.project.folder.name а вот с redux-ом будет примерно такая неудобная конструкция state.projects[state.projects[state.tasks[comment.taskId].projectId].folderId].name и в больших приложениях код бизнес-логики будет постоянно перемазан вот таким вот кодом вытаскивания объекта из стора по его айдишнику на каждый чих