These are chat archives for bem/talk

22nd
Aug 2014
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 04:53
my thought is - specification should be minimal and easy to implement. as far I can see now, many stuff was added because “we need this shortcut in one place in bem-core” and “someone maybe could use it”. Also bem-core should be nice and clean. If developers of other libraries want to use it - they should not ask questions like “what is this field means, and why it not documented”.
Vladimir Starkov
@iamstarkov
Aug 22 2014 05:32

so "economy" after deprecating noDeps not so significant

you should deprecate it not for economy, but for not letting consumers use your code in bad way

if somebody wants to noDep some block it's a signal to block's maintainer to split it into smaller parts and not include them all
Vladimir Starkov
@iamstarkov
Aug 22 2014 05:39
implementing cost still make sense, because without low cost of logic implementing, there is no chance of competition have arisen, so code consumers will suffer. And I hope, you didn't want it. So let's deprecate noDeps.
competition among building tools, I mean
Alexej Yaroshevich
@zxqfox
Aug 22 2014 05:41
Can I use noDeps as plugin?
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 05:41
How?
Alexej Yaroshevich
@zxqfox
Aug 22 2014 05:42
somewhere in configuration: tech('deps.js').usePlugin('noDeps')
I think It's a solution. It will not exist in common, but as extension only. So who really need it will use it with all warnings.
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 05:44
This is not a solution, but hiding problem in a plugin.
You will always need this plugin, because bem-core contains noDeps
Alexej Yaroshevich
@zxqfox
Aug 22 2014 05:45
It's not a problem at all ;-D
It doesn't
bem-bl does, but it's depreacted
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 05:45
Any project, that using bem-core (as far I know) noDeps i-bem__init_auto block
i-bem__dom_init_auto
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 05:46
Searh in internal github
Alexej Yaroshevich
@zxqfox
Aug 22 2014 05:47
k
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 05:47
Almost any 38 projects in Yandex using it. :P
Alexej Yaroshevich
@zxqfox
Aug 22 2014 05:47
Then there is no reason atm to remove it ;-(
or decouple
Vladimir Starkov
@iamstarkov
Aug 22 2014 05:49
nope, core libs maintainers can restructure block i-bem__dom_init_auto to not force consumers use noDeps, and that's all
Seems to me that problem is only not enough good i-bem architecture
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 05:51
yup
if you get rid of this problem in i-bem - them you find no usages of noDeps
Alexej Yaroshevich
@zxqfox
Aug 22 2014 06:01
okok
Atm I didn't see a reason of using noDeps in i-bem__dom_init_auto ;-\
So I can't even talk about it.
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 06:03
It not used in it. It used to ignore it.
Alexej Yaroshevich
@zxqfox
Aug 22 2014 06:04
In projects?
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 06:04
Yep
Alexej Yaroshevich
@zxqfox
Aug 22 2014 06:05
+1 to refactor
Sergey Berezhnoy
@veged
Aug 22 2014 07:07
ok, guys, I've got your opinions, thanks! will think about it in future versions
Alexej Yaroshevich
@zxqfox
Aug 22 2014 07:08
Need an issue?
Sergey Berezhnoy
@veged
Aug 22 2014 07:09
nope, cause I'm not gonna do something concrete
will think about it in future versions
Alexej Yaroshevich
@zxqfox
Aug 22 2014 07:09
ah ok
Thanks
Yelena Jetpyspayeva
@mursya
Aug 22 2014 09:21
Few links in case you missed it: @csswizardry wrote a guide on CSS incl. BEM-like naming chapter http://cssguidelin.es/; @andersonorui_ wrote a piece on how to make Bootstrap even cooler with BEM https://medium.com/@andersonorui_/bem-sass-and-bootstrap-9f89dc07d20f
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 13:43
If I specify in i-bem__elem_mod_val.deps.js elem as html - is this means, that this deps would be for i-bem__html_mod_val?
Alexej Yaroshevich
@zxqfox
Aug 22 2014 13:43
Or for i-bem__html ?
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 13:45
Main question - deps file in block directory can define dependencies for other blocks (if I include properties of those blocks in deps file)?
Alexej Yaroshevich
@zxqfox
Aug 22 2014 13:48
For other blocks — hm. It's like node's require('c') for file a.js in b.js?
Alexej Yaroshevich
@zxqfox
Aug 22 2014 13:51
ffs
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 13:51
It places itself into other block (i-bem__html) mustDeps
@mursya @veged please help us
Sergey Berezhnoy
@veged
Aug 22 2014 18:30
@floatdrop it should be for i-bem__html (without mod)
about deps file in block directory with deps for other block — yes, it's possible
you can define deps for another block inside deps file of block
Sergey Berezhnoy
@veged
Aug 22 2014 18:36
main usage is defining ordered deps (mustDeps) for another block
in case when you need to say that b1 must go before b2 you can write b2.deps.js with mustDeps: b1 or b1.deps.js with b2 mustDeps b1
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 18:37
whose idea was that?
Alexej Yaroshevich
@zxqfox
Aug 22 2014 18:38
I feel global scope ;-D
Sergey Berezhnoy
@veged
Aug 22 2014 18:39
cause it is =) all blocks are in same "global" scope
Alexej Yaroshevich
@zxqfox
Aug 22 2014 18:42
Ye, sure. but the main question here is why blocks can access another deps. I think. It's not clear at all
nvm
Sergey Berezhnoy
@veged
Aug 22 2014 18:43
it's not actually about broke incapsulation — it's about nuance in form of describing order deps
just syntax
Sergey Berezhnoy
@veged
Aug 22 2014 18:51
also, here is an issue about deps — bem/bem-core#656
Alexej Yaroshevich
@zxqfox
Aug 22 2014 18:52
We though about move noDeps to plugin as well as some other rarely used extensions
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 18:53
it's not actually about broke incapsulation — it's about nuance in form of describing order deps
other deps should be described by their deps file imho
noDeps may be implemented by filtering blocks before/after dependencies resolution - so plugin it is.
Sergey Berezhnoy
@veged
Aug 22 2014 19:05
but you need file to write it — if main deps parser can't then you need something like b1.no-deps.js
Alexej Yaroshevich
@zxqfox
Aug 22 2014 19:06
deps parser shouldn't write anything actually
Sergey Berezhnoy
@veged
Aug 22 2014 19:07
I mean you as user need place to define your possible noDeps (in case if you need it)
Alexej Yaroshevich
@zxqfox
Aug 22 2014 19:07
it should collect and share links between blocks and lists/graphs
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 19:07
I don’t need file for that. From noDeps usage clear, that it always written in one place (for us it written in page deps) - so it can be moved to build configuration.
Sergey Berezhnoy
@veged
Aug 22 2014 19:08
write such info in page definition is violation of encapsulation — only block itself can know which blocks it noDeps
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 19:09
if this is possible by noDeps - then it will be used by consumers
think about it like public API to service
Alexej Yaroshevich
@zxqfox
Aug 22 2014 19:09
R you sure? ;-D
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 19:10
static/desktop.blocks/b-page/b-page.deps.js contains noDeps in our project
by page definition I mean b-page.deps.js
Sergey Berezhnoy
@veged
Aug 22 2014 19:11
@floatdrop can't catch the analogy — it is just inconvenient to use
you gonna describe all project blocks in one b-page
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 19:12
if noDeps can exclude dependencies from other blocks - then consumers will use that
Sergey Berezhnoy
@veged
Aug 22 2014 19:12
which is in my opinion violation of encapsulation for blocks
if consumers will use that it doesn't mean that they gonna write it all in one file for all blocks
not BEM way ;-)
it's like write all CSS in b-page.css
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 19:13
We define only subset of blocks in this files
And (I think) this block is extended by another b-page from lower level.
Alexej Yaroshevich
@zxqfox
Aug 22 2014 19:14
I think it's legit only if you redefining your page block on bundle level
Sergey Berezhnoy
@veged
Aug 22 2014 19:15
are you talking now only about deps between b-page and i-bem__dom_init_auto? cause if not, I'm still miss of point
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 19:15
yep
Alexej Yaroshevich
@zxqfox
Aug 22 2014 19:16
;-D
I think now it can be ignored. But yes, it should be discussed
Clean standard is a very good thing
Vsevolod Strukchinsky
@floatdrop
Aug 22 2014 19:18
I’m off to get some sleep. Good night every one, thanks for discussing this. Much information. Very appreciate.
Alexej Yaroshevich
@zxqfox
Aug 22 2014 19:20
Good night ;-)
Sergey Berezhnoy
@veged
Aug 22 2014 19:20
cu