I'm debating an API that looks somewhat like this (CoffeeScript syntax for brevity, think of it like JS-aware pseudocode):
system.rule(
rule: 'block',
prefix: '.',
transform: (prefix, rule) ->
"#{prefix + rule}"
)
system.rule(
rule: 'element',
prefix: '--',
transform: (prefix, rule) ->
if @inModifier? and @inBlock? then "#{@modifier.selector} #{@block.selector + prefix + rule}"
if @inElement? then "#{@element.selector + prefix + rule}"
if @inBlock? then "#{@block.selector + prefix + rule}"
else system.error "[FATAL]: rule `element` must be nested inside a parent rule."
)
system.rule(
rule: 'modifier',
prefix: '.\\+',
transform: (prefix, rule) ->
if @inElement? then "#{@element.selector + prefix + rule}"
else "#{@block.selector + prefix + rule}"
)However I think this might present a problem in regards to modules that are nested underneath multiple other modules (modifiers, elements or states...) I think having extra properties, like @blocks, @elements, @modifiers, for example, which resolve to an array of each respective module the selector belongs to, in order of which they appear, might be enough to make this a powerful enough API for selector transformation.
Also, it's important to note that each rule that is defined will be added to the @<module>, @<modules>, and @in<Module> API.
A further breakdown of exactly what's going on here - the rule parameter represents the argument that was passed to the module, @<module>.selector is the full CSS selector string of every module up until and including the current module. The prefix argument represents the prefix property passed to system.rule. You might think this is not needed, but if another user wishes to use your module, having the prefix and suffix set explicitly will allow them to customise it in system's settings.
system.error is basically a utility helper that throws node errors through postcss, which will make debugging a lot easier since right now, there's no way of throwing selector-level errors in system due to the nature of how they are detected.
I'm debating an API that looks somewhat like this (CoffeeScript syntax for brevity, think of it like JS-aware pseudocode):
However I think this might present a problem in regards to modules that are nested underneath multiple other modules (modifiers, elements or states...) I think having extra properties, like
@blocks,@elements,@modifiers, for example, which resolve to an array of each respective module the selector belongs to, in order of which they appear, might be enough to make this a powerful enough API for selector transformation.Also, it's important to note that each rule that is defined will be added to the
@<module>,@<modules>, and@in<Module>API.A further breakdown of exactly what's going on here - the
ruleparameter represents the argument that was passed to the module,@<module>.selectoris the full CSS selector string of every module up until and including the current module. Theprefixargument represents theprefixproperty passed tosystem.rule. You might think this is not needed, but if another user wishes to use your module, having theprefixandsuffixset explicitly will allow them to customise it insystem's settings.system.erroris basically a utility helper that throwsnodeerrors throughpostcss, which will make debugging a lot easier since right now, there's no way of throwing selector-level errors insystemdue to the nature of how they are detected.