Rome is a dependency-free, customizable date picker | Hacker News Reader

Rome is a dependency-free, customizable date picker

github.com

46 pointsbevacqua47 comments

Dependency free, apart from all those dependencies it has? https://github.com/bevacqua/rome/blob/master/package.json#L2...

Edit: seems the dependencies are bundled in the distributed files, making it 55kb minified!

It even says it depends on moment even in the readme. False advertising!

I'm looking at the example, specifically choosing only a date; You need to click off of the box entirely before the date gets updated, and it doesn't close when you click a date itself.

Fixed and thank you. In the future please report these kind of issues in the repository itself.

I'm a bit confused, how are we supposed to use this without node? Definitely interested in the standalone version.

  Note that if you're using the standalone version, the API is published under
  the rome global. If you're using CJS, then you'll have to require('rome').

You can use Browserify[1] or WebPack[2] as a CommonJS module loader.

[1]: http://browserify.org/ [2]: http://webpack.github.io/

Right, so when he says dependency free...

By that reasoning nothing is dependency-free, as it requires a browser, or a computer, or a universe...

Dependency-free almost always refers to runtime dependencies. A build tool is not a dependency. (Rome isn't dependency-free in that sense either[1], but hey...)

[1]: https://github.com/bevacqua/rome/blob/master/package.json#L2...

Why isn't a build tool a dependency? Seems arbitrary to me.

Because it isn't needed at runtime. Definitely not arbitrary. scons isn't a dependency of Google Chrome.

Yeah I guess that makes sense. Fair enough.

Because when we talk about dependencies we usually talk about runtime dependencies. If you'll need to load other stuff to run this as an end user.

Do you count gcc and make as "dependencies" on installing and/or running some software built with them?

I would suggest something analogous to "static build" rather than anything having to do with dependencies.

By that reasoning everything is dependency free, because I can just static link all the required libraries, or provide them in a vendor directory in the download.

Just take the assets in the `dist` directory and the API is accessible on the `rome` global.

I think maybe don't advertise it as dependency free. The modifications to get it to native js aren't massive, but it's not dependency free. For one thing if I make those modifications I then lose all future updates (or they become a massive pain in the ass).

Edit: I'm wrong, I misunderstood dependency free. It would be great to have a native js version of this anyway.

I don't understand how this can be considered dependency free in any sense - it has a dependency on Moment.js, which is a fairly large (and very popular and good) library for working with dates in JavaScript. Without Moment.js, this library would not work - therefore it is "dependent" on that. This is what the word "dependency" means.

Just because you can bundle up that library in the dist doesn't mean it's not a dependency.

This looks like it lacks i8n. Many other (jquery ui based) datepickers have i8n modules with built in foreign day / month names.

moment.js exposes i18n options[1], I'd just have to expose an API to allow you to add/set a language through their API.

[1]: http://momentjs.com/docs/#/i18n/

This looks great. The two deal-breakers for me at the moment are the missing i18n, and support for older browsers (which I realize is increasingly rare these days, but unfortunately our webapp needs to support IE6+ for the time being. Yes, for real reasons).

Now you can access moment through rome.moment, there you can do whatever you want, i18n-wise

Cool, kudos to you for being so responsive! I see several threads with a similar resolution here.

Update on IE support -- for the moment it seems to support IE 11 only.

How would one set week start day to monday in this? Can't really see an option for that among the options.

Doesn't look configurable: https://github.com/bevacqua/rome/blob/master/src/rome.js#L35...

Just implemented this. `weekStart: 1`

Looks nice. One tinsey issue; It doesn't seem to allow me to clear the field. If I accidentally clicked on the text field, I have no way to empty the field again.

I cleared the contents of the field and clicked elsewhere, it fills the field with the last selected value.

`invalidate: false` or `required: false`

This looks awesome, great work.

I have been looking for a good datepicker to use at work, this one seems to miss a few things: No i18n (for days and months), doesn't close if you reclick the input, and no "today" button.

Does have i18n. Just configure moment before using rome.

I've been using http://amsul.ca/pickadate.js/ lately and it's been excellent. Highly recommend it.

a time-saving feature of many date pickers is the ability to exclude certain dates (weekends, holidays, sold out, etc.). Pretty easy to implement - just a suggestion.

definitely on the road map

implemented in v0.4.0 https://github.com/bevacqua/rome/blob/master/CHANGELOG.md

Bad news. I've had a javascript library named Rome that I created over a year ago, https://github.com/Akkuma/Rome/commit/0cdcd210351d5c546064be...

Looks like you forgot to land-grab the npm package name :)

I wasn't really intending to turn it into an npm package as I wrote it for browsers due to its use of MutationObserver.

npm is very much used for browser libraries these days: http://browserify.org/.

I've never used browserify, despite working in node, so I could be off base but I thought you didn't need to make it an npm package to support CommonJS and play nicely with the rest of your browserify js.

You don't need a package.json to use CommonJS or even to use Browserify, but as a developer I don't want to copy external dependencies into a vendor folder to use them, I want to declare my deps in my app's package.json -- so any lib that uses CommonJS but doesn't provide a package.json I will probably not bother to use.

People who use npm packages in browser code are pretty much all using Browserify or Webpack and leverage npm. (Many people use Bower, but I don't see the point of using two overlapping package managers.)

It's a new dawn of modular JS code; no more global namespace, no more stuffing CDN links in your <head>. I recommend giving it a go.

And it's gained so much traction. Bevacqua absolutely has to change the name!

I didn't try to gain traction with it since no one will use a library without documentation. Your passive aggressiveness is completely unwarranted. I never once stated he had to change his library's name. I was simply pointing out that the name was already used, since I know I personally try to avoid conflicts.

How does this handle the existence of native datepickers (a la Chrome)?

Ignores those, they're far too differently implemented across browsers. This just assumes you're using a `<input type='text' />`

Does it let you pick dates with the keyboard?

Not at the moment

Reply on news.ycombinator.com