-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolve Deps #2
Comments
/*
{
entities: [{ block: 'A' }],
dependOn: [
{
tech: bemhtml,
entities: [{ block: 'B' }]
}
]
}
*/ I don't like that in the resulting deps info about order of tech-dependencies is lost, and these deps are grouped by techs. Proposing another resulting format (it could be optional): /*
{
entities: [{ block: 'A' }, { block: 'B', tech: 'bemhtml' }]
}
*/ |
No, this information is not lost. It is important to understand why we need result. If we need to build JavaScript then dependencies with var myDeps = {
entity: { block: 'A' },
tech: 'js',
dependOn: [
{
entity: [{ block: 'B' }],
order: 'dependenceBeforeDependants',
tech: 'js'
}
]
};
var res = resolve(decl, deps, { tech: 'js' });
console.log(res);
/*
{
entities: [{ block: 'B' }, { block: 'A' }],
dependOn: []
}
*/ If we need to build JavaScript with BEMHTML then dependencies with var myDeps = [
{
entity: { block: 'A' },
tech: 'js',
dependOn: [
{
entity: [{ block: 'B' }],
tech: 'bemhtml'
},
{
entity: [{ block: 'C' }],
tech: 'bemhtml'
}
]
},
{
entity: { block: 'C' },
tech: 'bemhtml',
dependOn: [
{
entity: [{ block: 'D' }],
tech: 'bemhtml'
}
]
},
];
var res = resolve(decl, deps, { tech: 'js' });
console.log(res);
/*
{
entities: [{ block: 'A' }],
dependOn: [
{
tech: bemhtml,
entities: [{ block: 'B' }, { block: 'C' }]
}
]
}
*/
res.entities // we can concat JS files
var bemhtmlForJsDecl = res.dependOn[0].entities;
var bemhtmlForJsRes = resolve(decl, deps, { tech: 'bemhtml' });
console.log(bemhtmlForJsRes);
/*
{
entities: [{ block: 'B' }, { block: 'C' }, { block: 'D' }],
dependOn: []
}
*/
bemhtmlForJsRes.entities // we can compile BEMHTML files |
What if I need to mix files of different techs in a single flow? |
@arikon You're talking about different technologies or different extensions? Can you give real-life examples? |
@blond Different techs and exts
No =( |
You can resolve different exts at the time of parsing. For different techs I think that everything should remain as it is. Real-life example — |
Fixed in #59 |
API
The
resolve
method to supplement the declaration missing entities.Important: It takes into account the order dependencies of BEM-entities.
Object[]
decl
— list of BEM-entities. Each item is object. See, bem-naming.Object[]
deps
— list of dependencies between BEM-entities.Example:
Terms
Common
dependencies - dependencies where one entity depends on another entity, without taking in account specific techsResolve common dependencies
- resolve dependencies without specifying any techUnordered
dependencies - dependencies which ordering is not specified explicitly. (i.e.order
param is not set)Ordered
dependencies - dependencies which ordering specified explicitly (i.e.order
param is being set)Deps Format
Each item of deps list is
Object
.Object
entity
— BEM-entity that is dependent on otherObject[]
dependOn
— list of BEM-entities of which depends on entityExample:
This means that the block
A
depends on blocksB
andC
.Techs
Constraints can be not only between the BEM-entities but also between technologies.
Example:
Tech -> Block
This means that the
css
tech of blockA
depends on all techs of blockB
.Example:
Tech -> Tech
This means that the
js
tech of blockA
depends onjs
tech of blockB
.Deps By Techs
For cases when the technology is dependent on other technology in result will be add
dependOn
field. Each item ofdependOn
is object withtech
andentities
filed.Example:
Order
Depending provides information about the order:
dependenceBeforeDependants
— BEM-entity may require that the other BEM-entity will be before it.false
— BEM-entity may expect that the other BEM-entity will be before or after it.Example:
This means that the block
A
depends on of blockB
and require thatB
will be beforeA
.Priority
Rule 1: Try to keep the order of declaration.
Example:
Declaration: A, B, C
Dependency graph: B <- E (with
order: dependenceBeforeDependants
)Expected result: A, E, B, C
Rule 2: Try to keep the natural order for BEM-entities with same block scope (block and its mods, elems and their mods):
The text was updated successfully, but these errors were encountered: