Skip to content

Class merging behaviour different for default and custom emotion instanceΒ #3227

Open
@BaggioWongHK

Description

Description: Before pointing to any documentation improvements, I'm actually not sure whether this is intended behaviour that's not mentioned in the docs (maybe it's obvious to most users), or it's unintended behaviour. So I'd like to clarify first.

When investigating an issue, I noticed that the way emotion handles merging classes defined in cx as per what's described #817 is different when importing from @emotion/css (or the older emotion), and when defined in cx from a custom emotion instance.

I've reproduced it here: https://stackblitz.com/edit/vitejs-vite-t1zwhc?file=src%2Femotion-default.ts

As we can we see, if the classes aren't merged, then styles are once again susceptible to evaluation via their order in the document - style tags in this instance.

image image

Would it be possible to clarify

  1. Is this divergence (i.e. whether classes are merged or not) intended?
  2. If so, what is the rationale behind this?

I think this would be helpful to note in the docs, because per the docs, this behaviour would not be consistent with

Subsequent styles overwrite property values of previous styles.

as seen with the above example.

Documentation links:

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions