Closed mishanga closed 9 years ago
А что ты пытаешься сделать?
Кстати, есть вариант вообще вынести toHTML в отдельный файл/функцию. Она вполне самодостаточна.
@zxqfox я тут пытаюсь убить несколько зайцев. Во-первых, появится возможность генерировать совершенно кастомный HTML для любого узла, чтобы не костылять. Во-вторых, можно будет в любой момент посмотреть, что уже сгенерировано, чтобы отправлять готовый HTML чанками в браузер для ускорения загрузки и отрисовки.
Про чанки не очень понял. Допустим, это будет работать для [ { block1 }, { block2 }, ... ]
.
А для { block: 'page', contents: ... }
? Последнее же чаще.
upd: И как быть с flow? toHtml станет асинхронной?
Чанки: https://ru.wikipedia.org/wiki/Chunked_transfer_encoding
Принципиально ничего не изменится. Ты можешь не пользоваться возможностью переопределять toHtml для узла.
Я понимаю про чанки, но не понимаю, как ты можешь <html><head><body class="page">
, потом подождать, потом отдать еще кусок, и потом конец </body></html>
. Для этого же надо будет отрисовать целую строку, распилить, отправить начало, ждать, потом отправить конец, и как-то это все попахивает.
Но если это возможно, то стоит заодно подумать про создание DOM-нод, вместо генерации строк, и про вызов из toHTML
классического алгоритма отрисовки.
Вообще, выглядит круто ;-)
@zxqfox в реальности мы делаем так: отдаем <html><head>...</head>
, а вторым куском <body>...</body></html>
. Это позволяет нам начать отдавать html и заинлайненный css еще до того, как пришел ответ от бэкенда, то есть практически мгновенно.
Мы делаем так уже несколько лет, теперь вот понадобилось реализовать это в BH.
Coverage remained the same at 100.0% when pulling 40d2af5dc17b4dad904d60d838809a6370a1c4f7 on yield into 8f49e4aa643dcd165be2ac1992f91ad8fd57cf7d on master.