More phenogrid features, scrollbar changes

[vincerubinetti]

Closes #363

• allow all non-mocked requests to pass through msw. the list of exceptions was just getting to be too long and too hard to predict (e.g. hard to know what format vite will compile assets into in which contexts). the penalty will be once in a while a live api will be hit during mocked testing; probably will only happen when adding new endpoints.
• replace sem sim compare fixture data with bigger example (for stress testing phenogrid)
• update sem sim compare api func to derive some additional data, like totaling up the scores for each col and row
• rearrange css z-indices
• get rid of big arrows in table scroll
• force scrollbars to be visible on macos chrome and safari (not firefox, not ios). more discussion on this below. add ability to add little dark shadow on scrollable elements. previously was just using an alpha mask, so it would just fade into the background, so sometimes you'd miss it if the gradient landed in-between elements. being a gray gradient will make it always visible on light/dark bgs.
• phenogrid component: add scrolling, sticky col/row headers, info popup, download image
• add util funcs to support the above

Discussions:

Maybe someone can provide me here with some content to put in the info tooltip per #362

I added a sorting method where the rows/cols get sorted based on the sum of their cells' scores. I'm not sure if this is useful, but it kind a seems like it to me because it basically puts the darker (higher score) cells closer to the top left corner. Does anyone know what's involved with doing the freq/rarity sorting and different calc methods here:

We can do phenogrid in two ways: HTML (table) or SVG, each with pros and cons:

• A table is automatically (fairly) accessible, svg takes more work to make nicely accessible.
• A table is harder and much to download as an image (taking a screenshot of the dom is brittle and prone to mysterious cross-browser/device errors, e.g. safari just fails to download when the grid has too many elements), with svg all you do is download the source as a text file.
• A table requires setting background colors on several elements to make the "stick" col/row headers work (i.e. the top row has to have a white bg so when you scroll up and the cells go under it, they don't pop through), an svg has clip paths and masks that can "cut out" part of a shape without needing a background color, keeping things transparent (good for image export, and doesn't necessitate changing all the bg colors if you're using the widget on a site with a dark bg for example).
• A table allows for "sticky" col/row headers more smoothly and easily with CSS, with svg this would necessitate javascript (syncing the scroll position of the container to the position of the clip paths and other svg elements) and result in some lag.
• An svg should theoretically be more performant than a table and better able to handle larger grids. A table uses more elements per cell (e.g. a tbody wraps a tr wraps a td wraps a colored button, vs. a single svg colored rect element at a coordinate) and uses a more complex layout algorithm (i.e. in a table all cells can affect the sizing of other cells, vs. in an svg an element is just drawn at a coordinate with some transforms).

Regarding scrollbars. I didn't like the bulky arrows with the animations on the tables. Looks clunky, but more importantly, it's not "simple". Have to add new dom elements and restructure your component hierarchy to accommodate this. Instead, I added a utility class that adds a shadow that can simply be slapped on any element without changing anything else, however it can only work in one direction at a time (e.g., couldn't have a horizontal and vertical scrolling together), but I think that's an okay limitation. Also, I've added a utility class to force the scrollbar to always be visible, but it still won't work on macos firefox or ios. This is because apple has forced a design standard on ios where the scrollbar hides unless you are actively scrolling (I guess to make it look more slick and/or save screen space), and firefox has taken it further and completely ignores attempts to force scrollbar visibility on any platform (and instead just respect whatever the OS tells it to do). You can change this behavior in your OS settings, and we can recommend users do it, but there is no (good) way to us to force it. There are libraries like Perfect Scrollbar that can force scrollbars on any platform, but they are not good to use imo: they require adding new DOM elements to draw the scrollbar (despite them often claiming they don't affect the dom), and they basically (poorly) replicate the browser's native scrolling behavior with javascript. Sounds easy, but there are more things to account for than you'd think (speed, acceleration, snapping, wheel vs touch vs trackpad vs keyboard control, etc.), and if you check out Perfect Scrollbar for example, you can notice their website's scrolling feels a bit off from native behavior. All of this is to say, the solutions I've implemented here are as far as I'm willing to go. We should leave it here, with CSS properties and some basic shadows. If we still get these common complaints about scrollbars not being visible, e.g. in ios, we will have to just say it's the browser's/OS's fault for enforcing this bad design decision on us. This is the approach stackoverflow seems to take, for example, with its scrollbars in big code blocks. You will see they disappear on firefox. Going further is just too brittle and not within our scope to fix.

[netlify]

✅ Deploy Preview for monarch-app ready!

Name	Link
🔨 Latest commit	727e6a4
🔍 Latest deploy log	https://app.netlify.com/sites/monarch-app/deploys/651ef2706ca2c00008e9968a
😎 Deploy Preview	https://deploy-preview-372--monarch-app.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[glass-ships]

looks alright to me!