Want more? Subscribe to my free newsletter:

Lets Tincr: Bi-directional Editing And Saving With The Chrome DevTools

August 10, 2012

Following on from my post last year on the Chrome DevTools AutoSave project, I’d like to share another useful extension Nikita Vasilyev brought to my attention called Tincr, by Ryan Ackley.

We often find ourselves switching back and forth between the Chrome Developer Tools and a text editor while debugging. This can sometimes feel unnecessarily time-consuming. We make changes to scripts and styles from within the DevTools as part of our debug session, check what changes were made and then have to manually apply them to our source files. Similarly, unless you have a watch or live Reload process setup, updates to your source files require a browser reload.

Tincr changes that. The idea is that you can:

  • Make changes inside the DevTools (to scripts and styles) which are then automatically reflected in your source files
  • Make changes to your source files (CSS/JavaScript) which result in a browser reload showing your changes

In short, you get bi-directional editing without the need to leave the Developer Tools and your debug session unless you really need to.

This solves the problem of changes you make inside the DevTools only persisting until you’ve reloaded the page. You no longer have to worry about changes not being saved to the file-system nor do you have to worry about copying and pasting changes from the tools to your editor.

Installation

Grab the latest sources from https://bitbucket.org/ryanackley/tincr. Although the Tincr site recommends finding it on the Chrome Web Store, it’s currently still going through the review process and so the sources are your best option for getting started.

Once extracted, load Tincr as an unpacked extension in Chrome whilst in developer mode (to enable developer mode to go chrome://extensions and check ‘Developer mode’).

Setup

Once you’ve installed Tincr, you’ll be presented with a new panel in the DevTools. The Tincr panel essentially lets you configure options such as the root directory for your application as well as the project type you’re working on. 

Tincr supports 4 application types (Ruby on Rails, Chrome Extension, Atlassian Plugin, Configuration file).

For example, if you’re a Ruby developer and are debugging your app with the DevTools, simply select the RoR option. This will expect your scripts to be stored under /app/assets/javascripts and your stylesheets under /app/assets/stylesheets. Changes to these files will result in a reload.

If you’re like me, and the above doesn’t describe your typical file-path setup, you’ll want to opt for the ‘Configuration file’ option. A Tincr config file basically contains a number of regular expressions informing Tincr how it should map between files and URLs. It should be named tincr.json and stored in your root directory.

The below is a config file which maps between scripts stored in app/js and stylesheets stored in app/css to their relative URLs /js and /css.

{
    "toFile" : [
        {"from": "/(.+\.js)",
         "to": "/app/js/$1"},
        {"from": "/(.+\.css)",
         "to": "/app/css$1"}
    ],
    "fromFile" : [
        {"from": "(\\|/)app\1(?:js|css)
\1(.+(\.js|\.css))(\.[a-zA-Z]+)?$",
         "to": "/$2?body=1"}
    ]
}

and similarly, the RoR config file (just for reference), looks like:

{
    "toFile" : [
        {"from": "/assets/(.+\.js)",
         "to": "/app/assets/javascripts/$1"},
        {"from": "/assets/(.+\.css)",
         "to": "/app/assets/stylesheets/$1"}
    ],
    "fromFile" : [
        {"from": "(\\|/)app\1assets\1
(?:javascripts|stylesheets)\1(.+(\.js|\.css))
(\.[a-zA-Z]+)?$",
         "to": "/assets/$2?body=1"}
    ]
}

toFile describes how it should save from the DevTools and basically iterates through each from resource, matching it to a file using the to pattern, which is relative to your base directory. The fromFile section is used for live reloading and is also relative to the base directory.

This is used to improve the file-to-url relationship inference, where you may be working with source files that require compilation (e.g CoffeeScript), which isn’t supported in auto-save but can have compiled sources reloaded.

Workflow

The Tincr workflow is relatively straight-forward. Open up the index to your application and either:

  • Make changes to your CSS via the Styles pane on the Elements panel
  • Freely edit the .js and .css files within the Sources panel.

 

In my own experience, I’ve found the bi-directional CSS editing support to be the most reliable, however script editing should work fine too.

For developers interested in using Tincr to edit preprocessed code via the DevTools (e.g CoffeeScript, SASS) directly, you’ll require better sourcemaps support for these preprocessors.

I think we’ll see these start to improve in the near future, but for now, bi-directional editing for JavaScript and CSS is what Tincr supports best out of the box.

Reminder: The Sources Panel & Saving

Although automatically having your changes saved from within the DevTools is great, remember that you have the ability to edit sources directly from within the Sources panel out of the box.

This can be done using the Save and Save As options within the Source panel’s context menu. With syntax highlighting and an editor already in there, you can already edit files from our tools..just not in as automated a fashion.

Conclusions

Tincr is an interesting experiment and I’ve love to see how well it might fit into a modern workflow once there’s better support for editing files that are preprocessed. There’s also a little more work that could be done to smooth out the user experience (e.g allowing developers to select their script and stylesheets directories from the UI, over using config files).

That said, it’s definitely worth checking out and may come in helpful if support for just CSS and JavaScript is sufficient for your needs.

Note: If you wish to discuss Tincr with the author directly, there's a discussion thread about the tool on the DevTools Google Group.