Conversation
There was a problem hiding this comment.
Может начать собирать Noscript через Browserify? Тогда каждый файл будет отдельным CommonJS модулем и, как следствие, (1) не придется оборачивать каждый файл в IIFE, (2) не придется помнить, что в выражении var ns = ns || require('ns'); первая часть для браузера, а вторая для сервера.
There was a problem hiding this comment.
А напиши пример, пожалуйста.
К примеру, как будет выглядеть такой вот файл в терминах Browserify:
var ns = ns || require('ns');
ns.coolMethod = function() {
return 'cool';
};There was a problem hiding this comment.
Вообще, в случае вспомогательной функции или класса, можно не прикреплять его к неймспейсу в самом модуле (чтобы без побочных эффектов):
// cool-method.js
var COOL = 'cool';
module.exports = function coolMethod() {
return COOL;
};
// ns.js
var ns = {};
ns.coolMethod = require('./cool-method');
module.exports = ns;Но если без сильных изменений, то можно записать так:
var ns = require('./ns');
module.exports = ns.coolMethod = function() {
return 'cool';
};There was a problem hiding this comment.
Хм хм хм )
Ну может быть и стоит сделать как ты предлагаешь.
/сс @doochik @edoroshenko ?
There was a problem hiding this comment.
Я за.
И уж точно не стоит писать везде no || require('nommon')
There was a problem hiding this comment.
да, browserify решает эту проблему
Еще вот такая запись var no = no || require('nommon') не даст нам исполнять код в браузере или сделать модуль, потому что получится вот так
(function() {
// и тут всегда будет вызываться require, потому что no определен локально
var no = no || require('nommon');
})()
There was a problem hiding this comment.
Ну не надо это делать внутри замыкания просто
https://github.com/yandex-ui/noscript/blob/server.render.92/src/ns.view.js#L1-L2
There was a problem hiding this comment.
Мы сами оборачиваем эти файлы в модули и такие строки все сломают
|
Давайте относиться к этому pr, как к прототипу. Я здесь пока вижу "решение по-быстрому". Хочется сделать ровно. Я тоже готов сделать заход |
|
Это полноценное решение вообще-то. |
|
Ром, ну давай по-честному, ты просто запустил ns в ноде и навтыкал костылей, чтобы оно завелось. Я считаю такой подход не очень правильным |
|
Приведи пример костыля? |
|
Примеры костылей: |
|
Ну ок, если ты придумаешь более элегантный способ - я не против. |
|
Я начал свой заход на серверный ns и теперь могу внести в свою позицию немного конструктива. @chestozo , ты решил задачу "сделать так, чтобы ns как-то заработал на сервере". Ты её успешно решил. Это proof of concept, прототип, но не рабочее решение. Создание рабочего решения требует более глубокой проработки и проектирования. Как я вижу правильный подход к решению этой задачи.
Естественно, это только первый подход к снаряду. Следующие шаги, которые я планирую: вникнуть в задачу поглубже, написать тесты, придумать и обсудить api, декомпозировать задачу. |
чтобы на сервер не клиентский код. Либо ты его не тащишь на сервер, либо ты втыкаешь костыли, чтобы он не ломался (if !window итд).
Это же разные окружения. В ноде нет window, location, history, dom, document. Это же очевидно. Это точно нужно перечислять? Я прелагаю выделить 3 типа сущностей noscript:
Первый проще, второй - ровнее. Пока писал этот коммент, придумал третье окружение: тестовое. Нам в бою ни на клиенте, ни на сервере не нужны костыли |
Друг, не воспринимай это на свой счёт. Мы все хотим сделать хороший инструмент. Этого можно достичь только дискуссией |
|
Я думаю, что явно очерченные сборки особо не нужны, они сами органично сформируются. Предлагаю, с точки зрения Node.js, рассматривать Noscript как набор компонентов (модулей). Да, для браузерного окружения есть клей в виде Идея с разделением |
Это как? ) |
|
Если подключить Browserify, то клиентский Серверный клей (типо такой) будет подключать |
There was a problem hiding this comment.
откуда в ns завязка на descript? А если я не хочу descript, а хочу express ?
There was a problem hiding this comment.
no.de надо читать как node, а не как no.descript.
Это свойство из nommon.
Зависимости от descript - нет )
There was a problem hiding this comment.
А ещё лучше - вообще не использовать проверки и писать код, не зависящий от окружения.
Вот не знаю, утопия это в наших обстоятельствах, или нет
There was a problem hiding this comment.
@maksimr при желании, и эта проверка не будет работать, если в браузере нужный json-чик забацать )
Но и window можно и в nodejs объявить )
В общем - мы все умрём )
There was a problem hiding this comment.
@edoroshenko +1
@chestozo Я написал потому, что столкнулся с проблемами при созаднии yate-playground :)
|
Мое мнение:
|
Я вначале так и сделал, а потом переделал назад.
Вот тут не очень понял, что такое |
|
Это нужно решать не через добавление опций к сложному сценарию, а через разделение сценария на отдельные простые, которые потом можно комбинировать в зависимости от окружения.
Не нужно выполнять на сервере специфично клиентский код только из-за того, что нам лень придумывать, как его отделить.
его тесты будут контролировать |
|
@edoroshenko не будем, |
|
@doochik а зачем вообще создавать объект ns.action? |
|
Я кстати, не две сборки хочу, а три. Ещё для тестов ) |
|
Это не правильно, надо тестировать то, что уходит в браузер, а не какую-то специальную сборку |
|
Вот есть nommon, которые используется в nodejs и в браузере. |
|
я хочу в неё перенести только костыли |
|
Нужно из множества работающих схем выбрать оптимальную |
|
@edoroshenko можно, но тогда все настоящие приваты придется вынести наружу. Но и тогда кастомная сборка не нужна, а просто в стабах все написать можно |
|
@doochik да, всё в стабах |
|
предлагаю встречу, а то у меня пальцы устали |
|
Парни, давайте я сделаю заход и тогда уже соберёмся и обсудим конкретные решения. А то я пока только критикую и ничего своего не предложил. Я хочу другой api |
|
Давай все же, как ты любишь, мы сначала поговорим
|
|
И еще: давайте все споры про встраивание в node, browserify и т.п. оставим на конец. Сначала надо сделать вот эти 4 шага Потом, уже с готовым решением, проще будет понять че и как делать с нодой |
|
Про разбиение на 4 шага: это неполная картина. Шаги такие:
Под рендером я понимаю: html + DOM + events. |
|
Я тоже за встречу. |
|
Если что - вот тут есть пример, как вызывать descript в nodejs https://github.com/pasaran/yate/blob/master/docs/quick-start.md#%D0%92-nodejs |
|
Распилил ns.Update #304 |
|
Закрываю, раз есть отдельное issue на распил. |
5 participants
Изменения API:
ns.tmplтеперь возвращает строку. До сих пор он возвращал DOM ноду, но у нас нет DOM-а на сервере (он нам и не нужен)ns.updateтеперь поддерживаетoptions.syncOnly(выполнить update только для синхронных видов) иoptions.renderOnly(результатом update-а должна стать HTML строка)Особенности работы:
ns.tmplиns.http, к примеру, так https://github.com/chestozo/noscript-demo/blob/master/server.js#L20-L49Пример:
допилил своё демо приложение https://github.com/chestozo/noscript-demo/
А ещё я хочу сказать вот что:
ns.updatewindow,document,location). И вообще все глобальные объекты должны быть доступны в nodejs и их нужно передавать в yate, как тут https://github.com/chestozo/noscript-demo/blob/master/server.js#L24<div id="ns-root"> ... </div>. Но это делается на стороне приложения, а не noscriptns.updatesyncMode: true- чтобы все view считались синхронными и все данные запрашивались тоже синхронной пачкой. Пока не делал.