Live data from Hacker News

Pickadate.js

github.com

101–110 of 130 posts

Re: Pickadate.js

#101
What I would really love is for someone to provide both a date and time picker. For some reason everybody is concerned only about the date.

Re: Pickadate.js

#102
post #40

Earlier quoted context omitted.

looks like a single var pattern inside an immediately invoked function expression to me. works well and great for readability

Thank you for not calling it a "self-executing anonymous function".

I'm a proponent of simply calling them 'immediate functions'.

Re: Pickadate.js

#103
post #77
post #29

Earlier quoted context omitted.

The fact that the code is very neat and is well documented bothers me. Also the fact that javascript is a lot more readable when you put a blank line between every two lines bothers me (a lot!). And that it works perfectly and looks great, man that bothers me.

// If datePassed is true else if ( datePassed === true ) { Yes, very well documented. >.>

  // Return the calendarObject
  return calendarObject
It's like this all the way through the code!

Re: Pickadate.js

#104

Earlier quoted context omitted.

I have always wondered why javascript date pickers were always over complicated for the job. https://github.com/listenrightmeow/daterange Under 5k/100 lines uncompressed. You can easily modify above to work in a prototype fashion without a library. Unfortunately I was lazy when I wrote it and used ender/jquery for selector support.

If you are going to offer something you claim to be better, it should be better. I did a "git clone" and opened the example: * The example looks unappealing. Not styled, not bound to a text field. * It's not clear to my why clicking twice in a row produces a range — should this not be accomplished through mouse dragging or similar? * If I select an end date that precedes the start date, it shows an alert box, which a…

i enjoyed this post.

Re: Pickadate.js

#105
A few random comments...

This value is not what it says:

    SECONDS_IN_DAY = 86400000,
That's the number of milliseconds in a day. Instead of a magic precalculated number, why not create all the relevant constants so the values become perfectly clear:

    HOURS_IN_DAY = 24,
    MINUTES_IN_DAY = HOURS_IN_DAY * 60,
    SECONDS_IN_DAY = MINUTES_IN_DAY * 60,
    MILLISECONDS_IN_DAY = SECONDS_IN_DAY * 1000,
Personally, I find these kinds of string constants get in the way:

    STRING_DIV = 'div',
    STRING_TR = 'tr',
The string 'div' is never going to change to something else, is it? It would be better to just use the string directly where you need it.

This is an amazing and scary piece of code:

    /**
     * Get the count of the number of
     * days in a month, given the
     * month and year
     */
    getCountDays = function( year, month ) {
    
        var
            // Set flip based on if month is
            // before or after July
            flip = ( month > 6 ) ? true : false
    
        // If it's February
        if ( month === 1 ) {
    
            // If it's not a leap year
            // then 28 otherwise 29
            return ( year % 4 ) ? 28 : 29
        }
    
        // If it's an odd month ID
        if ( month % 2 ) {

            // If it's after July then 31
            // otherwise 30
            return ( flip ) ? 31 : 30
        }
    
        // If it's an even month ID
        // and it's after July then 30
        // otherwise 31
        return ( flip ) ? 30 : 31
    }, //getCountDays
It also calculates leap years incorrectly - try getCountDays(1900,1). February 1900 had 28 days, not 29.

Why not let JavaScript do the work for you?

    getCountDays = function( year, month ) {
        var msInMonth = new Date(year,month+1) - new Date(year,month);
        return Math.floor( msInMonth / MILLISECONDS_IN_DAY );
    },
This will handle all leap years correctly.

You can probably do something similar in your createDate function to avoid the manual tests.

Also the name getCountDays is not very informative. Maybe getDaysInMonth?

The settings options use names_with_underscores, but that's not very idiomatic in JavaScript (except for capitalized constants). camelCaseNames would be more comfortable.

Re: Pickadate.js

#106
post #66

pickadate is just as opinionated as jquery ui. why must component writers insist on hard-coded (and non-customisable) use-cases. there's simply no need to mandate an `input` element.

You might enjoy my attempt. No jQuery dependency and binding to an input field is optional.

https://github.com/dbushell/Pikaday

Re: Pickadate.js

#107
post #95
post #31

Earlier quoted context omitted.

No. DatePickers, along with Forms, are the bane of my existence. More choices that are brought to light, the better.

Agreed! I had no idea how many bad ones there were until I needed one for a project.

And yet you keep us in suspense...

Re: Pickadate.js

#109
post #100
post #51

Earlier quoted context omitted.

There you go - this will make your life easier then: http://dojotoolkit.org/reference-guide/1.8/dijit/form.html#d...

Please, never use the Dojo Toolkit. I was forced to use it on a project and working with it was reinventing the wheel while pulling out hair. It was overly complicated for something that needed to be straightforward and simple.

Amen to that. The doc for it sucks too (not that there's enough there, but most doc for it found by google et al is obsolete/deprecated. And last but not least... the plugin ecosystem for dojo sucks even worse, and whatever widgets/dijits actually exist for it, usually look like @ss. The only one who seems to be committed to dojo is...IBM.
Post reply on HN