DebugPanel should only be concerned with positioning / anchoring / hotkeys, not styling monitors.

[iktl]

Currently, DebugPanel passes several styles down to the Monitor in use as an artifact of the original demo put together by @gaearon. Since new Monitors are being actively developed, and I believe we should be encouraging a consistent approach to syntax like:

<DebugPanel top right bottom>
   <DevTools store={store} monitor={LogMonitor} />
</DebugPanel>

...where LogMonitor is subbed out by the developer for their preferred Monitor.

To this effect, I suggest that DebugPanel be re-tooled to be concerned only with it's positioning on screen and anchoring (it's current properties remain intact, and also hotkeys for enabling / disabling visibility.

This frees Monitors up to be singularly focused on their own appearance and behaviours within the DebugPanel, and keeps the general DX with DevTools consistent irrespective of the Monitor being used. Diff-Monitor is guilty of re-implementing some of these as we didn't want to write overrides to the DebugPanel styles coming down, so I would be the first to jump onboard with a PR if this suggestion seems valid.

[gaearon]

Let's do this!

[sergey-lapin]

Should every monitor decide for itself where it should be? Maybe it is redux-devtools concern? Otherwise there might be styles conflicts.

[iktl]

Alright, I'll work up a PR tonight removing the styling from DebugPanel and updating the LogMonitor included in the core sample so everything remains consistent.

[iktl]

@Lapanoid That's essentially what I think we should try to avoid. If we can encourage DebugPanel to be the standard wrapper for a Monitor, it will centralize a lot of the issues that might come up down the line when people want to switch Monitors arbitrarily.

[sergey-lapin]

@iktl DebugPanel is actually a good thing as it keeps monitors from being wherever they want to be, so it actually prevents a lot of style issues that might be. Monitors should be ignorant on their positon and size I think, so user could use them just as usual react component that can be styled. But if react-devtools will not make any decision on their appearence it will be like lego or zoo (somebody like it). Any ide have some rules that applied to all plugins and restrains them. So I think we need DebugPanel, but just better.

[iktl]

Oh I absolutely agree, I just don't think that DebugPanel should be telling the monitor inside it what to look like. It's just slightly over-zealous with its CSS right now.

[sergey-lapin]

Why you don't like it? Monitors are tools that should be controlled from elsewhere don't you think? We can rewrite DebugPanel to be more convinient for future monitors.

[philholden]

I am finding for the debug panel that it is often in the way of app since it covers links I need to press. I would find it helpful if it squashed the page content like chrome dev tools. Doing this probably requires an iframe for the main page or having redux dev tools as a panel in a chrome dev tools extension.

The problem with Chrome dev tools is that it is hard to add custom monitors.

Not sure iframe is what I want all the time but it would be helpful if this is an option. Could perhaps be done as a url query string similar to persistent debug mode. It is also handy if the dev tools can be dragged to be resized as the test monitor is not readable unless it is given enough space.

I really like the way Blender handles toolbars, panels and workspaces. It allows you to drag corners to split and join panes horizontally and vertically. Any pane can then be assigned to be any purpose via a drop down. I wish Sublime, Atom, Gimp and Inkscape had this.

[gaearon]

I am finding for the debug panel that it is often in the way of app since it covers links I need to press.

Just to clarify, you know that you can move it, right? Not that it's very convenient but just in case you didn't notice it has top, left, bottom, right props to control where it docks.

[gaearon]

Another note is you don't need to use DebugPanel at all. You can put DevTools right into your app.

[philholden]

Yes I have used these. I tend to be working on editors that are a bit like photoshop or an IDE and so they already have menus on the top, panels on the sides and zoom and other things on the bottom. There is more functionality than there is space to put it in.

I guess at times it would be nice to run redux dev tools on a second screen in another browser window with all communication happening via message passing. This may also be very handy for native apps as there is even less space on an iPhone.

[sergey-lapin]

@philholden I encountered problems with using iframes with https://github.com/lapanoid/redux-devtools-monitor-dock. Despite that ifraime is the only way I know how encupsulate css it is kinda hard to pass css. Composition of monitors broken as user should also pass path to css file. There are no such problems with inline styles Radium aproach. And I actually can read css to string and pass it as inline style but there also can be fonts.. I don't have any solution on this yet, it would be great to recomend to all devs not to use css at all.

[sergey-lapin]

I guess monitors is not such big problem as user apps. For example https://github.com/tastejs/todomvc-app-css apply styles on body, and use fonts. So I tried to bundle user app with iframe and use it as plain react component so it would not be hovered by monitors as it actually happens now (they are just display:fixed) but I stucked with fonts as I write previously.

[philholden]

@Lapanoid yes I am using Radium for style and quite liking it. Main downside so far is it makes components stateful so stops me doing shouldComponentUpdate() {return false} on my table rows that need hovers. I think its a good fit for dev tools is it allows them to be rendered in any context: Chome DevTools, Atom editor another window. I have never felt the need to change the CSS for Chrome's dev tools.

The thing that needs to go in the iframe is the app not the devtools. The app needs to be able to do what it likes with the body element and window.innerWidth without thinking about devtools. As soon as you say the app needs make room for the devtools you need to force a style convention on the app.

I'd love devtools where you could get the exact layout you wanted for a given app with each tool getting the space it needed.

Blenders layout manager works like this:

• drag corners horizontally to add a column
• drag corners vertically to add a row
• drag corner onto adjoining cell to merge cells
• drag borders to resize
• use dropdown to select monitor from list of available

https://www.youtube.com/watch?v=fZF48g-AJyA&t=0m55s

[sergey-lapin]

The app needs to be able to do what it likes with the body element and window.innerWidth without thinking about devtools. As soon as you say the app needs make room for the devtools you need to force a style convention on the app.

True. Because of it I thing we need iframe because user apps can not be restricted on anything but I still don't know the right way to bundle arbitrary web app into it.

Your markup is basically what I want too.

[philholden]

What happens if you set the src on the iframe to the normal index.html:

<devtools>
  <row><iframe src="/" /></row>
  <row>
    <col>
      <monitor></monitor>
    </col>
    <col>
      <monitor></monitor>
    </col>
  </row>
<devtools>

I think WebPack can be used to give you and entry point that does this. Webpackdevserver does something like this where it puts your app in an iframe and adds a bit of status above if you visit a special url e.g.

http://localhost:9090/webpack-dev-server/

See last three lines here:

http://webpack.github.io/docs/webpack-dev-server.html

I think the first challenge is getting the dev tools working in their own window and connecting to the app running in another window. From there getting the iframe working should be a case of just absolutely positioning it in the right gap.

[sergey-lapin]

@philholden Thanks for the hint! webpack-dev-server really good place to look for how to solve this. I think separate window is good for users but bad for devs as configuration of this should be more complex(we need solid bridge for this at least). It is pretty cheap to experiment with redux and monitors with hot reloading and it is simple because monitors and app runs on same page.

[philholden]

I have been thinking a bit more about implementing a Blender pane split style layout manager in React as I think it is an abstraction that has loads of use cases outside of devtools e.g. dashboards, text editors, image editors etc.

When I first ran persistent mode in Redux Dev Tools one of the things I wanted to do was run several instances of an app in the same browser side-by-side in different states.

I am thinking in multiuser applications you might want a layout that has remote monitors for all six connected clients. You could then see how an action in one client propagates to all the others.

Imagine if monitors could be exposed as html pages and stores knew how to communicate their state and actions to them via the server or inter iframe communication. DevTools could then just be a collection of iframes. You could create you own IDE for every product.

The same approach could be used to rapidly develop the product itself out of very loosely coupled parts.

I have very little time at home but might ask at work if I could get some time to look at a pane splitter.

[sergey-lapin]

@philholden If you interested I can add you as collaborator https://github.com/lapanoid/redux-devtools-monitor-dock. I think that simple radio interface is just a first step. If this can be done with iframes successfully we can introduce panes as well. I will look on webpack-dev-server approach in the near future and try to adapt it.

[philholden]

@Lapanoid I am getting there with my pane splitter hope to have something to demo very soon.

[sergey-lapin]

@philholden great! I also made some progress with iframes

[gaearon]

Closing as inactive.

We're killing DebugPanel and should have a better modularity story after #132.
We'll also include a built-in docking solution using react-dock.