A Meteor Developement tool

community
1

As you probably already know if you follow our community contributors, @msavin has created some great tools to develop and debug a meteor application. Namely, Mongol let you play with the subscriptions and the local database, and the new JetSetter tool let you see and modify session variables. The community has also created some tools for the Blaze rendering engine (for instance to see your original template name or the data context attached to a DOM node).

I feel like adding a package to the application is generally not the good way to use these tools, mostly because

  1. as you directly includes the debugger tool code in your application, it may have some side effects; more specifically the code is included in development mode but not in production, and we want to limit the risk of a different behavior in development and production;
  2. we can’t use these tools to debug production applications, and/or third-parties applications; it would be useful to explore the local state (minimongo, publications, sessions, template data context) of any meteor application — and it should be technically feasible.

If a debugger tool logic and UI shouldn’t be include in the debugged application source (as a dependency on a package), it could instead be distributed as an external tool independent of the debugged application.

Is that something that makes sense to others as well? How could we create a federated “Meteor debugger tool” that one could install in its browser?

There are of course some difficulties related to the varieties of incompatible debugger tools APIs (I use Firefox, but I know most of you are using Chrome). There is also some cases when you have to modify the application behavior anyway, but even in this case the UI could still be in the browser development tool. Any thought on this? @msavin?

8 Likes
2

Maybe a Chrome extension using Meteor?
http://thebakery.io/blog/meteor-spotting-building-a-chrome-extension-using-meteor/

Since it’s all javascript, the templates could be copied over, even if they’re not reactive. But the DDP connection would work. Not sure about getting at the Session data though. And with a Chrome extension, there would probably be enough screen real estate to display both Mongol and JetSetter at the same time.

Very interesting idea though.

3

Thanks for mentioning the packages! I think your idea of having a development tool for production is really good, but I do not think there is much to gain with a browser extension approach over overlays.

I think overlays have a better use case here because:

  • they are cross browser
  • they have a UI specific to their purpose
  • they’re not distracting and quick to launch
  • they do not eat up the viewport like the console or browser extensions
  • they leverage the browser instance that’s already running
  • they’re ‘off’ when they’re not triggered
  • there’s a bigger plan for Mongol/JetSetter, and we want to keep relevant things in sight when needed
  • they’re easier to fork and customize

If we develop a developers browser extension, it would still require the Meteor app to have a package so it can send out data and take commands, which can lead to the same problems (if they are real). I think Meteor’s packaging system does a good job at preventing problems like this.

However, I could be just rationalizing my case here, so please disagree with me :slight_smile: my goal is to build the ultimate development tools, and I want to make sure everyone is comfortable using them.

Is code separation the primary benefit you see for the browser extension?

Edit re: forking code: What is the best admin package for meteor?

4

I would like to add Cordova/mobile app debugging aids to the requirements list if I may.

Not sure if overlays work for those, I haven’t tested it. But it suggests a way of making a customized debug build rather than a browser extension to cover the full scope of Meteor output with a uniform set of tools.