Larisa Moroz

Лучше использовать vue-cli-3 и плагин @vueneue/ssr.

В предыдущих проектах использовал Vue Server Renderer, поскольку он более гибкий. В nuxt некоторые вещи сначала жизнь упрощают, а потом реально начинают ее портить. Взять даже тот самый хваленый роутинг на файлах. Я бы понял, если бы он поддерживал все возможности vue-router, но он реально практически все отрезает :( Можно, конечно, отключить это дело или вообще написать свой шаблон формирования роутинга для Nuxt, но зачем же тогда сам Nuxt?

Дальше планирую пользоваться связкой vue-cli-3 + плагины (в т. ч. указанный выше).

Вот накидал блики, при желании можно раскачать до вполне приемлемого состояния https://jsfiddle.net/l2banners/tjm7p1r6/4/

по поводу косых линий на фоне, они сплошные, их можно в ксс сделать и под низ положить впринципе это не сложно, ну а сами блоки сделать белыми почти прозрачными... Ну и все, тени тоже не проблема, тени можно через js двигать при прокрутке

Тыц

https://github.com/walkor/Workerman
Пользовался этим пакетом, всё отлично работает. С let сертификатом.

Мы ожидали увидеть приложение с использованием готовых библиотек для работы с HTTP, базой данных, работы с консолью. А также легко расширяемое и поддерживаемое.

Теперь понятно, что они хотят — но в ТЗ не было указано:

• Под HTTP понимают либы, работающие с PSR 7 или близкие по «духу», например Symfony HTTP Foundation
  
• Под БД понимают Doctrine 2 или Eloquent
  
• По консольным — на рынкке используют как правило Symfony Console
  

Именно это и хотели, предлагаю вам либо объяснить и написать уже на компонентах, либо послать к черту, НО отметить этот момент и на будущее таки делать уточнение, каковы ожидания от задания...
Нескольких людей встречал до фанатизма не принимающих сторонние пакеты, и наоборот... Это нужно учитывать... видел задания на PHP 5.3, видел задания строго на Codeigniter...

Тут на Тостере был пример, когда человек применил композер даже не для сторонней либы, а для внутренних, так на него тимлид сокрушился...
Разве Composer бесполезен в 2017?

Люди разные :)


Материал по компонентной разработке

Елена,
не нужно Symfony ассоциировать с фреймворком — это в первую очередь компоненты — потрясающие компоненты:

• Symfony Console
  
• Symfony HTTP Foundation
  
• Syfony Routing (к слову очень быстрый, недавно ускорили его в 70 раз ребята и сделали самым шустрым компонентом)
  
• Twig
  
• Debug
  

[*!*] В некоторых вакансиях даже указывают, что нужно уметь работать с некоторыми выше перечисленными компонентами :) Пруф: https://novosibirsk.hh.ru/vacancy/25367906

Doctrine — совсем не из Symfony и этот компонент можно использовать где угодно

Zend к слову пошел по тому же пути, например

• для HTTP Request/Response PSR 7 у него есть отличный компонент Zend Diactoros,
  
• для работы с PSR 15 Middleware есть компонент Zend Expressive,
  
• для работы с ролями и правами крутое решение Zend ACL
  

Laravel уже да — фреймворк, и опять же на компонентах, и можно использовать его куски, например у него замечательная ORM (Active Record) — в отличие от AR в Yii2 ее можно (и нужно) использовать в любом кастомном проекте вне фреймворка Laravel или вообще фреймворка там , где Доктрина лишняя


Почитать и посмотреть:

Современный PHP без фреймворков (статья Mail.ru на Хабре)
Консольное приложение (мастер-класс) — собрано из компонента Symfony Console и ORM Eloquent (от Ларавел)
PSR-7 фреймворк от Д.Елисеева

response:
https://nodejs.org/api/http.html#http_event_close_1
request:
https://nodejs.org/api/http.html#http_event_close_2

Натравить analyzer ниже, вписав его в индекс и к нужным полям:

{
  "settings": {
    "analysis": {
      "analyzer": {
        "address_analyzer_toster": {
          "tokenizer": "whitespace",
          "char_filter": [
            "useless_symbols",
          ],
          "filter": "useless_words": {
                    "type":       "stop",
                    "stopwords": ["ул", "д", "проезд", ...]
          }
        }
      },
      "char_filter": {
        "useless_symbols": {
          "type": "pattern_replace",
          "pattern": "[,\.:].*",
          "replacement": ""
        }
      }
    }
  }
}

Все красиво объяснил Nkly777, только в блоке PS merge с rebase перепутаны.
Добавлю картинок.

git rebase devel - собачка на молнии - "сшивает" коммиты по дате их создания
(ветка devel "растворяется" в основной ветке)

git merge devel - пожарная лестница, все коммиты ветки devel крепятся в конец, образуется пересечение
(devel остается отдельной веткой, к которой можно вернуться)

git chery-pick idea - забрать коммиты из ветки idea

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