0.0.6 • Published 9 years ago

bangers-and-hash v0.0.6

Weekly downloads
-
License
ISC
Repository
-
Last release
9 years ago

bangers-and-hash

URL generator that supports hashbangs

npm version Build Status

Written by Joe Hare and Chris Gibson

yum

##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.
0.0.6

9 years ago

0.0.5

9 years ago

0.0.4

9 years ago

0.0.2

9 years ago

0.0.1

9 years ago