Reference generated classnames

[maxburs]

Is there any way to reference a generated class name in a different makeStyles call or the same one?

For example, if I was to try and convert a css module file that looks like this, how would I do it?

/* Same file class references. I'd expect this to generate 3 unique classes. */
.element1 { }
.element2 { }

.open.element1 { }
.open.element2 { }

/* Different file class references (https://github.com/css-modules/css-modules#composing-from-other-files) */
.button {
  color: white;
}

.button {
  composes darkMode from '../pageStyles.css';
  color: black;
}

I found this reference to "nested selectors" in the docs, but it uses global names for the child selectors.

import { makeStyles } from '@griffel/react';

const useClasses = makeStyles({
  root: {
    '& .foo': { color: 'green' },
    '&.bar': { color: 'red' },
  },
});

[maxburs]

More context:

My team is looking to update to Fluent 9. We've got a lot of Sass we're looking to replacing with Griffel. A common pattern we use is to create status (open/closed, light/dark, loading) classes on a components root element, and then use nested selectors to style elements.

[maxburs]

A few more examples of things we're using this pattern for right now:

open/closed

Hide/show and animate items in a panel based on if it's open

&:hover

Apply styles to child elements based on if a parent is in a hover state

Layout

Apply styles based on if another element is present or not. For example, we may want to change the padding or location of a button based on what's adjacent to it.

[maxburs]

I would like to understand a bit more about your patterns to see how we can help there. However, our suggestion (I am slowly working to get it in a written form) is to use base styles and merges for permutations.

I think what I'm trying to do is avoid status permutations for every child element. Selectors allow me to apply the status permutation to a single element, and then re-use that permutation/status everywhere. Updating the classes for every element would be possible, but, would also make things a lot more verbose, inefficient (I think?), and would make translating some of these existing styles more involved, because we'd have to start communicating this state through js.

[maxburs]

usage of nested selectors is not what we recommend to do.

This means that any selectors we currently have that use combinators (1) would have to be replaced with a new class repressing that state?

(1) https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors#combinators

For example, if we're using the sibling selector (.class1 + .class2), we'd instead create a new class to represent this state, and apply it conditionally using mergeClasses?

[layershifter]

@layershifter Here's a more concrete example.

Thank you for providing detailed examples and use cases 👍

This allows us to update the layouts of all child elements by updating the class on the root element, rather than passing down the root element size and re-running all of the React components.

To be clear, we recommend to avoid nested selectors, but there are exclusions and valid usages. I think for the case that you mentioned it's better (more efficiently) to use nested selectors.

However, we don't have a special API to generate these/use these classes. Let me provide some details on this:

// ComponentA.styles.ts
makeStyles({
  root: { color: 'red' }
})
// ComponentB.styles.ts
makeStyles({
  root: { color: 'red' }
})

Both these calls will generate the same classes to be reused (https://griffel.js.org/react/guides/atomic-css) so will produce less unique classes. The problem is that it's unclear what do in this case:

// ⚠️ NOT A REAL API

// ComponentA.styles.ts
makeStyles({
  root: { color: 'red' },
  child: { "<root>": { color: 'red' } }
})
// ComponentB.styles.ts
makeStyles({
  root: { color: 'red' },
  child: { "<root>": { color: 'red' } }
})

• Are styles in ComponentA.styles.ts & ComponentB.styles.ts still the same?
• What to use in real CSS instead of <root>? (makeStyles can return multiple classes for root)

I was thinking about something like that:

// ⚠️ NOT A REAL API

const rootClassName = makeClassName()

makeStyles({
  root: { className: rootClassName, color: 'red' },
  child: { `.${rootClassName}`: { color: 'red' } }
})

• Why? With static classes you need to care about possible collisions, keep them meaningful, etc.

However, the issue similar to scoped CSS variables (microsoft/fluentui#17923) and runtime params (#90 (comment)): we have runtime (zero setup) version and I personally don't know a way to make it deterministically and avoid collisions on a client, SSR & build time. That's why in Fluent UI itself we use static classes.

---

Now for additional cases:

• "open/closed": in this case I suggest to avoid nested selectors, this could be done with mergeClasses
• &:hover: in this case please use nested selectors, but keep them simple
• "Layout": I would say: up to you, I would try to avoid nested selectors there

---

I think what I'm trying to do is avoid status permutations for every child element. Selectors allow me to apply the status permutation to a single element, and then re-use that permutation/status everywhere. Updating the classes for every element would be possible, but, would also make things a lot more verbose, inefficient (I think?), and would make translating some of these existing styles more involved, because we'd have to start communicating this state through js.

It depends on how features are implemented:

• If you do a re-render of components anyway: don't use nested selectors, use mergeClasses
• If you don't do a re-render for performance reasons: take the best decision

For example, if we're using the sibling selector (.class1 + .class2), we'd instead create a new class to represent this state, and apply it conditionally using mergeClasses?

Yes, it's our general suggestion as it allows to avoid this problem.

// One class for each element, high change for classes to be reused
makeStyles({
  root: { color: 'red' },
  child: { backgroundColor: 'green' }
})

// Two classes on `root` element`, `.f2yt26o .child` will be likely never reused
makeStyles({
  root: {
     color: 'red',
     '& .child': { backgroundColor: 'green' }
  },
})

[maxburs]

Thanks for the detailed response.

To be clear, we recommend to avoid nested selectors, but there are exclusions and valid usages. I think for the case that you mentioned it's better (more efficiently) to use nested selectors.

This matches how we're using it right now. Most places don't need tools this powerful, but we've got a few places that it's really useful.

I was thinking about something like that:

// ⚠️ NOT A REAL API

const rootClassName = makeClassName()

makeStyles({
  root: { className: rootClassName, color: 'red' },
  child: { `.${rootClassName}`: { color: 'red' } }
})

• Why? With static classes you need to care about possible collisions, keep them meaningful, etc.

However, the issue similar to scoped CSS variables (microsoft/fluentui#17923) and runtime params (#90 (comment)): we have runtime (zero setup) version and I personally don't know a way to make it deterministically and avoid collisions on a client, SSR & build time. That's why in Fluent UI itself we use static classes.

An api to do something like this would be great.

This would be useful for more than class names too. For example, container queries (1) can be named, it would be nice if we could make these names unique.

(1) https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries

[AkimaLunar]

Hey 👋 Has there been any updates to this feature idea (.${rootClassName})? I am not seeing anything in the docs, but I thought I might check.

[layershifter]

@AkimaLunar so far, we don't have any progress on it.