xmoonlight: полный бред. uhash для каждой попытки логина разный, как он может использоваться в аутентификации? Откуда сервер берёт skey, по которому ведёт поиск?
xmoonlight: итак, клиент регистрируется. Сервер генерирует случайные skey и random1 и высылает из клиенту. Клиент придумывает user и password, вычисляет uhash1 = hash(user:password:skey:random1) и отправляет на сервер uhash1. Сервер записывает в базу uhash1 и skey.
На следующий день некто хочет залогиниться, как сервер найдёт в базе нужный skey?
Пусть в базе записано имя user и клиент говорит - я user и хочу авторизоваться. Сервер находит в базе запись с именем user, берёт из неё skey, генерирует random2, высылает skey и random2 клиенту. Клиент вычисляет uhash2 = hash(user:password:skey:random2) и отправляет на сервер uhash2. Итого у сервера есть user skey random2 uhash2, каковы дальнейшие действия сервера?
xmoonlight: в целом очень странная схема, клиент присылает хэш, сервер дожен получить из базы все логины с паролями, вычислить для каждого hash(USER:PASSWORD:SKEY:RANDOM) и если найдётся равный присланному, то авторизовать соответствующий аккаунт, так получается?
Как-то уж очень много недостатков по сравнению с простой передачей пароля по https.
да ни к чему такие сложности, просто child_process использовать с установленными переменными окружения. Даже готовый модуль сразу нагуглился - https://github.com/sihorton/node-php-cgi
Дмитрий: Такая проблема вроде была, и решалась кажется тем, что родителя делали владельцем например с помощью cloneElement. Сейчас работает без ухищрений - jsbin
Дмитрий: componentDidMount выполняется после вставки элементов в dom, но до того, как браузер успевает закончить их отрисовку, скорее всего из-за этого. Ниже правильно написали, setTimeout или requestAnimationFrame обычная практика.
перебор дерева и хэша
Количество итераций там одинаковое, просто обращение к свойству объекта дорогая операция.
И оператор in тоже дорогой, даже получение массива ключей Object.keys и итерация по нему незначительно, но быстрее.