-
Notifications
You must be signed in to change notification settings - Fork 308
[WIP] Make media query and :visited CSS rules unique #635
Conversation
@@ -73,7 +74,7 @@ function _topLevelRulesToCSS({ | |||
); | |||
|
|||
// CSS classes cannot start with a number | |||
const mediaQueryClassName = 'rmq-' + hash(query + ruleCSS); | |||
const mediaQueryClassName = `rmq-${styleId()}-${hash(query + ruleCSS)}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
styleId()
will execute every render. Since addCSS
no longer dedupes due to the incrementing number, you'll end up with many duplicate styles in the CSS, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure looks that way. The unique component id route may solve that issue, and I think it'd be a similar sized diff. Thoughts?
This reverts commit 6bf2895.
…ponent props once, allowing for deduping
The approach I just pushed no longer uses a counter, but a uuid set only once on component props. This gives us deduping back and prevents coupling the plugins to the |
You could also store the unique id in the component state (directly on the
|
…instances (won't run every render, which also means we don't have to check if it already exists!)
That's so much better, now it doesn't run every render and we don't have to check that we already set the styleID on the component. Thanks for the guidance! |
@@ -63,6 +64,7 @@ export default function enhanceWithRadium( | |||
|
|||
this.state = this.state || {}; | |||
this.state._radiumStyleState = {}; | |||
this.state._styleID = uuid.v4(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want this to be per-instance or per-component? #625 would be solved by per-component, but #593 it seems would not be.
If it is per-instance, you should move it directly to this
, and prefix it with radium, just like _radiumIsMounted
below.
If it is per component class, you can make it a static, like _isRadiumEnhanced
above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, confirmed a static _styleID doesn't solve #625
One issue with putting a styleID on each instance is that you'd end up with a ton of bloat and duplication in the stylesheet; consider rendering a grid with 100 cells, each one adding 2-3 media queries. |
True, that would be nasty. Maybe we can change the StyleKeeper's @media only screen and (min-width: 1024) {
.rmq-12345, .rmq-23456 {
display: none;
}
} I'll investigate! |
Does |
It would avoid stylesheet bloat, but might not fix usage with grid for example, where you had clashes within the same component, right? |
I tried a few approaches to reducing styleID's added bloat to the stylesheet without success. Using styleID increases the lines of CSS from 315 to 896 (~3x) in the It may be worth reconsidering media query precedence in the future, as I've noticed designers heavily rely on the cascading behavior of I honestly don't know which follows the principle of least surprise: the consistency of definition-order precedence everywhere, or the cascading behavior of media query ranges that designers expect. Thoughts? @ianobermiller @alexlande |
@tptee, the 3x will be fine after gzip, but having too many selectors will definitely slow things down eventually. We need a better solution, but I am fine with this until we figure one out. The increase is linear with respect to what? The number of components rendered? If you have a grid with 100 rows, do you get 100x the style sheet size? |
I'm going to kick the tires on a more robust solution, since I don't have a clear picture of the scale at which stylesheet bloat increases. I'll hopefully have something to report back soon! |
I think I have an optimization for removing stylesheet bloat that still guarantees rule uniqueness. I've got a brain dump below, and I'd love if you all could give this a feasibility check before I continue. It's the only optimization I could find that respects the order precedence test. /cc @ianobermiller @alexlande @coopy /*
Algorithm:
- Prepare an incoming media query + ruleset using addCSS().
- Look at the previous rules defined for the same media query (if present).
- Remove rules in the current set that are duplicates of the previous set.
- Write the deduplicated current set to the stylesheet.
- Apply the class names of both the previous and current set to the component.
*/
/* Existing query */
@media only screen and (max-width: 640px) {
.rmq-ffe912bc {
display: flex !important;
flex-basis: calc(50% - 8px) !important;
align-items: flex-start !important;
justify-content: flex-start !important;
order: initial !important;
}
}
/* Incoming query */
@media only screen and (max-width: 640px) {
.rmq-69620a79 {
display: flex !important;
flex-basis: 100% !important;
align-items: flex-start !important;
justify-content: flex-start !important;
order: initial !important;
}
}
/* duplicates: display, align-items, justify-content, order */
/* component <---- .rmq-ffe912bc .rmq-69620a79 */
/* deduped ruleset ------> stylesheet */
@media only screen and (max-width: 640px) {
.rmq-69620a79 {
flex-basis: 100% !important;
}
}
/* --------------------------------------------------------- */
/* Another incoming query */
@media only screen and (max-width: 640px) {
.rmq-b0a85267 {
display: flex !important;
flex-basis: 100% !important;
align-items: center !important;
justify-content: flex-end !important;
order: initial !important;
}
}
/* duplicates from first query: display */
/* duplicates from second query: flex-basis */
/* component <---- .rmq-ffe912bc .rmq-69620a79 .rmq-b0a85267 */
/* deduped ruleset ------> stylesheet */
@media only screen and (max-width: 640px) {
.rmq-b0a85267 {
align-items: center !important;
justify-content: flex-end !important;
}
} |
Sounds complicated, but I think it would work. |
Yep, sounds reasonable to me. |
Any recent update regarding this PR? Cheers. |
Closing this as it will not be prioritized and the branch has fallen stale |
Resolves #593 and #625.
@ianobermiller @alexlande can you give this a sanity check?