-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add insertionPoint
option in EmotionCache
#2521
Add insertionPoint
option in EmotionCache
#2521
Conversation
🦋 Changeset detectedLatest commit: 61fcc7f The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 61fcc7f:
|
Codecov Report
|
@@ -37,6 +37,7 @@ export interface Options { | |||
container?: HTMLElement | |||
speedy?: boolean | |||
prepend?: boolean |
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.
prepend?: boolean | |
/** @deprecate use `insertionPoint` instead */ | |
prepend?: boolean |
a note about this deprecation should both go into the docs and into the changeset
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.
I would keep the prepend
option, it is much simplified version for that use-case (adding the style rules first in the head). Otherwise you would need to create a node and add it first in the head, just so that you can say, add the style rules after this element.
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.
Btw I am adding the style rules after the node specified in the insertionPoint
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.
I would keep the prepend option, it is much simplified version for that use-case (adding the style rules first in the head). Otherwise you would need to create a node and add it first in the head, just so that you can say, add the style rules after this element.
I was thinking about this in the last few days and I think I would still prefer to deprecate the prepend
. This would align more with Emotion's overall philosophy (minimal API surface, only a few options, not using conflicting options etc). While achieving prepend
with insertionPoint
is a little bit more involved it can still be done. I expect that not that many people need any of those options anyway (both didn't exist in Emotion 10) and this has to be usually only done once in the application.
Removing this option would simplify the code (the cost ain't high here though), but importantly it would simplify the docs, teachability and would allow us to drop conflicting options in the future (insertionPoint
used together with prepend
doesn't make any sense).
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.
Updated
packages/sheet/README.md
Outdated
@@ -51,6 +51,10 @@ This defines how rules are inserted. If it is true, rules will be inserted with | |||
|
|||
This defines where rules are inserted into the `container`. By default they are appended but this can be changed by using `prepend: true` option. | |||
|
|||
#### insertionPoint | |||
|
|||
This defines specific dom node after which the rules are inserted into the `container`. |
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.
It might not always be obvious which element one should choose as their insertionPoint
. Even if a correct element gets chosen the relation between this element and it being insertion point might not be obvious.
To make things easier for people and to alleviate the indirect relationship problem we could suggest here using smth like this as the insertion point:
<meta name="emotion-insertion-point" content="" />
This technique (using custom <meta/>
) is used by next/head
.
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.
Updated with a codesnippet
Co-authored-by: Mateusz Burzyński <mateuszburzynski@gmail.com>
// <meta name="emotion-insertion-point" content=""> | ||
const emotionInsertionPoint = document.createElement('meta') | ||
emotionInsertionPoint.setAttribute('name', 'emotion-insertion-point') | ||
emotionInsertionPoint.setAttribute('content', '') |
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.
FYI: I've checked the spec and it seems that content
attribute is required in this case:
If either name, http-equiv, or itemprop is specified, then the content attribute must also be specified. Otherwise, it must be omitted.
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.
Kindly, does this work with SSR, 'cause document
seems to be undefined in my case? What do you suggest I do?
Thanks.
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.
You need to create such a tag (or similar) in your SSR response and then select it on the client's side and pass it as the insertionPoint
to createCache
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.
Hi, @Andarist. Thanks for your response. I saw and did as you suggested and it worked. Thank you.
But then, there's another issue which I'm noticing. I'm using Framer Motion's page transition feature--AnimatePresence--with MUI, and it happens that on route change start, the styles of the unmounting page/component (seem) to get removed from the DOM causing a FOUC of the unmounting page (before it transitions out).
Is there a way to preserve the styles of the pages as they get mounted, so they don't have to get removed and re-added everytime they get mounted/unmounted. I hope you understand what I mean?
Cc: @oliverturner
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.
What styles are removed on the route change? By default Emotion doesn't unmount any styles - except global ones when used through <Global/>
. Framer Motion also works in a way that it temporarily preserve components that are unmounted in the tree (they just render exiting children for longer than you are rendering them - they can do that cause they just cache previously received children). So even if some styles would get unmounted during the process they should be unmounted after the component goes completely out of the page so there should be no FOUC.
So while I understand what you are observing there, I don't understand how this can happen. Do you have a repro case (even a complex one, like a full deployed page) that I could take a look at?
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.
...versus what it currently looks like in prod:
prod-480x.mov
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.
@Andarist , so you'll notice the FOUC in the production (build) video.
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.
Hi, @Andarist . Seen these yet?
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.
Could you perhaps record this with https://www.replay.io/ ? I'd like to debug this and can't do that with just a standard recording of the problem.
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.
Alright, I will. Thanks for your support. 🤲🏼
Thank you! ❤️ |
What:
Fixes #2037 (it is closed, but the feature request haven't been implemented before).
It adds an option to the
EmotionCache
for specifying an insertion point - dom node after which the style rules will be inserted.Why:
It is necessary feature for applications that have third-party styles coming from one place, which should be injected first, then the app's styles coming from emotion, for example, coming from a UI library (as @mui/material) that needs to be injected next, and then any other overrides for the default styles.
How:
It's pretty much self explanatory, the style rules are being injected after the specified node. This option wins over
prepend
, if both are being specified, as I would say is more specific.Checklist: