5,472,597 events, 1,062,302 push events, 1,623,226 commit messages, 117,926,726 characters
Reduce unmounts when hiding DevTool panes
This started as an investigation into https://github.com/RecordReplay/devtools/issues/3851. Toggling the visibility of the Editor was triggering an unmount and remount of basically every component in the DevView. DevView had 4 different branches, each with slightly different rendering trees, based on which components (editor, video, both, neither) were open. This was a lot of complexity and it actually didn't capture all of the options (because the user can also toggle whether or not the sidebar was open).
I cleaned it up by simplifying that render tree so that it's always the
same child components inside of the SplitBox. There is still one place
where changing a view causes an unmount and remount which is inside of
Viewer. This is because in the vertical view the video is the
startComponent (because vertical SplitBoxes flow top-to-bottom), but
in the horizontal view the video is supposed to be the endComponent
(because horizontal SplitBoxes flow left-to-right). I thought I would be
clever and just add flex-direction: row-reverse in the horizontal case
but that caused a really horrible UI bug where trying to slide the
component to make it bigger actually made it smaller and vice versa. I
was far enough down the rabbit-hole by this point that I didn't want to
spend any more time going that route.
This change also addresses
https://github.com/RecordReplay/devtools/issues/3746. It looks like
previously viewer mode stored a panel split size in
nonDevSidePanelWidth, but the function that sets that was no longer
called, so I've removed that setting. Instead, both places where
SidePanel is rendered now pull from and write to the setting
sidePanelSize, in the new prefs file. This means that when you
navigate between DevTools and Viewer mode the width of the side panel
will remain the same.
I cannot tell if this is fully intended, but it works quite well in my testing. Consider the following case, where the container is a SplitBox flowing left-to-right, with component A being the controlled component (which means component B has flex-grow on it and will take up whatever space A leaves open):
Let's also say that component A might not be visible right now, in which case we want component B to take up its space, ignoring the partition. Rather than doing this:
if (!componentA) {
return componentB;
} else {
return <SplitBox left={componentA} right={componentB}/>
}
You can do something like this:
return <SplitBox left={componentA} right={componentB} maxWidth={componentA ? "auto" : "0px"}/>
This says "give me a SplitBox that contains these two components, but if
this one doesn't exist, then make sure it doesn't take up any space".
Without code like this, it's actually pretty difficult to avoid having
many different if checks in the render statements or having accidental
gaps in the UI where the SplitBox is making room for an element that
doesn't exist.
This gives us the following:
CleanShot.2021-10-04.at.17.15.53.mp4
I think this is in a pretty nice state for the user interface, but I don't love how it feels to code UI's like this with the nested SplitBoxes. I think a future we should move towards, particularly for layouts like DevTools, is a CSS grid, where the drag events just change the CSS, rather than the react state, and things can be moved from panel to panel by just changing their grid number. That's a much larger undertaking.
Rebekah Beta 2.0
Lunchbox Miraculous Womb Cursed Spoon Dice of Fate Isaac's Locks Eternal Bond Love = Power Candy Wedding Ring Love me, love me not Doorstopper Typical Rom-com Finger Finger! Love Deluxe Moriah Diary Great Phoenix
Added two secrets
fuck you discord rpc
no discord rpc here in this house
added some usefull shit. hope you are will throw after this motherfucking bullshit
Remove honeycomb. I don't know how to use it and it's expensive with my traffic.
Resources from the honeycomb folks in slack:
Kent C. Dodds Today at 12:51 PM Hi friends 👋 I added honeycomb to my node.js site and now that it's launched and gets over 50k page views a day I'm going way over my limit. Thing is that I don't know how to make use of honeycomb. I pretty much just want to be notified whenever there are unusual things going on (lots of 404s, long response times, etc). I've got the basic telemetry stuff set up. The dashboard seems like it's only usable by someone who knows what they're doing and that's definitely not me. Anyone got tips? 8 replies
Levi Wilson 10 minutes ago if you're going way over your limit, you may want to look into setting up a refinery server so you can do trace-level sampling to rule out "uninteresting" traces
Levi Wilson 10 minutes ago and start with setting up specific "interesting" requests you'd like to see
Levi Wilson 9 minutes ago https://docs.honeycomb.io/manage-data-volume/refinery/sampling-methods/#rule-based-sampling Rules Based Sampling is what we use and it works quite well docs.honeycomb.iodocs.honeycomb.io Supported Sampling Methods | Honeycomb How sampling decisions are made
Levi Wilson 8 minutes ago re: the dashboard, you might want to go into your schema definitions to define things like what it means for a "route" so the home screen will be more useful (as well as "errors", "users", etc.)
Kent C. Dodds 8 minutes ago Cool, thanks for the resources and ideas 🙂 (edited)
Ryan Brown 7 minutes ago +1 for rule sampling
Levi Wilson 5 minutes ago one concern you might have, however, with refinery is if you've that much traffic...adequately sizing it will be important
Levi Wilson 4 minutes ago https://docs.honeycomb.io/manage-data-volume/refinery/scale-and-troubleshoot/ has deets on that docs.honeycomb.iodocs.honeycomb.io Scale and Troubleshoot | Honeycomb Scaling and troubleshooting a Refinery cluster
arp: Do not fill cache from random packets.
On paper this looks great, and in a sane network it should work. However the world out there is full of horribly broken, screwed up networks, which of course ruin this.
I've seen a customer's network where the router is IP 192.168.1.1, MAC addr xx:03. However, every 1 minute the router broadcasts some "mikrotik discovery" UDP garbage with source IP 192.168.1.1, source MAC addr xx:02 (one less!). This accidentally poisons smoltcp's ARP cache, which then sends all traffic for the default gateway to xx:02, which unsurprisingly blackholes it.
And, of course, the broadcast is every 1min and the ARP cache lifetime is 1min. This means the cache is almsot all the time poisoned, and the smoltcp device barely works. Fantastic.
Screw you mikrotik.