Skip to content
This repository has been archived by the owner on Feb 6, 2018. It is now read-only.

Refactored walk arguments #30

Merged
merged 1 commit into from
Jul 2, 2015
Merged

Refactored walk arguments #30

merged 1 commit into from
Jul 2, 2015

Conversation

blond
Copy link
Member

@blond blond commented Mar 27, 2015

Resolved #15

1. The second argument now expects config instead of options.

Options by default now should be specified in config.defaults instead of options.

Before:

walk(['blocks'], { sheme: 'flat' });

After:

var config = {
    defaults: { sheme: 'flat' }
};

walk(['blocks'], config);

2. Info about levels (scheme and naming) now need specify in config.levels instead of levels arguments.

The levels argument as Array is no longer supported.

Before:

walk([{ path: 'blocks', sheme: 'flat' }]);

After:

var config = {
    levels: {
        blocks: { sheme: 'flat' }
    }
};

walk(['blocks'], config);

@eGavr
Copy link
Contributor

eGavr commented Mar 27, 2015

Типо теперь можно будет сканить не олько уровни, но и конкретные блоки?

@blond
Copy link
Member Author

blond commented Mar 27, 2015

@eGavr, нет :) Но это шаг к этому.

@eGavr
Copy link
Contributor

eGavr commented Mar 28, 2015

Я не понимаю, почему не научить bem-walk сканировать не только уровни, а и любую сущность в принципе?
@andrewblond я знаю, что если ты уперся, то тебя не переубедить, но послушай пользователя, я а черт возьми, им я являюсь :) сканирование строго уровней решает частную задачу и мне у себя приходится реализовывать логику фильтрации нужных сущностей. а теперь вопрос : зачем мне это уметь делать, если этот вроде как неплохо выполнить чисто с помощью сканера уровней?

Если мне нужен будет bem-walk на еще нескольких пакетах, то снова реализовывать эту логику, так может вынести ее в сам bem-walk?

Ты когда-то давно говорил, что таким способом мы потеряем в скорости... И че?
Какой смысл в тулзе, если главное в ней не ее прямая функциональность, а ее скорость? зачем ограничивать бэнчмарками пользователей? и добавляем функционал (не бесполезный, а нужный) - теряем в скорости + какая разница, где я эту скорость потеряю, используя bem-walk или подключив bem-walk и все равно допилив его? итог один - скорость мы потеряем в любом случае.

В общем, ИМХО, для bem-walk это будет не лишним :

  1. уметь сканировать что угодно , понимать , выдавать результат
  2. иметь свой уже наконец определенный стандарт вывода, а пользователь уже сам решает, что ему надо из этого
  3. уметь ругать НЕ БЭМ-сущности, а точнее хотя бы давать какую-то инфу по ним . А какое применение? а теперь представь, что ты пишешь проект, три часа ночи и у тебя какой-то элемент не приезжает... и ты такой сидишь-сидишь после 3 чашек кофе и очень долго не можешь заметить, что ты элемент обозвал через одно подчеркивание, ну а файлы в нем как надо через два. такие задачи bem-walk тоже мог бы решать.

@Yeti-or
Copy link
Member

Yeti-or commented Mar 28, 2015

@eGavr а как же делать только одну вещь, но делать её хорошо?

2015-03-28 9:07 GMT+03:00 Evgeniy Gavryushin notifications@github.com:

Я не понимаю, почему не научить bem-walk сканировать не только уровни, а и
любую сущность в принципе.
@andrewblond https://github.com/andrewblond я знаю, что если ты уперся,
то тебя не переубедить, но послушай пользователя, я а черт возьми, им я
являюсь :) сканирование строго уровней решает частную задачу и мне у себя
приходится реализовывать логику фильтрации нужных сущностей. а теперь
вопрос : зачем мне это уметь делать, если этот вроде как неплохо делать
чисто с помощью сканера уровней?

Если мне нужен будет bem-walk на еще нескольких пакетах, то снова
реализовывать эту логику, так может вынести ее в сам bem-walk?

Ты когда-то давно говорил, что таким способом мы потеряем в скорости... И
че?
Какой смысл в тулзе, если главное в ней не ее прямая функциональность, а
ее скорость? зачем ограничивать бэнчмарками пользователей? и добавляем
функционал (не бесполезный, а нужный) - теряем в скорости + какая разница,
где я эту скорость потеряю, используя bem-walk или подключив bem-walk и все
равно допилив его? итог один - скорость мы потеряем в любом случае.

В общем, ИМХО, для bem-walk это будет не лишним :

  1. уметь сканировать что угодно , понимать , выдавать результат
  2. иметь свой уже наконец определенный стандарт вывода, а пользователь уже
    сам решает, что ему надо из этого
  3. уметь ругать НЕ БЭМ-сущности, а точнее хотя бы давать какую-то инфу по
    ним . А какое применение? а теперь представь, что ты пишешь проект, три
    часа ночи и у тебя какой-то элемент не приезжает... и ты такой
    сидишь-сидишь после 3 чашек кофе и очень долго не можешь заметить, что ты
    элемент обозвал через одно подчеркивание, ну а файлы в нем как надо через
    два. такие задачи bem-walk тоже мог бы решать.


Reply to this email directly or view it on GitHub
#30 (comment).

@blond
Copy link
Member Author

blond commented Mar 28, 2015

@eGavr, про частичное сканирование есть задача — #14. От неё никто не отказывался ;) Проблема в том, задача сложная, и за один день её не запилить.

что если ты уперся, то тебя не переубедить

Это заведомо ложное утверждение =)

Что касается скорости —это очень важная фича, которая заявлена изначально. Терять её для всех, ради задачи не для всех — неправильно.

По поводу разных фич: не хочется превращать тулзу в убер-штуку, которая умеет абсолютно всё. Политика развития в том, что бы инструмент умел общие (читай как common, не merged) для всех вещи, но позволял у себя реализовать любые выкрутасы.

Если ты считаешь, что какие-то задачи можно решить проще — заводи ишью по каждому вопросу, будем обсуждать ;)

  1. иметь свой уже наконец определенный стандарт вывода, а пользователь уже сам решает, что ему надо из этого

Что ты имеешь ввиду? Если ты о данных каждого встретившегося файла, от он такой — #12. Но если добавлять другие сущности/события валкера, то у них формат может быть другой, что вроде логично — #20.

  1. уметь ругать НЕ БЭМ-сущности

Для каждой схемы, это довольно индивидуальное поведение. Скажем для flex или flat схем будет очень странным вообще ругаться. Для nested да, я понимаю нужность этого кейса.

Кроме того, способ ругаться тоже не очень понятен: варнинги, ошибки, события?

Если есть предложить что-то конкретное — заводи ишью, обсудим ;)

@eGavr
Copy link
Contributor

eGavr commented Mar 28, 2015

По поводу разных фич: не хочется превращать тулзу в убер-штуку

ээээ... bem-walk - это сканер бэм сущностей по задумке, я так понимаю, поэтому добавление функционала ПРО СКАНИРОВАНИЕ СУЩНОСТЕЙ не превратит тулзу в убер штуку, а улучшит ее для пользователя.

Что ты имеешь ввиду? Если ты о данных каждого встретившегося файла, от он такой — #12.

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

Кроме того, способ ругаться тоже не очень понятен: варнинги, ошибки, события?

Пожалуй стоит просто давать какую-то инфу, что файл найден и не пропускать его, например, имени и полного пути было бы достаточно, ну и какое-то отдельное поле , которое бы говорило, что это не БЭМ сущность.

@blond blond self-assigned this Jun 21, 2015
@blond blond added the review label Jun 21, 2015
**1. The second argument now expects `config` instead of `options`.**

Options by default now need specify in `config.defaults` instead of
`options`.

*Before:*

```js
walk(['blocks'], { sheme: 'flat' });
```

*After:*

```js
var config = {
    defaults: { sheme: 'flat' }
};

walk(['blocks'], config);
```

**2. Info about levels (scheme and naming) now need specify in
`config.levels` instead of `levels` arguments.**

The `levels` argument as `Array` no longer supported.

*Before:*

```js
walk([{ path: 'blocks', sheme: 'flat' }]);
```

*After:*

```js
var config = {
    levels: {
        blocks: { sheme: 'flat' }
    }
};

walk(['blocks'], config);
```
blond added a commit that referenced this pull request Jul 2, 2015
Refactored `walk` arguments
@blond blond merged commit fe2a480 into master Jul 2, 2015
@blond blond removed the review label Jul 2, 2015
@blond blond deleted the issue-15 branch July 2, 2015 21:58
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move level info to config
3 participants