Backend vs Frontend

grigori · 21 Окт 2015

fixxxer написал(а):
@grigori, спринг != джава, есть тот же play framework, скажем

да хоть груви с Circumflex, чем экзотичнее зверинец - тем веселей поддержка

fixxxer · 21 Окт 2015

Хых, груви вообще смешная фигня, выглядит как будто джависты захотели пхп =)

hell0w0rd · 21 Окт 2015

fixxxer написал(а):
Кстати, а как на реакте без говнокода решаются такие проблемы, когда нужно подергать реальный DOM? Вот скажем, чтобы посчитать реальный boundingClientRect и красиво спозиционировать какой-нибудь поповер.

Смотря что подергать. Если нужно атрибуты вытащить - есть механизм ссылок. Если нужно встроить плагинчик который будет менять DOM, допустим wysiwyg, в render необходимый минимум разметки, инициализация в componendDidMount, shouldComponentUpdate => false. То есть реакт никогда не полезет обновлять dom и не наткнется на чужой html. Пример обертки

hell0w0rd · 21 Окт 2015

grigori написал(а):
вы писали с шаблонизаторами на java?

Нет. Вообще с шаблонизаторами работал последний раз год назад, наверное. Я про то и говорю - нужно исключительно json api. Все view в современном мире берет на себя клиент, а тк мир не совершенен и есть поисковики, не понимающие js, появились технологии позволяющие не только DOM обновлять, но и html генерить. Из абсолютно такого же кода.
Из такого подхода туча плюсов, Symfony/Yii/Laravel-Forms - в мусорку. Assetic/Huetic - в мусорку. Всяческие переводы, вообще все что V в MVC - в мусорку.

fixxxer · 21 Окт 2015

hell0w0rd написал(а):
Смотря что подергать. Если нужно атрибуты вытащить - есть механизм ссылок. Если нужно встроить плагинчик который будет менять DOM, допустим wysiwyg, в render необходимый минимум разметки, инициализация в componendDidMount, shouldComponentUpdate => false. То есть реакт никогда не полезет обновлять dom и не наткнется на чужой html. Пример обертки

Именно менять. С shouldComponentUpdate понятно, но это по сути отказ от плюшек.

Вот у меня есть хороший пример под рукой. N-уровневое меню с выпадашками (типа как в бутстрапе), в DOM-е расположено где угодно (в т.ч. внутри overflow:hidden). Размеры и количество пунктов заранее неизвестны. Если какие-то пункты не помещаются (в т.ч. после любых ресайзов) - надо убрать что не влезло и добавить пункт "еще", куда уедет с первого уровня что не влезло (и станет вторым уровнем, его подпункты 3-м). Список пунктов тоже может меняться в процессе работы приложения. Вот как это красиво сделать на реакте?

А насчет ContentEditable есть мнение, что DOM менять как раз не надо. Я тут аж два специализированных визивига писал, многократно желал всяческих кар придумавшему этот гребаный execCommand и упоротые ranges, с мнением полностью согласен. Реакт на эту идею должен очень неплохо лечь.

fixxxer · 21 Окт 2015

hell0w0rd написал(а):
Нет. Вообще с шаблонизаторами работал последний раз год назад, наверное. Я про то и говорю - нужно исключительно json api. Все view в современном мире берет на себя клиент, а тк мир не совершенен и есть поисковики, не понимающие js, появились технологии позволяющие не только DOM обновлять, но и html генерить. Из абсолютно такого же кода.
Из такого подхода туча плюсов, Symfony/Yii/Laravel-Forms - в мусорку. Assetic/Huetic - в мусорку. Всяческие переводы, вообще все что V в MVC - в мусорку.

Так presentation никуда не делся. Во-первых, он есть на клиенте. Во-вторых, сборка json-а из пачки моделей - это тоже Presentation layer.

Формы - смотря что иметь в виду, если на уровне "валидатора-фильтра реквеста" - полезно, а если про говнохелперы в шаблонах - всегда избегал этой ереси, еще во времена prototype.js.

Ну и слишком категорично. В одном проекте не надо, в другом - еще как надо. Иногда вообще надо статику генерировать

hell0w0rd · 21 Окт 2015

fixxxer написал(а):
Вот как это красиво сделать на реакте?

гм, если заранее не известны размеры - тебе в любом случае надо это дело срендрить, узнать размеры, перерендрить. Других вариантов нет ни на одном фреймворке. Единственное что мне в реакте больше всего нравится - тебе не нужно всякие глупые el.classList.add('foo'), el1.hide() и тому подобные штуки делать. Просто обновляешь стейт, тем самым форсишь render, внутри которого все и выводишь.
PS хотя теоретически ты размеры можешь узнать, если стили генерить внутри компонента. А кол-во ты знаешь, потому что в props передается. Единственное - parentNode не доступно, до componentDidMount.

fixxxer · 21 Окт 2015

если заранее не известны размеры - тебе в любом случае надо это дело срендрить, узнать размеры, перерендрить

Да это понятно, но насколько вменяемо будет менять стейты из кода, напрямую работающему c DOM, особенно по какому-нибудь window resize event? Не вылезут ли тут race conditions во все поля?

Может, какой-то лок надо делать?

Размеры без рендеринга я фиг узнаю - начнем с того, что в разных ОС и даже браузерах шрифты рендерятся по-разному.

UPD: если следить за стейтом и складывать в очередь (или вообще через flux прокрутить) - вроде все ок должно быть. Попробую

hell0w0rd · 21 Окт 2015

fixxxer написал(а):
Да это понятно, но насколько вменяемо будет менять стейты из кода, напрямую работающему c DOM, особенно по какому-нибудь window resize event? Не вылезут ли тут race conditions во все поля? Может, какой-то лок надо делать?

У меня не было такой проблемы. Надо понимать, что react не 1.0, так что в предыдущей версии, на пример, были проблемы с серверным пререндером select с defaultValue. Я только issue открыл, оказалось уже пофиксили.
Надо было простой бесконечный скролл сделать, там как раз глобальное событие, все ок, все работает: https://gist.github.com/nkt/abd19ccfa57eff92d0ea.
И на счет работы на прямую с DOM. Либо ты туда не пускаешь реакт, либо делаешь обновления state и в render уже реакт сам вычислит изменения.

fixxxer · 21 Окт 2015

Ну это ясно... Я вот думаю, что будет, если евент прилетит аккурат между componentWillUpdate и componentDidUpdate.

hell0w0rd · 21 Окт 2015

fixxxer написал(а):
Ну это ясно... Я вот думаю, что будет, если евент прилетит аккурат между componentWillUpdate и componentDidUpdate.

ничего не будет. все изменения собираются в кучку. Поэтому у setState интерфейс такой: setState(state, callback);

stalxed · 21 Окт 2015

А каковы шансы, что тяжелый frontend(рендеринг шаблонов на стороне клиента) умрет как flash?
Или наоборот это будет использовано в большинстве сайтов, как само собой разумеющееся?

stalxed · 21 Окт 2015

hell0w0rd написал(а):
А node.js еще ко всему прочему позволяет шарить код между клиентом/сервером (валидация, шаблоны) и делать universal приложения. Это когда вместо пустого index.html по запросу отдается весь контент, а дальше работает как обычное SPA. Такого без node.js либо невозможно, либо сложно, а значит дорого, сделать.

Т.е. по любому URL можно собрать обычную html страницу, а дальнейшие перемещения по сайту осуществляются без перегрузки всей страницы?

Подобное я видел в OroCrm.
Мы можем запросить любую страницу(например http://demo.orocrm.com/desktop/account/view/37), сгенерится html код страницы.
Дальше перемещения без перегрузки всей страницы.
Html шаблоны генерятся symfony/twig.

Вот как они это наколдовали:
https://github.com/orocrm/platform/blob/master/src/Oro/Bundle/UIBundle/Resources/doc/reference/client-side-architecture.md

Реально не особо врубаюсь

Но фишка прикольная, symfony шаблоны twig получается могут собираться как на сервере, так и на клиенте(и валидация тоже, как на сервере, так и на клиенте, подхватывает сам стандартный симфоневский validation.yml).

@hell0w0rd если понимаешь, объясни пожалуйста как это работает

, мне очень понравились их шаблоны, с одной стороны везде можно загрузить страницу целиком, с другой стороны с неё возможен переход используя ajax(иногда передавая только "серединку" страницы, в некоторых случаях используя только данные, которые рендерятся на клиенте).

Но это всё равно выглядит прикольнее, чем использовать node.js как backend.

AnrDaemon · 21 Окт 2015

hell0w0rd написал(а):
ну вот тебе сайтик на реакте

Не переварило. Тупо белый экран.

Но хотя бы не упало - уже радует.

fixxxer · 21 Окт 2015

У тебя там что, какой нить jelly bean со штатным браузером?

MiksIr · 21 Окт 2015

fixxxer написал(а):
У тебя там что, какой нить jelly bean со штатным браузером?

Дык ему ж сумочку жене, тут не до современных планшетов. На обед хватает - и то счастье.

флоппик · 21 Окт 2015

fixxxer написал(а):
А насчет ContentEditable есть мнение, что DOM менять как раз не надо. Я тут аж два специализированных визивига писал, многократно желал всяческих кар придумавшему этот гребаный execCommand и упоротые ranges, с мнением полностью согласен. Реакт на эту идею должен очень неплохо лечь.

Надо сказать, там в ContentEditable «стандартизированость» на уровне времен IE5.5

hell0w0rd · 21 Окт 2015

@stalxed, просто зная, что там twig, могу предположить, что на клиенте используется одна из его реализаций - twig.js/swig.js. Ну а дальше дело техники, протащили роуты, протащили валидацию, судя по доке там require.js и chaplin в качестве фреймворка.
Я про эту поделку одно могу сказать, скорее всего шаг в лево-право от того, что она может по умолчанию, надо будет написать кучу бойлепрейт кода, чтобы это все работало.
PS хотя судя по зависимостям в lib, шаблонизатора на клиенте нет. Может работает по принципу pjax. Хз, это все костыли. Ну и для админки вообще это все не нужно, там просто SPA за глаза.

grigori · 21 Окт 2015

hell0w0rd написал(а):
тк мир не совершенен и есть поисковики, не понимающие js, появились технологии позволяющие не только DOM обновлять, но и html генерить.

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

Приходит русский в грузинский магазин, спрашивает:
- Цинандали есть?
Продавец наливает из бочки в бутылку, достает этикетку, наклеивает, дает покупателю.
- А Киндзмараули?
Продавец наливает из той же бочки, берет другую этикетку, наклеивает, подает.
- А Хванчкара?
- Ест. Этыкеткы нэт.

stalxed · 21 Окт 2015

hell0w0rd написал(а):
@stalxed, просто зная, что там twig, могу предположить, что на клиенте используется одна из его реализаций - twig.js/swig.js. Ну а дальше дело техники, протащили роуты, протащили валидацию, судя по доке там require.js и chaplin в качестве фреймворка..

Нет, валидацию они сами генерят вручную, т.е. написали много кода, с нуля...

Twig генерится на стороне сервера, т.е. в шаблоне код типа:

HTML:

{% block content_data %}
    {% set generalData %}
        {{ form_row(form.name) }}
        {{ form_row(form.description) }}
    {% endset %}

    {% set id = 'order-action' %}
    {% set data = {
        formErrors: form_errors(form) ? form_errors(form) : null,
        dataBlocks: blocks
    } %}

    {{ parent() }}
{% endblock content_data %}

Twig на сервере его обрабатывает и посылает клиенту или целиком страницу(если первый заход) или только вот эту часть, как json типа {content: вот_эта_обработанная_хрень}.
Часть шаблонов рендерится полностью на стороне клиента, но небольшая часть(но весомая, например data gridы).

В чём минус такого подхода? Т.е. не полностью рендерить страницу на клиенте, а отдавать обработанный html части страницы, которая меняется?
Субъективно - это быстрее работает на стороне клиента, браузер как-то отзывчивые себя при таком ведет.

Backend vs Frontend

( ͡° ͜ʖ ͡°)

К.О.

Продвинутый новичок

Продвинутый новичок

К.О.

К.О.

Продвинутый новичок

К.О.

Продвинутый новичок

К.О.

Продвинутый новичок

Новичок

Новичок

Продвинутый новичок

К.О.

miksir@home:~$

promotor fidei

Продвинутый новичок

( ͡° ͜ʖ ͡°)

Новичок