-
-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
expand on embedded mode #155
base: main
Are you sure you want to change the base?
Conversation
commit: |
return ( | ||
<> | ||
<Component {...props} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this withDevTools method is kind of low-key deprecated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
deprecated
in favor of?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
if (!hydrated) return <Component /> | ||
|
||
if ((config?.panelMode ?? "auto") === "embedded") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why the default here? you don't really need to check if "auto" === "embedded"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mainly for clarity that the default mode is "auto"
. It's not technically necessary, happy to remove it if preferred.
@@ -0,0 +1,28 @@ | |||
# templates/unstable-vite | |||
|
|||
⚠️ Remix support for Vite is unstable and not recommended for production. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how old of a template did you use here? 🤣
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just a copy of test-apps/remix-vite
😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh boy thats embarrassing 😳
if ((config?.panelMode ?? "auto") === "embedded") { | ||
return ( | ||
<RDTEmbeddedContextProvider> | ||
<Component /> | ||
</RDTEmbeddedContextProvider> | ||
) | ||
} | ||
|
||
return ( | ||
<> | ||
<Component {...props} /> | ||
{createPortal(<RemixDevTools {...config} />, document.body)} | ||
</> | ||
) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Primarily because you really want React Context to be granular. One thing I was going to suggest to you was to separate the dispatch
context out from the state
context.
Having them both in the same context is inefficient, because every useContext()
call subscribes the component to rerenders whenever the context value changes. That means that components that only need the dispatch
will have to re-render whenever the state
changes, even if they never read any state
. By breaking those up into separate contexts, you get granular control of what causes a re-render. And since dispatch
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 invoking dispatch
!).
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 by RDTContextProvider
changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, makes sense, okay
WIP
Mainly opening this PR for feedback about the approach