Где есть человеческое управление компонентами (интерфейса)?

В реакте: компонент делаем классом, рендер разбиваем на кусочки, в суперклассе переопределяем нужные кусочки рендера. Получаем тот же компонент с измененной версткой, без особо ужасного дублирования кода.

Но если надо много компонентов единообразным образом менять, то даже не знаю.

К сожалению, не решает проблему, если надо изменить одну вещь из двух разных внешних модулей.
Со стилями и яваскриптом такой проблемы особо нет. А с шаблонами есть.

Самый простой пример - добавить 2 пункта в меню (конкретно это обычно решается иначе, но для примера сойдет)

Я пилю свою компонентную либу года эдак с 2012, учитывая, что она обходится с DOM-структурой как с объектами, то я помещаю нужные мне узлы в объектные переменные (setas - специальный механизм для этого)
https://github.com/special-k/redtea#Виджеты-1

Собственно, как бы я не менял потом верстку, нужный мне узел всегда в одной и той же переменной.

createDom - обычный метод, переопределяется при обычном наследовании, никакой магии. Все просто.

Не совсем понял, как это поможет вносить изменения.

Меня интересует механизм, которым сторонний код может описать, как он хочет подкрутить виджет. Особенно для случаев, когда несколько приложений хотят подкрутить другое в одном и том же месте.

Например, для CSS правило выглядит «допиши XXX в конец файла стилей». Для яваскрипта, если есть глобальный медиатор - «воткнись на эвент YYY с приоритетом ZZZ».

Как для шаблонов (или DOM-а который генерится из кода) - ни фига не понятно. Точнее, я не видел способов которые бы мне понравились.

2 пункта меню это стейт в реакте -> водится к изменения чего то в JS из двух файлов. Темы наверное можно так же разруливать оверрайдом файлов с компонентами как обычно делают с шаблонами.

1. Допустим я хочу другой скин для сайта. Хорошо если мне повезет и достаточно изменить CSS. А если еще и верстку?

во многом это решает MVC-культурка: зависит от степени реализации, изоляции MVC, понимания без тупняка авторами решения. Суть если есть разделение и оно реализовано грамотно - любой элемент MVC можно менять независимо (в теории)

Соответственно, грамотная реализация MVC, позволяет как минимум представления (V) менять как перчатки, без изменений в модели и контроллере т.е. независимо. Это идеал к которому можно стремиться. Смена темы, это тоже представление.

На практике, все превращается порою в компост и зачастую элементы MVC имеют жесткую связь между собой - любое изменение в одном из элементов, вызывает деструктивный диссонанс в другой. Из-за сложности вопроса и синдрома блуждания в трех соснах, решения обрастает всевозможными подпорками, прокладками и прочими излишними сущностями... Хотя и возможны достаточно простые и лаконичные решения.

Кстати, да xml+xslt умеет различные трансформации, но не совсем идеален.

Оверрайды же работают в шаблонах до первого столба. Пока оверрайд один - все пашет. Как только из 2 разных мест полезут одно и тоже оверрайдить - настанет пендык.

Из более-менее устойчивого я видел только БЕМ-овские xslt-трансформации. Но там всё вцелом довольно гиморно описывать, и в тот же реакт подобное уже не привинтить.

был такой ужас и страх: dojo не знаю как он жив или нет, но там это решалось, хоть и страшно

Не, как сделать из говна и палок я знаю. Мне интересно как сделать красиво. Вроде проблема давняя, кто-то уже мог решить.

Ну так из двух мест не надо. Если ты хочешь решение - 'добавить в любое место дерева произвольное количество элементов' не делая заранее экстеншн поинтов, то такого нигде из коробки нет. Хотя наверное как то можно накостылять с реактом. Но получится чото типо xml+xslt :D i.e. можно сделать какие-нибудь функции, которые в колбек полючают дерево которое будет рендерить реакт по такомуто xpath и там чото с ним делать. Но так как эстеншн поинтов сильно меньше чем разметки - проще делать экстеншн поинты.

Добавили модуль блогов и на карточку юзера понадобилось добавить ссылки из бложика.

В реакте обычно просто передают массив(или чонить более хитрое) компонентов которые ты хочешь отрендерить и дальше контейнер сам страдает.

Точнее, я не видел способов которые бы мне понравились.

Ну суть функция, которая при одних параметрах выдает одну структуру, при других - другую. В шаблонах это выражается во вкраплениях кода.

Ну вот мне как раз интересно что-то типа xml+xslt но с человеческим лицом, а не как в BEM.

Альтернативы, там где массивы на шаблон мапятся и можно содержимое массива подкрутить - это другое. Это когда ты говоришь «хочу чтобы конкретно в этом месте расширялось вот так». Такое у меня используется, просто это не везде удобно.

То есть я хочу что-то более интересное, чем ручное расставление экстеншен поинтов.

что-то более интересное, чем ручное расставление экстеншен поинтов

приведи пример модификации исходного шаблона

Ну дык вопрос в том, как получать эти вкрапления. Чтобы было гибко и удобно.

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

Ну представь что у меня есть простая менюшка со статическим содержимым. И чтобы много не программировать, я просто заверстал все пункты, вместо того чтобы делать массив, скармливать его циклу и предусматривать возможность модификации этого массива.

А потом какое-то расширение захотело добавить еще один элемент в конец меню. Подобное надо очень редко. Фигарить ради этого везде расширяемые меню как-то не айс.

Можно работать без html, например с абстракциями вроде virtual dom. Вполне возможно, что с какими-то другими сущностями можно добиться вменяемого результата.

Можно работать без html, например с абстракциями вроде virtual dom.

не в это дело 8) а в том что вся эта кухня была изначально сделана для текста, гипертекста. Щас на оном строят интерфейсы, пытаются css-ом делать лайауты (при том до сих пор нельзя сделать тупой горизонтальный алигн! без хаков) а js-ом добавлять динамику - пререстраивая dom.

при том они толькотолько начали делать CSS Grid Layout, еще не известно с каким результатом и когда оно будет работать в браузерах.

Полагаю что к тому времени когда эта куча костылей будет удобна для построение UI, народ уже вовсю будет рисовать кнопочки в canvas и это будет гораздо быстрее работать

На самом деле это просто реализуется. Я по молодости проектировал фреймворк (до стадии запиливания не дошло) для замены tapestry5 и как раз думал о подобной фиче.

Для этого нужно было параллельно шаблону компонента объявить свой шаблон. И показать, что мы наследуем и переопределяем основной шаблон. Дальше директивами <override id|xpath="...«/> можно было переопределять элементы из основного шаблона. При этом имея this на основной шаблон, т.е. можно было пользоваться данными основного шаблона.

При желании можно было объявить и класс, в котором делать какую-то доп. логику для расширенного шаблона.

С того времени много воды утекло и я вновь пилю фреймворк и пока не вижу для себя необходимости в этой фиче. Но добавлю это в TODO, не помню зачем мне это было раньше нужно, но может где в будущем пригодится...

Стране нужен 64-битный HTML, 32-битный устарел :)

при том они толькотолько начали делать CSS Grid Layout, еще не известно с каким результатом и когда оно будет работать в браузерах.

В хроме уже работает, если включить экспериментальные флаги.

народ уже вовсю будет рисовать кнопочки в canvas и это будет гораздо быстрее работать

Не будет, HTML+CSS+DOM гораздо гибче всех этих кнопочек в canvas'e.

Не будет, HTML+CSS+DOM гораздо гибче всех этих кнопочек в canvas'e.

Разупорись солнышко, ты утверждаешь что три технологии гибче рисования вручную. Нельзя так напиваться в понедельник.

рисования вручную

Если тебе надо рисование вручную, то можешь делать это на SVG или вставить img. Но HTML+CSS+img обычно достаточно, чтобы сделать уникальный интерфейс и не рисовать вручную.

Если тебе надо рисование вручную, то можешь делать это на SVG или вставить img.

омг, когда протрезвеешь приходи

(при том до сих пор нельзя сделать тупой горизонтальный алигн! без хаков)

Флексбокс жи.

о я это пропустил

Это может достигаться за счет абстрагирования от реальных dom-структур компонента и соответственно упрощения. Как правило, каждый компонент позволяет в себя добавлять другие компоненты - это общепринятая точка расширения, которая автоматически есть у всех компонентов. Тогда ты легко добавляешь новый пункт в меню. Т.е. получается эдакий shadow dom. Если у тебя 5 вариантов куда нужно добавить элемент - то это неудачная структура компонентов.

Так же, можно в рамках одного компонента (или класса компонентов) прописать правила замены используемых компонентов, т.е.: «Вместо этого используй этот, если...».

как обеспечить изменение внешнего вида

Описание проблемы в исходном сообщение похоже ближе всего к фреймворкам, в которых разделены шаблоны от логики. Стоит посмотреть на Ractive.js и vue.js.

Считаю что тоже самое можно решить и средствами React с использованием любого шаблонизатора на js и подгрузку разных шаблонов.

Вот и для react готовое решение -> https://github.com/wix/react-templates

Если включить экспериментальные флаги = не работает. Ты же не будешь писать «включите флаг» на сайте. Ну и попробуй тем, что есть, сделать стандартные layout'ы какие-нибудь, потом расскажешь как оно.

Flexbox для layout'ов тоже хреноват. Лучше, чем было до, но недостаточно.

сделать стандартные layout'ы какие-нибудь, потом расскажешь как оно

Делал всё нормально работает, но только слишком много писанины получается. Поэтому в хроме мне проще флексбокс юзать.

Ты же не будешь писать «включите флаг» на сайте

Я делаю веб-приложение, которое оборачивает хром, а на старте я могу любые флаги задать. Тут кстати также речь шла о создании интерфейсов приложений, а не о создании сайтов. Поэтому «экспериментальные флаги != не работает».

А еще есть очень интересный проект от автора MyHTML и MyCSS https://github.com/lexborisov/Modest Если он запилит нормальный рендеринг для grid и flexbox, то все ваши десктопные рисования выкинут на мороз. Т.к. он решит оверхед хрома по памяти и времени запуска.

перепись говнокодеров использующих говнотехнологии

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

И чтобы у этого изобретение было человеческое лицо. Я пока видел только по частям - либо человеческое, либо арсширяемое.

Ты про теорию все правильно говоришь, но меня уже практика интересует, про теорию я в курсе.

Например в своей библиотеке я регистрирую виджеты и менеджеры в приложении по имени, в принципе мне не сложно реализовать второй сценарий с подменой компонентов, я такое уже сделал для менеджеров. Первый у меня реализован изначально.

В react и пр.. Ну хуки должны быть какие-то на пирсинге.. С DSL проще похоже, там всегда идет вызов каких-то функций, которые сами по себе уже хук.

Адресовать-то как потом, куда именно надо зацепиться?

Что-то типа селекторов например, или id. В любой форме но с каким-то похожим смыслом. Чтобы это было для людей а не для роботов.

Если ты будешь дробить на компоненты вплоть до тега, потом заколебешься это вместе собирать.

Если ты будешь дробить на компоненты вплоть до тега, потом заколебешься это вместе собирать.

Спорно.. Компоненты дробятся по функциональному назначению, потому они будут собираться в некоторую осмысленную систему, в которой звенья можно заменять на аналогичные.

А количество элементов в компоненте не принципиально.

был такой ужас и страх: dojo не знаю как он жив или нет, но там это решалось, хоть и страшно

Живее всех живых. На это ещё навешивают набор своих полуглючных компонент, встраивают в свои фреймворки и это приходится использовать.

Где есть человеческое управление компонентами (интерфейса)?

GWT, extJS - эти технологии ближе всего к сути js+html. И соответственно они обеспечивают достаточно человеческое управление.

extJS - эти технологии ближе всего к сути js+html. И соответственно они обеспечивают достаточно человеческое управление.

Ложь. ExtJS хорошо только до тех пор пока штатных функций хватает. Но как только надо какое-то поведение сильно переделать, то приходится копаться в ацких дебрях (например, приватных методах). В следующий раз хорошо подумаешь брать extjs или делать полностью самому. Последнее может оказаться проще.

Ложь.

не употребляй таких слов и будешь выглядеть чуть-чуть умнее.

поработаю капитаном:

Но как только надо какое-то поведение сильно переделать

Не существует каких-нить фрейморков, где сильное изменений стандартного поведения, легко и приятно. А вообще это называется «я не шарю и хочу сделать через жопу». Если тебе надо сделать сильно другое поведение, надо взять инструмент, где это поведение есть.

не употребляй таких слов и будешь выглядеть чуть-чуть умнее.

это не важно

Не существует каких-нить фрейморков, где сильное изменений стандартного поведения, легко и приятно.

Фреймворков наверное и не существует, а библиотеки, решающие свою одну задачу, есть. И такие библиотеки проще интегрируются с другими. Так сказать из небольших кирпичиков бывает проще собрать то что нужно, вместо использования каких-то огромных готовых блоков.

А вообще это называется «я не шарю и хочу сделать через жопу».

Это называется sencha зажралась и хочет сильно много за extjs.

Если тебе надо сделать сильно другое поведение, надо взять инструмент, где это поведение есть.

Согласен. Только потом связать это с другими частями extjs не будет просто.

Лет 5 назад рекомендовать extjs имело смысл, но не сейчас же.

Тем более ни extjs, ни gwt сами по себе не решают исходную задачу. В extjs конечно есть шаблоны, но преимуществ это не даёт никаких. Тем более если предполагается сразу закладывать возможность сильно кастомной вёрстки. Это будет больше похоже на перепись компонентов extjs самому с нуля.

Смысл в том, что в идеале нужно сначала проектировать проект, утверждать дизайн и тз, а уж потом кодить. А не на лету менять функциональность. Меня такие клиенты (кто без тз) дико выводят из себя. Компоненты хреначу вот так, либо по старинке - css отдельно, js отдельно.

http://vuejs.org/guide/application.html#Single-File-Components

которую можно мутировать без предварительного резервирования точек расширения в явном виде.

а в чем проблема с точками расширения? В ООП программировании это часть архитектуры. Если структура изменятеся, надо думать над централизованным изменением архитектуры.

Наверное, можно разрешить какой-то манки-патчинг на уровне шаблонов. Если там XML - прикрутить XML трансформации. Для ООП всегда можно намутить какие-то трансформации тоже, в простейшем случае - миксины.

НО имхо это приведет к тоннам говнокода, когда никто не знает что и как работает, а может только запатчить чтобы не развалилось.

Имхо, работу архитектора никто кроме архитектора не сделает (на текущем уровне развития технологий, пока не изобрели ИИ)

А для поддержания архитектуры нужны:
- централизация (центализованное архитектурное видение, управление конфигурацией, четкое централизованное понимание командой «правильного способа делать вещи»)
- дисциплина
- отлаженные процессы («что делать, когда нам нужно добавить новый экстеншен поинт»)

И вот я думаю, что нужно обязательно как можно больше статических проверок со стороны компилятора, чтобы часть контроля за целостностью перенести с разработчика на автоматические тулзы

И автотесты желательно какие-то иметь, да (тесты по сути - еще один уровень полу-статической проверки над исходным языком)

Т.е. супер-технология лежит не в плоскости «движок шаблонов», а в области социальной, как так скоординировать команду, чтобы она писала в правильном ключе относительно общего архитектурного видения (возможно, применяя при этом разные технические трюки типа поддержания целостности через использование строго статического языка шаблонов или проверок автотестами)

Ай, не надо мне за проектирование рассказывать. Тут продвинутый пилотаж а не дошкольная группа.

Выдохни, выдыхай скорее

ну у нас есть строгий язык шаблонов со всеми такими фичами, так что при переходе к шаблонам ты почти не замечаешь, что это уже вёрстка, а не Java. Но выложить не могу, проприетарщина проклятая потому что. Разве что написать заново на другом языке программирования :)

но без архитектора, который будет четенько проектировать архитектуру компонентов, бить плёткой отклоняющихся от курса Партии и сжигать молниями недовольных, это всё равно не взлетит - это основная часть магии :)

А вы не пробовали использовать от БЭМа не BEM XSLT, а другие шаблонизаторы? Например BEMHTML или BH? Это должно решать ваши задачи. Правда прийдется заиспользовать и сборщик от bem, например enb. Можно и gulp, но кажется там ещё нет всего для полного и безграничного счастья. Пример с gulp-ом можно посмотреть на движке https://github.com/bem-site/bem.info/, на которым сейчас собирается http://bem.info.

Ну и посмотрите, как реализована библиотека с web-компонентами https://github.com/bem/bem-components, но на первом этапе в её сборку и тестирование лучше не лезть.