Open arikon opened 11 years ago
Maybe bem move
?
@narqo I was thinking that bem move
is about moving BEM-entities between levels.
Agreed with @narqo. "move" is more intuitive and shorter for renaming. bem move --to-level=another mb?
bem mv
?
# rename block__elem1 to block__elem2
bem mv block__elem1 __elem2
# make block2 from block1__elem
bem mv block1__elem block2 --recursive
# rename block1 to block2
bem mv block1 block2
# rename block1 to block2 (with all its contents)
bem mv block1 block2 --recursive
# rename block1 to block2 at levels common.blocks and desktop.blocks
bem mv --level common.blocks --level desktop.blocks block1 block2
# move block from desktop.blocks level to common.blocks level
bem mv --from desktop.blocks --to common.blocks block
# move block (and all its contents) from desktop.blocks level to common.blocks level
bem mv --from desktop.blocks -to common.blocks block --recursive
Provide another cases please.
Shortcuts like block__elem
is good, but there is bem create
with other api. I have read blog post and I totally agree with veged.
bem mv
could be a shortcut to bem move
, mv and move just about the same for me
@corpix It is fixed already, see #319 and #322
@arikon oops, sorry. Missed this
Sergey Belov notifications@github.com wrote:
@corpix It is fixed already, see #319 and #322
Reply to this email directly or view it on GitHub: https://github.com/bem/bem-tools/issues/317#issuecomment-10937916
@arikon are you working on this already?
@bariscicek I've started and then postponed my work
@arikon Maybe you can share your code so I can continue working on this issue?
I'll push it later today!
30.03.2013, 00:55, "Baris Cicek" notifications@github.com:
Maybe you can share your code so I can continue working on this issue?
— Reply to this email directly or view it on GitHub.
Отправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail
@arikon cool thanks.
@bariscicek Just pushed bem-mv
branch
@arikon I just started working on the branch. I haven't committed anything, but first Ineed to clarify some stuff since it might be related with design decisions.
First of all I added a 'default level' option. Because otherwise you need to specify -s
and -t
everytime even though you're working in same level, which should be a case for most of the use cases. Now it uses -l
option to set sourceLevel
and targetLevel
if they weren't specified.
Now on copying the entities my major question is this. Is it valid to have an empty directory on source levels? There are cases that you might leave the empty directory if you specify a tech file. Or move command should remove all the empty directories left behind. (my idea is to check directories of source files and if htye are empty remove them). an example can be
bem mv block__elem_mod_val.css block2__elem_mod_val.css
In that case _mod
directory on source might be left empty. But mod
entity should exists.
Basically it relies on if an empty directoy in BEM tree has any meaning. If there's no meaning at all, I believe it's better to clean the empty directories that would prevent clutter in the development environment.
Once implementing the move function, I"ll fix the change tech. Then it's better to brainstorm about the contents of the files. A basic replace would be fine but it might also break files. Maybe there should be a git-type of conflict or approve question before applying replace bem entity names. I remember I read a similar proposal on yandex club discussion over the topic, but could not understand very well. (limited pa-ruskiy over here.)
@arikon I need more info about BEM entity changes. First of all what's the point? I don't see any use case. Second, how it could be possible? For example for a tree block1_elem1_mod
you want to move it as an element elemNew
. So that content of block1
will be content of __elemNew
and content of elem1
will be _elem1
(ie. a mod) and _mod
will be a value indeed? I'm trying to say, once you try to move the hierarchy one level up you lose the logic of BEM.
I think it's not necessary to change BEM entity types. But we should discuss about the refactoring of files using the .tech
files update
functions that should be described. Do you have any idea for that? I believe there should be a default regex for the 'BEM entity' names per .tech
. And it should be default a direct replace. But tech file should describe its regex in case, (for example css tech file should have /\.{block_name}/
kind of regex, so in case of a move a replace operation using this regex should be applied to files). What do you think?
Ok with recent patch, I'll be waiting for you to check. This includes content change as well which is pretty useful.
@bariscicek Sorry for the delay. Could you please open pull request for this?
@arikon Np bro. Let's talk about it ;-) Don't merge it btw. It should be refactored asap.
Implement
bem mv
command. See blog post for opinions on command line interface: http://clubs.ya.ru/bem/replies.xml?item_no=2066