Skip to content
jsguy edited this page May 24, 2015 · 4 revisions

Debugging a miso app

In order to debug a miso app, (or any isomorphic JavaScript app for that matter), you'll need to be able to debug on both the client and the server. Here we will demonstrate debugging the client-side code using Chrome, and the server code using JetBrains WebStorm 9. Miso can actually be debugged using any standard node and client-side debugging tools that support source maps.

In this example we're going to debug the example todos app, so be sure you know how it works, and you know how to install it - if you don't know how, please read the todos app tutorial first.

One thing to keep in mind is how miso works: it is isomorphic which means that the code we have is able to run both server and client side. Of course it doesn't always run on both sides, so here is a handy little table to explain what typically runs where and when, for the todos example:
File action Server Client
/mvc/todo.js index Runs when a browser loads up /todos Runs when you interact with anything
/system/api/flatfiledb.api.js find Runs when index is run either server (directly) or client side (through the api) Never runs on the client - an ajax request is automatically generated by miso

Those are the only files that are used in the todos example.

Client-side miso debugging

Firstly let us make sure that we've configured Chrome correctly:

  • Open the dev tools (CMD + ALT + J on Mac, F12 on PC)
  • Click the setting cog

Chrome cog

  • Scroll down to the "Sources" section
  • Make sure that "Enable JavaScript source maps" is ticked and close the settings.

Chrome todos source

Now Chrome is ready to interact with miso. Next run the miso todo app in development mode - i.e. in the directory you setup miso, run the following:

miso run

When you're up and running, go to the todos URL, if everything is setup with defaults, it will be:

http://localhost:6476/todos

Next open the dev tools in Chrome and:

  • Click the "Sources" tab
  • Open the "mvc" folder
  • Click on the "todo.js" file

You should now see a todo.js file in the right-hand pane

Chrome todos source

  • Scroll down to the last line inside the addTodo method
  • Click on the line-number next to the return statement to set a breakpoint

You should now see a mark next to the line, and a breakpoint in the list of breakpoints.

Chrome todos source

Now we want to try and trigger that breakpoint:

  • Enter a value in the "Add todo" box
  • Click the "Add" button

Chrome todos source

You should now see the breakpoint in action, complete with your value in the local scope.

Chrome todos source

And that's it for client-side debugging - you can now use the Chrome debugger to inspect and manipulate values, etc...

Server-side miso debugging

Note: Please clear any breakpoint you might have set in Chrome, so it won't interfere with our server-side debugging session - of course you can use both together, but for now let us clear them, and also stop the miso server, if it is still running, as we will get WebStorm to handle it for us.

In this example we're going to use WebStorm - you can use any IDE that supports node debugging, or free tools such as node-inspector, so this is simply for illustrative purposes.

First we need to setup our project, so in Webstorm:

  • Create a new project, setting your miso directory as the root.
  • Add a new node project configuration, with the following settings:

Chrome todos source

  • Now hit the debug button

Chrome todos source

You should see miso running in the WebStorm console like so:

Chrome todos source

  • Now open /system/api/flatfiledb/flatfiledb.api.js, and put a breakpoint on the last line of the find method.

Now if you go back to your browser todos app:

http://localhost:6476/todos

Reload the page, and you will see the breakpoint being activated in WebStorm:

Chrome todos source

Now click the "resume program button", and you'll see that the breakpoint it is immediately invoked again!

Chrome todos source

This is simply because miso renders the first page on the server - so depending on how you structure your queries, it will use the API twice - once from the server side rendering, and once from the client-side. Don't worry - this only happens on initial page load in order to render the first page both server side and client side, you can read more about how that works here:

How miso works: First page load

So, you are now able to inspect the values, and do any kind of server side debugging you like.

Clone this wiki locally