Closed awinogradov closed 10 years ago
Зачем?
Чтобы передавать параметры непосредственно инпуту. Сейчас есть шорткаты для некоторых, но писать для всех не тру вей, а передавать надо например дата атрибуты, директивы mvc HTML5 валидации и т.д.
Зачем передавать data-атрибуты? У блока есть апи, его недостаточно?
Для тех кто не использует i-bem.js на клиенте
А каким образом происходит взаимодействие с блоком? Через апи чего? Кто/что будет гарантировать согласованность его состояния?
Старым дедовским способом через jquery селекторы, селекторы и директивы angularjs
Библиотека не предоставляет таких интерфейсов и не гарантирует никакой работоспособности в таких условиях.
Да, библиотека в таких условиях используется только для верстки
Для верстки можно брать готовый html (или доопределять шаблоны на своем проекте) и делать с ним все что хочется. Входной же bemjson представляет собой один из интерфейсов, который библиотека поддерживает, и раздувать его странными фичами, которые не нужны при нормальном использовании библиотеки, считаю нецелесообразным, и, более того, вредным.
Принято. Предлагаю услышать мнение не только наше с тобой, а я пока создам pull-request. Вообще странно читать настолько критичное восприятие. Если есть идеи как это реализовать иначе, то я буду за. Но если вы хотите чтобы все дружно заюзали full-stack, то это врятли. Все приходит со временем и если обеспечить им безболезненную миграцию, то все от этого только выиграют.
Предлагаю услышать мнение не только наше с тобой...
Полностью согласен с @dfilatov. Для «старого дедовского angular'а» можно взять CSS + HTML (по необходимости).
У нас нет первоочередной цели «чтобы все дружно заюзали full-stack». Цель — сделать стабильную и целостную библиотеку с нормальным (предсказуемым) API.
@verybigman я написал две идеи, как реализовать то, что ты хочешь:
offtopic: Еще мне тут стало интересно, как совместно используются шаблонизатор из angular и bemjson + шаблонизатор из bem-мира?
Такое ощущение, что я пытаюсь отвоевать 2 строчки кода. @dfilatov доопределение работает и сейчас, идея именно в том, чтобы мне не писать библиотеку с такими доопределениями, а просто использовать bem-components, а потом еще и i-bem.js. Посмотреть как работает ангуляр можно в generator-bem. Я даже не знаю, ребят, что мне вам ответить на то, что я, внеся доп фичу имею за собой команду, которая будет вам за это благодарна, а вы предлагаете мне использовать HTML. Думаю, что стоит закрыть в таком случае таск и впринципе не создавать их сл стороны тогда, а я продолжу делать то, что делал. Прикреплю сюда @tadatuta, чтоб он был в курсе.
2 строчки здесь, 2 строчки там, ведь правда, это тут же захочется добавить во все блоки? Я, вообще, себе очень слабо представляю, как этот подход можно экстраполировать на чуть более сложные блоки чем input, которые без js, написанного для них, не будут вообще работать. Мне кажется, что тут нужно думать в сторону возможности использования апи блока из других технологий (того же angular), а не в сторону того, как залезть во внутренние "кишки" блока и чего-то там подхачить.
Конкретная проблема - конкретное решение. Я подумаю об использовании апи, но не сегодня и не завтра. А завтра пойду делать проект на своих блоках. Лично мне не принципиально такое расширение в bem-components, оно у нас и так работает и bem-components не используется. И пока я только больше убеждаюсь в правильности такого решения. Я предложил улучшение, которое позволит мне переводить проекты на bem-components, да, пока только в верстке. Тот кто против пусть закроет issue.
Закрыл
Как минимум задачу надо переформулировать во что-то более конкретное: каких параметров в bemjson-API сейчас не хватает и зачем они нужны.
А именно слияние параметров value и placeholder с, возможно переданными, параметрами в controlAttrs (ex: {block: ‘input’, controlAttrs: { ‘data-test’: ‘olololo' } }). @tadatuta как договорились запиши таск на меня