Автозаполнение input браузером

[hell0w0rd]

Я в чем-то согласен с @fixxxer, объяснить что должно быть в умном, а что в тупом компоненте верстальщику бывает сложно. Но таки если объяснить - получается вообще офигенно.
Кстати скорее всего, если вам нужен фреймворк, у вас минимум верстки и дофига интерфейсов. А это значит, что от верстальщика больше требуется тупо библиотека компонентов, там логики вообще не надо, только биндинги проставить и прокинуть в них переданные коллбэки.

@fixxxer, а по твоему polymer, или грядущие веб-компоненты эту проблему решают лучше?

 

[MiksIr]

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

 

[hell0w0rd]

@MiksIr, разбивку на компоненты не должен делать верстальщик, ее еще дизайнер делает. Это конкретно касательно верстки.

 

[fixxxer]

Ну, как я понял, сложные компоненты - это уже неверный путь, и нужно бить их на более мелкие.

Обычный SRP. Презентационная логика даже одной сущности может быть сложным сам по себе.

 

[MiksIr]

@MiksIr, разбивку на компоненты не должен делать верстальщик, ее еще дизайнер делает. Это конкретно касательно верстки.

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

 

[MiksIr]

Обычный SRP. Презентационная логика даже одной сущности может быть сложным сам по себе.

Не вижу, как наличие или отсутствие разметки в компоненте нарушает SRP. Обязанность компонента - отрисовать, наличие в нем jsx не накладывает новых обязанностей.

 

[fixxxer]

@fixxxer, а по твоему polymer, или грядущие веб-компоненты эту проблему решают лучше?

Я бы не стал противопоставлять, это разные вещи и вполне могут жить вместе. Веб-компоненты больше годятся для не имеющих отношения к domain model, чисто UI-компонентов - какой-нибудь плеер там, или кастомный элемент управления (скажем, какой-нибудь sortable list). Но это будет иметь смысл, когда появится нативная реализация - shadow dom нормально не заполифиллишь, а всякие shady dom - да ну нафиг.

 

[fixxxer]

Не вижу, как наличие или отсутствие разметки в компоненте нарушает SRP. Обязанность компонента - отрисовать, наличие в нем jsx не накладывает новых обязанностей.

Никак не мешает, я сумбурно написал

Про SRP - это одобрение опущенного куска цитаты. А дальше я про то, что если в компоненте неизбежно сложная и подверженная изменения presentation-логика, дописывать такие компоненты будет, как правило, верстальщик (не дергать же разработчика из-за одного if-а), и все может закончиться печально.

 

[MiksIr]

@fixxxer, ну это решается помещением верстальщика в код-ревью. Оно в общем и так должно быть, ибо особо одаренные, которым "шаблона не хватило", могут и в отдельный слой логики влезть

 

[fixxxer]

Вот я понял, что меня смущает. Именно удобство написания кода. Когда в строке что-то наворотил - сразу звоночек звенит, а тут типа код же.

В общем, ты прав, полная аналогия с native php шаблонами и говнохелперами, оттуда вся неприязнь.

 

[hell0w0rd]

Кстати, если помните, facebook говорили, что это изначально на php и было написано. То есть это был их php шаблонизатор.
Я, кстати, видел проект, где react использовали просто как движок шаблонов, внутри render простыня на 200 строк и map внутри map внутри jsx. Но за это надо пару раз просто ударить по рукам. А еще лучше для eslint правило написать и сюда https://github.com/yannickcr/eslint-plugin-react запулреквестить.