Cool writeup. It is similar to how we normally handle any other strings that need to be used in multiple places (theme related stuff, event names, enums etc.) - dy defining constants.
Some random thoughts:
About the holy-wars, putting libraries like 'styled-components' asaide, inline-css is a must when assigning a dynamically calculated numeric values. For example, in the fancy drag and drop library the x and y transforms for the object being dragged and the objects that make room for it are all inlined.
Bundle size will increase because of this. Sometimes it matters, sometimes not so much.
One more note on bundle size. If I were to put this into a proper NPM "package", I could create deploy hooks that would essentially empty out the lookup class and replace the code with the raw text/number values for the CSS properties. But, for the time being, that kinda feels like overkill and I don't have the time to dive into that...
Another interesting option might be an IDE plug-in.
It could also maybe provide some documentation for each attribute/ value on the fly.
But yhea.. probably an overkill :)
Ideally, the plugin would be configurable, so you could drop in any object that would serve as a kinda "definition file". It could then be used in your autocompletes without needing to be bundled into the code itself.
It should be configurable, because even if this plugin worked beautifully, I'd hate to have to write another plugin (or find another one out there on the interwebs) the next time I have another set of commonly-used constants that I want to autocomplete.
You're absolutely right that, when you boil it down, this is just a basic shared constant. I'm just amazed/annoyed sometimes when I realize that there are no "pre-baked" constants for the important shit that I find myself googling over and over and over...
Totally agree about the inline-styling necessities (at times). I put that Holy War caveat in the article because, amongst some people, you simply cannot have an intelligent conversation about inline styles (especially, in React) without some pedantic jerk trying to shout you down. There's a whole other article on the horizon about this exact topic... One of my favorite (and simplest) justifications for inline React styles something like this: display : someCondition ? 'inherit' : 'none'. There's just no way that I'm gonna try to pack that away into two conditional CSS classes.
Good point about bundle size. I will freely admit that, more often than not, I pay this little attention, because in today's high-bandwidth environment, I feel that this is usually a "micro-optimization". But that's not meant to discount your accurate observation. Like any other library/class/utility that is providing nothing more than syntactic convenience, it's always a good idea to at least be aware of the cost in package size.
BTW, I do agree with the problem statement :)
I forgot to say in the original comment.
Remembering all of these css attributes and values and what they all do is like trying to memorize an encyclopedia.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Cool writeup. It is similar to how we normally handle any other strings that need to be used in multiple places (theme related stuff, event names, enums etc.) - dy defining constants.
Some random thoughts:
One more note on bundle size. If I were to put this into a proper NPM "package", I could create
deployhooks that would essentially empty out the lookup class and replace the code with the raw text/number values for the CSS properties. But, for the time being, that kinda feels like overkill and I don't have the time to dive into that...Another interesting option might be an IDE plug-in.
It could also maybe provide some documentation for each attribute/ value on the fly.
But yhea.. probably an overkill :)
Maybe something like
marketplace.visualstudio.com/items...
Ideally, the plugin would be configurable, so you could drop in any object that would serve as a kinda "definition file". It could then be used in your autocompletes without needing to be bundled into the code itself.
It should be configurable, because even if this plugin worked beautifully, I'd hate to have to write another plugin (or find another one out there on the interwebs) the next time I have another set of commonly-used constants that I want to autocomplete.
Thanks again for the thoughtful feedback!
You're absolutely right that, when you boil it down, this is just a basic shared constant. I'm just amazed/annoyed sometimes when I realize that there are no "pre-baked" constants for the important shit that I find myself googling over and over and over...
Totally agree about the inline-styling necessities (at times). I put that Holy War caveat in the article because, amongst some people, you simply cannot have an intelligent conversation about inline styles (especially, in React) without some pedantic jerk trying to shout you down. There's a whole other article on the horizon about this exact topic... One of my favorite (and simplest) justifications for inline React styles something like this:
display : someCondition ? 'inherit' : 'none'. There's just no way that I'm gonna try to pack that away into two conditional CSS classes.Good point about bundle size. I will freely admit that, more often than not, I pay this little attention, because in today's high-bandwidth environment, I feel that this is usually a "micro-optimization". But that's not meant to discount your accurate observation. Like any other library/class/utility that is providing nothing more than syntactic convenience, it's always a good idea to at least be aware of the cost in package size.
BTW, I do agree with the problem statement :)
I forgot to say in the original comment.
Remembering all of these css attributes and values and what they all do is like trying to memorize an encyclopedia.