Echo JS 0.11.0

<~>

sylvainpv 2813 days ago. link 1 point
There are already many datepickers, but I never found one without any depedencies at all and working as a polyfill for input type="date".
tracker1 2813 days ago. link 1 point
Here's mine[1]. I need to button it up for an actual release, and improve the demo to show more options... it's pretty flexible and the modal is entirely standalone, with no external dependencies on the built version.

You could write a pretty thin shim for wiring up date inputs.  I didn't write an actual date input component as I wanted it to be able to tie to whatever input component/method one wanted... but have a nice full-modal picker.

Also, as you resize the screen it will handle reflows/sizing as well as vertical scrolling when the window is too small, many modal templates won't do that properly.  The size min+gz is about 20kb, using preact, preact-compat and redux... I'll probably refactor to separate the actual date-picker component from the modal, and make it more friendly for use inside react (and preact-compat) projects, without the bundling.

edit: the demo doesn't always seem to gzip the js, it's about 60k non-gzipped, but can shrink a bit with gzip level 5-9 compression.

[1] http://tracker1.github.io/md-datepicker/
soyuka 2813 days ago. link 1 point
Indeed, but without dependencies it's a lot more work. Anyway, moment is great for date management so IMO it's a dependency in lots of projects dealing with dates.

About the polyfill, with dpicker:

    ;[].slice.call(document.querySelectorAll('input[type="date"]')).forEach((e, i) => new DPicker(e))
sylvainpv 2813 days ago. link 1 point
Maybe you can use rollup or similar to bundle moment inside this lib and use tree-shaking to reduce the final size ?

About the polyfill, of course it is more complicated than that. There's no test of support, the value formatting is different, the optional HTML attributes are not handled etc. This would imply major changes in your library to mimic the standard.
soyuka 2813 days ago. link 2 points
I've introduced the type="date" attributes support (eg: min, max) and added format to the input attributes. This way, it can almost be a full polyfill, it'll still replace the type attribute with `text` so that the browser doesn't interfere with handled events/value.
soyuka 2813 days ago. link 1 point
Indeed but it's an interesting idea. Anyway, you'll have to change type=date to type=text, at least programatically to ditch the navigator behavior...

Thanks about the bundle idea, I'll think about that. Thing is, if you're handling dates with javascript, you probably already use momentjs. IMO it's easier to let the end developper bundle everything his way.
soyuka 2813 days ago. link 1 point
Not really, you've seen how many lines of code "rome" has? 2253 sloc in the standalone version, even with comments dpicker is 578 sloc, and I've lot of comments compared to rome. 

Also, I count 4 dependencies, where dpicker has only 2.

I don't speak about maintenance either (38 issues, 14 PR, not updated since a year). A date picker is supposed to be simple and straightforward. Btw rome is almost not commented.
MaxArt 2813 days ago. link 2 points
> Also, I count 4 dependencies, where dpicker has only 2.

I wouldn't count 3 of them, since they're packages by Bevacqua himself. The other is moment.js, which dpicker depends on too.
Rome *is* larger, though.
davidchase 2813 days ago. link 1 point
ok i was simply drawing comparison.. however it seems like you took to the offensive stance. When i saw your link it just reminded me of Rome by ponyfoo thats all. No harm no foul.
soyuka 2813 days ago. link 1 point
Sorry 'bout that, those were only facts didn't meant to be offensive. Thing is there are many date picker implementations and I always have the feeling that those are too heavy...
davidchase 2812 days ago. link 1 point
yes i agree the optimal one is probably something like yours minimal dependencies and a light footprint is usually best :)