Bugzilla

Tah(In reply to Chris Vander Linden from comment #7)
> I’m jumping back into Bug 1941575 now that I’m between semesters and wanted to share a simple phased plan to make sure I understand how to approach this.
> 
> **Phase 1 - Decouple SearchInput from Debugger Redux:**
> • Today SearchInput is Redux-connected (reads getSearchOptions and dispatches setSearchOptions).
> • I’ll refactor it so SearchInput becomes a “dumb” UI: it receives searchOptions (and a setter/callback) via props instead of importing selectors/actions directly.
> • SearchInFileBar (Debugger side) will supply those props (so all Debugger selectors/actions stay in the container/wrapper layer, not inside the shared UI component).
> 
> **Phase 2 - Move SearchInput to shared:**
> Once it’s unconnected, move SearchInput to devtools/client/shared/components/ (or the location you prefer), and keep Debugger working by updating imports (or leaving a thin shim at the old path if needed to avoid large churn).
> 
> **Phase 3 - Decouple and share SearchInFileBar:**
> Next, apply the same pattern to SearchInFileBar: remove Debugger-specific selectors/actions from the component itself and have those injected via props.
> 
> My question is where should the Redux wiring live?  Should there be a Debugger-only wrapper (connected) that renders a shared/dumb SearchInFileBar? That keeps the large Debugger Editor component clean (it would keep rendering a “SearchInFileBar” component and pass editor, but the wrapper would provide the Debugger-specific props).  Or, should the props be passed in the Debugger Editor component?

Yeah that  sounds like a good plan.


Thanks for your breakdown here, sounds like a good plan. This particular bug is for implementing the shared Search Component in the netmonitor.

I've filed other bugs for moving the SearchInput Component (Bug 2019256) and the SearchInFileBar Component from the debugger to the shared folder.

Tah(In reply to Chris Vander Linden from comment #7)
> I’m jumping back into Bug 1941575 now that I’m between semesters and wanted to share a simple phased plan to make sure I understand how to approach this.
> 
> **Phase 1 - Decouple SearchInput from Debugger Redux:**
> • Today SearchInput is Redux-connected (reads getSearchOptions and dispatches setSearchOptions).
> • I’ll refactor it so SearchInput becomes a “dumb” UI: it receives searchOptions (and a setter/callback) via props instead of importing selectors/actions directly.
> • SearchInFileBar (Debugger side) will supply those props (so all Debugger selectors/actions stay in the container/wrapper layer, not inside the shared UI component).
> 
> **Phase 2 - Move SearchInput to shared:**
> Once it’s unconnected, move SearchInput to devtools/client/shared/components/ (or the location you prefer), and keep Debugger working by updating imports (or leaving a thin shim at the old path if needed to avoid large churn).
> 
> **Phase 3 - Decouple and share SearchInFileBar:**
> Next, apply the same pattern to SearchInFileBar: remove Debugger-specific selectors/actions from the component itself and have those injected via props.
> 
> My question is where should the Redux wiring live?  Should there be a Debugger-only wrapper (connected) that renders a shared/dumb SearchInFileBar? That keeps the large Debugger Editor component clean (it would keep rendering a “SearchInFileBar” component and pass editor, but the wrapper would provide the Debugger-specific props).  Or, should the props be passed in the Debugger Editor component?

Yeah that  sounds like a good plan.


Thanks for your breakdown here, sounds like a good plan. This particular bug is for implementing the shared Search Component in the netmonitor.

I've filed other bugs for moving the SearchInput Component (Bug 2019256) and the SearchInFileBar Component (Bug 2019260) from the debugger to the shared folder.