Code Monkey home page Code Monkey logo

Comments (11)

molily avatar molily commented on September 18, 2024

Don’t know how important the line context is. If mediator.debug would be a function instead, we could make the whole debugging PubSub based like someone proposed before. Of course, the direct line context would get lost when using console.log/debug/etc. in a separate logging module.

My concern is that I don’t want to see all debug messages the whole time. In a bigger app, that would be hundres of messages in my console while I’m just interesting in the module I’m currently working on. My personal workflow is to uncomment the console.debug calls in the module/functions I’m currently interested in. So uncommenting all console.debug and making them depend on one flag alone would render the idea pretty useless for me.

That’s why I would favor a PubSub logging approach which allows at least to enable debug messages per module or per type. I don’t have a clear idea of that yet, but someone here said that there’s a similar mechanism in node.js? See also http://www.paperplanes.de/2012/3/14/on-notifications-logsubscribers-and-bringing-sanity-to-rails-logging.html for Rails' approach.

from chaplin.

paulmillr avatar paulmillr commented on September 18, 2024

The line context is pretty important in my opinion (using it all the time, clicking on lines & adding debug breakpoints somewhere), but I agree with you that seeing all messages is a pain.

How about commenting-out console.debug-s with triple ### to make it persisted in JS files?

from chaplin.

Rendez avatar Rendez commented on September 18, 2024

If there's to be a debug mode as a config flag, I rather wrap all model, collection, controllers and views' methods on initialize() with console.debug calls containing arguments. Consider this a decorator pattern.

from chaplin.

paulmillr avatar paulmillr commented on September 18, 2024

@Rendez i like the idea. wouldn't it be too slow though?

from chaplin.

molily avatar molily commented on September 18, 2024

@paulmillr What’s the benefit of having commented-out console.debug calls in the compiled JS?

from chaplin.

paulmillr avatar paulmillr commented on September 18, 2024

@molily if chaplin will be distributed as a separate one-file library, it will allow to debug things more easily.

from chaplin.

molily avatar molily commented on September 18, 2024

I see. Good idea, will implement that.

from chaplin.

karellm avatar karellm commented on September 18, 2024

I actually don't see this as necessary. I'd like to discuss the two options below first and see what you think.

Option 1
If you want to debug your code, use breakpoints and chrome live editing (you can add a console.log to the code). From experience, when I need to log thing, it is almost always specific to the bug I'm working on. Meaning that I'll need anyway to add my own console.log(). Plus, if console.log() are meant to reproduce the stacktrace, why not using the stacktrace for debugging?

Option 2
I like @Rendez solution better (but I wouldn't use it). We could use a debug() function like that:

debug = (message, namespaces) ->
  if config.debug == true
    console.log message
  else if _(namespaces).include? config.debug
    console.log message
  else
    return

As you can see config.debug can take 3 values:

  • true: display all
  • false: display nothing
  • string: a namespace to match against

Then in the code you can have:

debug("This is a debug message", "controller#action")

Which would be displayed only if config.debug is set to controller#action.

from chaplin.

paulmillr avatar paulmillr commented on September 18, 2024

@karellm I use breakpoints constantly but this is very different from logging. Sometimes it's hard to even know where to put a breakpoint and a quick look on console.log statements shows the place instantly.

Again, non-browser debug() would not preserve line numbers. I'm not sure if this will fuck up debug process in apps where you have one app.js file generated from everything, but i'm open to test the workflow / pull reqs.

from chaplin.

karellm avatar karellm commented on September 18, 2024

What do you mean by it would not preserve line numbers?

from chaplin.

paulmillr avatar paulmillr commented on September 18, 2024

this

<!doctype html>
<html>
<head>
  <meta charset="utf-8">
  <title>Page</title>
</head>
<body>
  <script>
  var debug = function(message) {
    console.log(message)
  };

  debug(1);
  debug(2);
  debug('shit');
  </script>
</body>
</html>

from chaplin.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.