PF3: Debug mode as a plugin?

[Wilto]

What would you guys think of moving PF3’s “debug mode” functionality to a plugin? I’m not sure the majority will end up using it (even if they should), so we might be able to shave a little code weight there.

[aFarkas]

+1. Maybe not even a picturefill plugin, but a general bookmarklet?

[Wilto]

Oh, that’s a cool idea. Maybe we could package it up as either-or.

[aFarkas]

@baloneysandwiches
I just went through our debug code and saw this: https://github.com/scottjehl/picturefill/blob/afarkas-pf3-proposal/src/picturefill.js#L877-L880

Is this right? We only continue in case we are in debug mode? Does this mean I can fully remove these lines?

[albell]

Removing those definitely won't break anything. I do think there are sometimes cases when a typo in markup can drive somebody crazy trying to track down. Especially with a new-ish spec that most people probably still don't understand. It's so much easier to just get a warning in the console, than sit and scratch your head wondering why it isn't working right. Silent failures suck. And then issues get filed that aren't really issues, etc. So I appreciate the desire to shave lines off the code, but in general, I'm skeptical of "debug modes". Checking for window and console is cheap and fast. Sometimes errors won't get spotted until live production, not on an isolated controlled test page.

I would like to see some of the PF3 debugging logic relocated into testing infrastructure. TBH when I waded into this briefly I saw some referencing I didn't understand. Is there any reason not to expose all or most of the internal functions by default, all the time? We don't have anything to hide do we? It makes unit testing so much easier, and the whole project much easier to contribute to. @aFarkas have you played with Intern?

[aFarkas]

Checking for window and console is cheap and fast.

This is true for typical parse errors, because you have to check them, to implement parsing, but the debug mode does a lot more. For example it checks whether your media condition order and source order make sense (i.e.: (min-width: 200px) 200px, (min-width: 300px) 33vw vs. (min-width: 300px) 33vw, (min-width: 200px) 200px). I also have some code, that checks, whether calculated sizes matches approximately the offsetWidth after the image is loaded. As a result debug mode is extreme slow.

Especially with a new-ish spec that most people probably still don't understand.

I would like to see some of the PF3 debugging logic relocated into testing infrastructure.

This screams for a new project (respimg-debugger). Most people want to see those logs in their favorite dev browser (in most cases this is Chrome). But soon Firefox will also support respimages natively. IE and Safari aren't far away either.

In general I very like the debug mode, but it is a burden for the polyfill - only part. In the long run, most devs would like to have something like this as a dev tool, not in the polyfill.

I didn't saw the debug code as part of the API also every public code is not uglifyable and makes the project much larger (I often went with functional tests, there). No, I had no time to play with Intern.

[albell]

This screams for a new project (respimg-debugger).

+1 for that then. This can be the first line of advice for people having trouble during setup.

I didn't saw the debug code as part of the API also every public code is not uglifyable and makes the project much larger.

Yeah, how much larger exactly? By default, object properties aren't mangled but variables are. Can't you just define the variables as minifyable functions and then manually assign them to the returned object with the (unminified) public names. If the public names are only written out once in that shouldn't add too much to overall file size. There's got to be a sane way to address this where we're still building for testability. Sorry, I am not an Uglify expert. Anyone?

(I often went with functional tests, there).

Yeah, that works up to a point but IMHO we really need unit tests.

[mike-engel]

So it looks like the debug code is gone now, @aFarkas. Are we still planning on making this a bookmarklet/plugin? If so, has this been started anywhere?

[aFarkas]

No it has not been started and I don't really have time for this. Although it would be a great thing. Maybe we can delegate this to the chrome dev tools team?