-
Notifications
You must be signed in to change notification settings - Fork 3
Debugging
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.
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
- Scroll down to the "Sources" section
- Make sure that "Enable JavaScript source maps" is ticked and close the settings.
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:
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
- Scroll down to the last line inside the
addTodomethod - 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.
Now we want to try and trigger that breakpoint:
- Enter a value in the "Add todo" box
- Click the "Add" button
You should now see the breakpoint in action, complete with your value in the local scope.
And that's it for client-side debugging - you can now use the Chrome debugger to inspect and manipulate values, etc...
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:
- Now hit the debug button
You should see miso running in the WebStorm console like so:
- Now open
/system/api/flatfiledb/flatfiledb.api.js, and put a breakpoint on the last line of thefindmethod.
Now if you go back to your browser todos app:
Reload the page, and you will see the breakpoint being activated in WebStorm:
Now click the "resume program button", and you'll see that the breakpoint it is immediately invoked again!
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.










