This code provides two things.
To use this results of this system you will also need the npm package, mojito-debug-view. This will be released separately.
initial version of mojito debug interface
removed debug verify logic.
Merge branch 'develop' of git://github.com/yahoo/mojito into sweetand…
fix lint complaints
log render data.
added render data.
turned off perfmarkers
added some docs for the debug api
added more documentation.
Merge remote branch 'origin/sweetandsour' into develop-perf
Merge branch 'develop-perf' of git://github.com/yahoo/mojito into dev…
fixes to make dispatch profilling and render logging work.
return !!store.modules[flag]; should be just enough.
In mojito-perf we use a different technique to avoid doing all the "id" computation everywhere, something that is subject to change in the future. What we do is to pass command or a string. If command is passed, internally we know how to get the ID from the command structure.
Check idFromCommand in perf.server.js
So, this line will become something like:
adapter.debug.profOpen("dispatch", command.instance.debugID, command);
profOpen is a general purpose profiling API. It is called in several places. We don't want to pass command in here.
We can create a new function in the api to do this, we can mirror what perf.server.js does.
adapter.debug.profOpen("dispatch", command.instance.debugID, adapter.debug.idFromCommand(command));
I don't like this API because not all elements in mojito will have access to adapter obj. That's one of the reasons we use Y.mojito.perf.* as something that is available at any given time, without requiring it.
Really the API is attached to the req object. This is done by the debug middleware that detects that the debugger should be turned on. The existing mojito.perf system is only useful for a single request. If you have multiple requests occurring at the same time the results will get all merged together. By attaching the debugger to the request we can keep all the data separate. This needed when we look towards running this in a production environment.
This PR is very long and confusing, probably because there is a mix of old code with new code, and refactors in the middle, I will need more time to make sense of it.
I do have few questions already:
The intent is to eventual make this api work on both the client and server side. We should be able to get the Debug UI to merge both server side and client side results together. This is a feature we plan to work on next quarter.
To use the debugger in a model, one would need to pass down debugger to the getData methods in the model.
The code does work woth the current perf api. If you enable perf marks, prof.PerfMark will be an available debug flag. The results will appear in a water fall display.
fixed bug with debug interface to perf.
logged timeline ends correctly.
fixed unit tests.
@bthaeler let's have a quick meeting to talk about this PR. /cc @drewfish
The develop-perf branch just went away, and github auto-closed pull requests against it. You'll have to redo this pull request against the develop branch. Sorry about this.