My main reason for adding this now is that I'm getting some scattered reports of things not displaying correctly, and I want to start gathering some browser data on that...
I recently confirmed that animations work on iOS (at least one did!), which was going to be my guess of what was breaking...
I took out virtualization for now too, I wanna see how this non-Chakra UI version, with fewer nodes and no tooltips etc, performs on large lists in production.
Looks like there was some kind of runtime conflict when running @emotion/css and @emotion/react at the same time in this app? Some styles would just get clobbered, making things look all weird.
Here, I've removed our @emotion/css dependency, and use the `<ClassNames>` utility element from `@emotion/react` instead. I'm not thrilled about the solution, but it seems okay for now...
...one other thing I tried was passing a `css` prop to Chakra elements, which seemed to work, but to clobber the element's own Emotion-based styles. I assumed that the Babel macro wouldn't help us, and wouldn't convert css props to className props for non-HTML elements... but I suppose I'm not sure!
Anyway, I don't love this syntax... but I'm happy for the site to be working again. I wonder if we can find something better.
Another longshot attempt to fix the prod-only emotion bug for free :p
This should be a very easy upgrade, bc I don't think we depend on the minor stuff that had breaking changes.
I'm naively hoping that this fixes the issue with Emotion/Chakra styles that only shows up on prod…
We've had an issue with prod-only bugs before, and it was due to a compiler bug re comments in JSX. I'm wondering if maybe one of our deps now has the same or a similar bug? and if maybe upgrading react-scripts will upgrade webpack, which might fix it?
It's a bit of a longshot, but it's a good upgrade to do anyway, so let's see if we get lucky!
Also, react-scripts 4 has Fast Refresh built in, so we can remove our overrides that added it!
The AMFPHP gateway's json.php endpoint has always had a problem parsing pets whose names start with digits… I've dug into it before, and checked again today, and there really is just no way around it: d584b58e95/core/json/app/Actions.php (L43)
And there aren't any reliable AMFPHP Node libraries out there to make the actual native AMF call.
Buuuut! In today's investigation, I noticed the xmlrpc.php endpoint for the first time. And, wouldn't you know it, there's //great// reliability for something as enterprise-standard as that!
So here, I've switched over to using an xmlrpc client library, which simplifies our calling code //and// makes number pets work correctly 😁 I wouldn't have done it just for the simplification, I think bringing in a library is net more complexity… but getting this finally right is a big relief.
Just gonna bulk load all those manifests into the db, and then that should make most loads notably faster by removing the net request! 🤞
We'll still load manifests inline sometimes, but only the first time anyone pulls up the layer in impress-2020. After that, it should be cached forever!
I had upgraded to a prerelease version of chakra-ui recently, and there was a bug that broke the "toast" message when you like, submit a bad pet name! It looked… very bad 😂
Now things look good again!!
Following this guide: https://dutzi.party/react-fast-refresh/
This enables code changes in dev to appear faster and preserve state, instead of reloading the page!
