Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 inEmotionCache
#2521Add
insertionPoint
option inEmotionCache
#2521Changes from all commits
84cf0a4
a8a38cc
5e801e0
221c298
60bf5bd
b13a72c
3fc9c88
c8fa22d
1c94b62
74ab823
218ea87
ef3412f
61fcc7f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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: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
tocreateCache
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. 🤲🏼
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.
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 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 achievingprepend
withinsertionPoint
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 withprepend
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