Максимка

https://facebook.github.io/react/docs/component-sp...

Хук componentDidMount выполняется только на клиенте.
Соответственно, если вы используете тот же ref, чтобы выполнить какие-то действия с DOM, то имеет смысл это делать в этом хуке.

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

git remote add upstream ...
И каждый раз для обновления
git fetch upstream
git rebase upstream/master

Расскажу, какая ситуация с этим у меня в Impress и что меня в этом устраивает и не устраивает.

Сейчас процессы для обработки запросов порождаются при старте, и повторно порождаются при падении. Утечки памяти или падения процессов - считаю ненормальным поведением, но в реальности не все используемые библиотеки пушу я и даже не весь код приложений пишу я, поэтому нужно как-то с утечками и падениями бороться. Конечно падения минимизированны, т.к. весь прикладной код выполняется в sandbox`ах, и при утечках можно просто создать новый sandbox в том же процессе, восстановить в нем все нужные структуры данных, потом заменить ссылку со старого (утекшего или испорченного при исключении sandbox`а) на новый и убить старый. Это быстрее, чем порождать новый процесс.

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

Как я хочу сделать. Кроме процессов обработки запросов иметь еще некоторый пул подготовленных запущенных процессов, которые уже и соединение к БД установили и развернули все что нужно в памяти. С родительским процессом они связаны TCP-сокетом, через который налажен RPC (полноценный вызов удаленных процедур с поддержкой колбэков, событий, асинхронного вызова нескольких запросов и т.д.) И когда возникает необходимость ответвить обработку или выполнить задание по расписанию, то вместо порождения процесса будет браться первый свободный процесс из пула и ему по RPC приходит заказ. Когда он все выполнил, то он по RPC возвращает колбэк или событие.

Вот все у меня уже вроде готово для этого и сам RPC написан и отлажен, скоро реализую. А дальше по тому же RPC (но с транспортом через вебсокеты) собираюсь связать и клиентские приложения, чтобы они становились единым целым с серверными процессами и воркерами.

Снести оба
Поставить офф пакет

Читаем https://deb.nodesource.com/setup чтоб узнать каким образом к нам на пк добавятся доп репозитории. Вся ответственность за проблемы только на тебе

По дефолту ставится 0.10.x

curl -sL https://deb.nodesource.com/setup | sudo bash -

вставить для установки репозиториев

sudo apt-get update && sudo apt-get install -y nodejs

установить ноду

если нужно свежее, то меняем
sudo vim /etc/apt/sources.list.d/nodesource.list

deb https://deb.nodesource.com/node_0.10 ....
deb-src https://deb.nodesource.com/node_0.10 ...

на

deb https://deb.nodesource.com/node_0.12 ....
deb-src https://deb.nodesource.com/node_0.12 ...

sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get install -y nodejs

//узнать про твои пакеты ты можешь так which node; man node

find . -name "*.txt" -type f -delete

и так со всеми расширениями, если без ключа

-delete

то сначала посмотрите списком, что оно есть и перепроверите, нужно ли грохать.

Если Вам нужно что-то очень кастомное, то, конечно, пишите руками. Также можете писать плагины самостоятельно, если хотите попрактиковаться и повысить уровень познаний JavaScript.

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

Вторая функция выполняется, когда объектная модель (DOM) готова к использованию, мол когдадокумент загружен и готов- делаем. Первая - в том же случае, т.к. The ready() method может быть применен только к одному данному документу, поэтому селектор не обязателен.

Третья - то же самое в принципе, т.к. $ - это функция, если не передать в нее параметры (селекторы), то она вернет объект готового документа.

Что при этом будет быстрее - хз.
Вообще я с javascript и Jquery не очень дружу, поэтому могу ошибаться. Думаю, надо гуглить в сторону функции $

выходит как-то так.

(function($){
    $(function(){
        //code here
    });
})(jQuery);

1-ый вариант - когда нужно что бы код выполнялся только тогда, когда у нас готово DOM дерево. То есть документ сам догрузился и браузер завершил разбор дерева элементов. Так мы можем быть уверены что по нашему селектору нам вернут реально все доступные элементы и нету такого что что-то еще не догрузилось. Собственно $(function() {}) это полный аналог $(document).ready.

2-ой вариант является хорошей практикой для ограничения области видимости. То есть ваш код работает только с теми объектами, которые передали в замыкания. Профит в том, что можно безболезненно подменять переменные. Скажем передавать jQuery другой версии или что-то в этом духе и при этом у нас нету необходимости менять хоть что-то внутри замыкания. Собственно об этом уже много раз спрашивалось и отвечалось

Он Вам не нужен, если Вы не знаете, как его собрать.