You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The css function is great for constructing reusable mixins, but for that use-case, it's important that they can be embedded in a styled definition, which they can't. At least not as-is.
The vertical boolean switch, written like that, requires being tagged with the css function, otherwise it produces the literal string false where otherwise the flex-direction would appear. I don't want to rewrite such things to a ternary statement, because it is less readable, and should be unneccesary. So the css tag is more or less required.
Alternative solutions
Currently, I have to do this in order to make it work:
The reason I've marked this as a feature request, is because the styles property on the result of the css function, I could not find anything about in the documentation. So this is technically an undocumented feature, or basically a hack. And the problem is that I have no way of knowing whether the above alternative solution is correct, supported, and future-proof.
It seems to me like a simple improvement to allow embedding mixins like this, by simply not blindly assuming that everything mixed in, is a string, or is blindly converted to a string.
The documentation about css does mention how to do exactly what I'm asking, but in a slightly different way, as in the use of the css fucntion must always be used inside another function that recieves props. But those props won't magically contain specific switches that I need, that are defined elsewhere, outside props. It makes me believe that it's impossible (without the above hack) to just keep statically defined mixins around - they have to be functions.
The text was updated successfully, but these errors were encountered:
The function never even gets called, the console log never appears. It doesn't even get the chance to output anything meaningful. But this is what the documentation suggests I do.
All the more reason to get this added as a feature, because clearly it's not supported, even though somehow the documentation suggests otherwise - or I'm misreading it, as it's hard to tell what's what without type annotations in the examples.
The problem
The
css
function is great for constructing reusable mixins, but for that use-case, it's important that they can be embedded in astyled
definition, which they can't. At least not as-is.Proposed solution
I'm think something like so:
The
vertical
boolean switch, written like that, requires being tagged with thecss
function, otherwise it produces the literal stringfalse
where otherwise the flex-direction would appear. I don't want to rewrite such things to a ternary statement, because it is less readable, and should be unneccesary. So thecss
tag is more or less required.Alternative solutions
Currently, I have to do this in order to make it work:
Note the added
.styles
.Additional context
The reason I've marked this as a feature request, is because the
styles
property on the result of thecss
function, I could not find anything about in the documentation. So this is technically an undocumented feature, or basically a hack. And the problem is that I have no way of knowing whether the above alternative solution is correct, supported, and future-proof.It seems to me like a simple improvement to allow embedding mixins like this, by simply not blindly assuming that everything mixed in, is a string, or is blindly converted to a string.
The documentation about
css
does mention how to do exactly what I'm asking, but in a slightly different way, as in the use of thecss
fucntion must always be used inside another function that recieves props. But those props won't magically contain specific switches that I need, that are defined elsewhere, outside props. It makes me believe that it's impossible (without the above hack) to just keep statically defined mixins around - they have to be functions.The text was updated successfully, but these errors were encountered: