bangers-and-hash

URL generator that supports hashbangs

Written by Joe Hare and Chris Gibson

##Installation##

> npm install --save bangers-and-hash

##Usage##

var Banger = require('bangers-and-hash');

var banger = new Banger();
banger
  .protocol('http')
  .host('yourserver')
  .port('8080') // your port
  .resources(['path', 'to', 'resource']) // server side resource path
  .hashBang()
  .hashResources(['client', 'side', 'resource']) // client side resource path
  .param('queryparam1', 'and its value')
  .param('queryparam2', 'anothervalue42');

  var url = banger.url();

• Note: These methods can all be called in any order, as long as url() is called last.
• This example produces http://yourserver:8080/path/to/resource/#/client/side/resource?queryparam1=and%20its%20value&queryparam2=anothervalue42

##Gulp Targets ##

• gulp test - run the mocha test suite
• gulp watch - start a watcher for the library and tests. Unit tests are re-ran with each update to keep a solid feedback loop for maintainers.

##Contributing## Right now this is all this module supports. It was written for a specific private project but it will be extended over time.

Feel free to send us a pull request! Keep in mind

• Most pull requests need to be related to an issue.
  • If your issue number is 42 and related to say, "support AMD module" name it issue42-support-amd-module.
  • Just ensure the text tokens in the name are brief but somewhat descriptive.
  • If there's not an issue for what you want to change please create one!
• Common style guidelines
  • 2 space indentation. No tabs please
  • Avoid anonymous functions. Try to always give them a name so there's a readable stack trace for errors.
  • We'll review your branch beforehand and address any changes.
• Your feature/fix must have accompanying unit tests.
  • We generally work TDD style on this project.
  • All existing tests passing in case they became obsolete and removed after a conversation about it.
• In commit messages use the command/imperative form - "Fix an elusive bug!" rather than "Fixes an elusive bug!"
• Commit message top lines need to be <= 73 characters. If you need to say more, insert blank line and then you lengthy explanation. More info is good, there's just good and bad places for it.
• Ask questions! These rules are there to keep the project clear, not shame new contributors. We'll help you get everything lined out.
• In fact, there's a question label for issues. Use it to ask us any old thing and it'll be a nice way to asynchronously record troubleshooting and disambiguations.