not spreading the props over the component actually breaks RR7 support, I learned it the hard way yesterday with line 27 above breaking my rr7 test setup. So props need to be accepted and spread across Component in every return case

Also, this withDevTools method is kind of low-key deprecated

deprecated

in favor of?

WithViteDevTools, this one is undocumented relic used to manually set it up if needed in remix v1, I plan to remove it fully in next major

why the default here? you don't really need to check if "auto" === "embedded"

Mainly for clarity that the default mode is"auto". It's not technically necessary, happy to remove it if preferred.

how old of a template did you use here? 🤣

It's just a copy oftest-apps/remix-vite 😅

Oh boy thats embarrassing 😳

I've been thinking,RDTContextProvider wraps both the EmbeddedDevTools and the regular ones, why wouldn't you just pop this panelMode option into that and here just not use the createPortal? instead of having 2 contexts?

Then you in the vite plugin set it to embedded, that hides this createPortal, and wherever you use you just pass in a prop that the panel is embedded (inside the EmbeddedDevTools to the context) and you get this behavior with less hassle and there is 1 context to read from

Primarily because you really want React Context to be granular. One thing I was going to suggest to you was to separate thedispatch context out from thestate context.

Having them both in the same context is inefficient, because everyuseContext() call subscribes the component to rerenders whenever the context value changes. That means that components that only need thedispatch will have to re-render whenever thestate changes, even if they never read anystate. By breaking those up into separate contexts, you get granular control of what causes a re-render. And sincedispatch is stable, components that only need to dispatch won't re-render themselves after the state changes (often times in response to those components themselves invokingdispatch!).

With that in mind, having a separate context for "embedded" mode makes sense, since the value of this is essentially static, a component that needs to render differently based on embedded-mode or not won't need to re-render whenever the state managed byRDTContextProvider changes.

I see, makes sense, okay