Theme-ui: Re-export keyframes from @emotion/core

[acal11]

Is your feature request related to a problem? Please describe.
It's not recommended to install @emotion/core separately since v0.3.0, however creating animations required the keyframes utility that it provides.

Describe the solution you'd like
Re-export keyframes as a theme-ui export.

Describe alternatives you've considered
N/A.

Additional context
Trying to build a loading animation.

[lachlanjc]

Because Theme UI includes @emotion/core internally, you should be able to still import & use keyframes like normal: https://github.com/system-ui/theme-ui/blob/9163f4818e46339fca9c53a9a43d8a3309c4e5db/packages/components/src/Spinner.js#L2

[Andre-InfoTrack]

Because Theme UI includes @emotion/core internally, you should be able to still import & use keyframes like normal:

https://github.com/system-ui/theme-ui/blob/9163f4818e46339fca9c53a9a43d8a3309c4e5db/packages/components/src/Spinner.js#L2

Ah true, eslint doesn’t like it which was throwing me off

[lachlanjc]

Seems like we should either export ourselves or note somewhere in the docs. @jxnblk?

[jxnblk]

@lachlanjc agreed! This would make an excellent addition to the docs

[0phoff]

Why not choose to re-export ?

IMO, it makes for a cleaner interface as it does not build on an "implementation detail" that you use emotion internally. What if you switch to another css-in-js package ?
By re-exporting it, you are free to do what you want internally in theme-ui.
You can switch packages, or even wrap the keyframes utility to add your own flair to it if you so like.

I know you probably won't switch packages and all, but doesn't this feel like code smell to you ?

At the end of the day, who am I to judge...
I am a mere mortal, building crappy software with these godly tools you gave me (Thanks by the way)!

[jxnblk]

I suggested docs first because re-exporting an API from another library also implies that we should provide duplicate documentation for that API and Theme UI doesn't do anything specific to change that API. An addition to the docs is needed regardless, and changing the package name in the import statement (later if we do export it) is a change that can be handled pretty quickly. I.e. it's not one or the other, but the docs piece is higher priority IMO