Сергей Протько: спасибо. А Вы ещё не подскажите, Вам методы этого инжектора не говорят что можно разбить на модули а потом воедино собрать, как в angularjs?
Сергей Протько: а что значит "ресолвит граф зависимостей"? Про все методы я понимаю, а вот про resolve(data) и defer(func) нет. Вы можете объяснить для чего это?
Сергей Протько: и я нашел di bottlejs называется, он как в первом angular, но немного не подходит. И я решил и его не использовать и свой пока не делать, так как день или два на него потратить придется.
Для изоморфных приложений нужен инжектор на основе дерева графов. И поиск зависимостей должен быть вверх по этому дереву.
Это нужно для того, чтобы модули которые которые не должны обновляться выносились в скопу сервера и создавались только раз. А уже все остальное пусть создается на каждое подключение.
И ещё обязательно нужно ввести instence чтобы не просто синглтоны получать, но и созданные объекты при каждом запросею. И обычный импорт не подойдет, ведь нужно в эти экземпляры данные инжектить.
И ещё было бы прикольно если бы добавть параметр private и public, для того чтобы модуль cookie скрывал свои фабрики ServerCookie и ClientCookie.
Сергей Протько: Вам не кажется что глупо говорить о микро оптимизациях, когда пропагандируешь функциональный подход, который, как Вы сказали, раньше не использовался из-за своей "тяжести".
А ещё более странно что они предлагают класс обертывать в функцию..
Сергей Протько: Скажите, а в angular2 сохранился подход с инжектором? Типа app.service(name, ...])?
А то я пришел к выводу, что нужно написать такой же для реакта, но с небольшими изменениями..
Нужно сделать понятие scope для самого инжектора, чтобы та часть которая должна создаваться для каждого пользователя , так и создавалась. А вот те части которые просто обрабатывают данные, должны присоединятся к создаваемому.
Сергей Протько: это не предварительная оптимизация, а больше продумывание архитектуры. И у меня ен предвзятые отношения, а кратковременные приступы паники вызванные недостаточным количеством данных. Например вчера у меня при разговоре с Вами на несколько минут сложилось впечатление, что я желаю прыгнуть выше головы делая изоморфное приложение тогда, когда ещё наверное никто не делал с пререндером авторизованного пользователя в полной мере. И кульминацией этого безумия становится тот факт, что я вообще не одного сайта не сделал.
Но затем волна прошла и я понял как хорошо что все именно так, ведь только по этому мне открылось то, что возможно другие узнают только после многих лет практики.
И так же я нашел разницу между рендером обычных сайтов на сервере и изоморфным приложением. При обычном раскладе рендер начинается после сбора информации, а в изоморфном путем рендера. То есть данные я получаю путем рендера.
Хотя те самые объекты из которых компоненты берут свои состояния сделать создаваемыми каждый раз и это будет от части redux, а отчасти и нет. Потому что нужно избегать моменты с множеством данных, например тысячами фильмов, которые будут пересобираться при изменении одной галочке вообще в другом компоненте.
Это интересно. И спасибо за статью про angular2, она очень понятная и интересная.
И вот ещу что... Под функциональным программированием я понимаю подход, когда функция при передачи в неё одного и того же значения будут возвращать один и тот же результат. Типа -
function multy(a, b){
return a * b;
}
function getFilmById(id){
return Film.find(id);
}
Хотел ещё пример с каррированием добавить, но не смог придумать :)
Сергей Протько: нет не делал я обычные :) Но меня это не сильно пугает, так как приблизительно я понимаю.. Но вот сейчас понял, что не понимаю, наверное, только сколько инстенсов приложения. Думаю что один и при заходе я получаю юзера из db, собираю все данные и передаю на рендер. Наверное все же одно... Да?
И ещё вот какие мысли... Когда страх сходит, то я начинаю смотреть на приложение с единственным инстенсом вот под каким углом. Заходит пользователь, я создаю его объект данных и.. не знаю как назвать.. объект конфигурации приложения. Потом я пробрасываю эти два объекта через приложение в котором построенно все на функциональном подходе и на фабриках которые возвращают каждый раз новые объекты. И вот я значит прокинул эти объекты и в конце получаю готовый конфиг который можно рендерить. Всё бы было замечатьльно, но потом начинаю сгущаться тучи противоречия.. Типа чтобы все эти "инстенсы которые в ожидании загрузки или ещё чего-то" нужно как-то замыкать, а для этого нужно уже сложную структуру из промисов и функций строить. И вот как все тучи закрыли небо вдруг пробивает мысль-молния, что оно того не стоит и что новый инстенс c ооп подходом избавит от сумашедствия придумывания того, как не создавая инстенс создать его с тысячами функций и промисов. то есть функциональный подход начинает себя не оправдывать.
Должно зависеть от юзера иначе было бы совсем просто. И это круто когда слышишь и думаешь, а вот когда делаешь то не все так однозначно. Просто мне кажется что было бы круто делать с одним экземпляром на сервере, но я не уверен что так получится. Мне очень-очень сложно представить приложение, которое вообще не хранит состояния в объектах. А ещё я не могу ответить на такой вопрос - если обработка данных у меня реализована функционально, то передав как глобальный стор одного юзера, приложение обработает его и не заменет на только-что вошедшего. То есть я в роутере на сервере получил пользователя, его данные и передал его в приложение. Но через долю секунды зайдет другой пользователь и я сного получу объект пользователя и передам его в приложение. Но приложение по сути, да и по факту, имеет только один инстенс и все его сервисы и прочие тоже имеют только один инстенс иначе бы они не смогли ужится с одним экземпляром самого приложения. и что? получается что с одним инстенсом приложения не получится?
Просто когда я начинаю размышлять я вхожу в бесконечную рекурсию и начинаю нагонять на себя жути так, что понимание синхронного выполнения js меня начинает пугать.
потому что {{"title":"вывы","text":"вывы"}: ""}, у этого объекта нет свойства-ключа title, у него есть ключ {"title":"вывы","text":"вывы"} со значением ""
Алексей Уколов: я понимаю что нужно. Вопрос только как поступить с куками? При моем положении их нужно получать в express сохранять и свойство, которое передать в axios, который передаст на php куку установив её.. как её правильно нужно установить, чтобы middleware на php увидел её как куку?
Пререндер нужен для более преятной загрузки клиенту. Это я так слышал, на деле ещё может оказать что скорость увеличивается лишь с приложением helloworld, а в настоящем приложении может и замедлится. Сегодня уже такие мысли закрадывались..
Алексей Уколов: нода выступает в качестве фронтэнда только при пререндре. По сути да, нужно проксировать куку от браузера к php через экспресс, но на деле все немного сложнее.
Возмно всему происходящему есть более разумное объяснение, но я его не знаю по этому вижу так - браузер посылает запрос к domain.com серверу nginx, который проксирует к экспрессу. Экспресс выступает в некоем образе интерпретатора изоморфного js. То есть он лично запросы к api.domain.com не делает, это делает изоморфная библиотека https://github.com/mzabriskie/axios которая работает и на сервере и на клиенте. По этому более точно маршрут будет от браузера к domain.com nginx, от него к express. Последний выполняет код и axios посылает запрос к api.domain.com (это nginx на котором работает php) где и нужна кука.
Как просили, более подробно...
У меня сервер nodejs занимается пререндером изоморфного spa используя данные полученные от api на php. Для аутентификации пришлось использовать не совсем стандартный подход с jwt + cookie. И вот чтобы отпререндерить страницу для авторизованного пользователя на ноде, нужно эметировать работу браузера с куками.
Алексей Уколов: без получаса двенадцати в воскресенье, мне кто-то, кто зарегился только что для того чтобы поприкалываться, говорит что мне это не нужно. Истерика? Нет, это была не истерика..