Hi all,
In an effort to keep our dependency to component suites to a minimum in our company, we started wrapping some OSS components in Aurelia instead. The first effort is an Aurelia wrapper for flatpickr, and we convinced management to OSS this effort.
There is already a wrapper available for flatpickr, but it isn’t actively maintained, and we wanted to move away from making a huge config object bindable. We wanted each individual configuration property flatpickr exposes available as a standalone bindable property or custom event. So we decided to build something from scratch.
It’s still early-days, but anyone interested can check out the wrapper here.
We are newbies when it comes to OSS development, you probably can tell 
, so any feedback, issues, pull-requests,… are most welcome.
We are planning to release at least one additional component wrapper this year, probably a multiselect component built around choices using the same philosophy, so stay tuned!
14 Likes
Congratulations to you, your Team and your Management for that great descision. The learning from contributing to OSS is one of the best ways to invest in people and their experience. If that combines with your day to day work even better.
5 Likes
Took a brief look at your wrapper, just curious is there any particular reason you exposed every single options through bindable properties? It’s not a bad thing but I think it would be easier to maintain and make it for a smaller lib if you only export 1 property options. The only disadvantage I could think of would be the possibility that a user enters an invalid option but that’s not big of a deal (at least to me). I have done something similar with Bootstrap DateTimePicker wrapper and I exposed only options, which you can see here. However for the methods and events, I had to expose them all individually to make them more Aurelia like.
Flatpickr is a great picker, it’s has a small footprint and has a nice styling without the need of jQuery or any other lib. I use it in another of my lib Aurelia-Slickgrid for date picker filter in a grid, it does the job well without making my lib too big.
Hope you’ll have lots of usage and contributions in your lib. Contributing to the Open Source world is really great, not just to share but also to learn from the others. Keep up the good work. 
1 Like
Thank you for you reply, about the options thing, I guess it’s mostly a matter of personal preference
The thing about standalone properties is that you can individually bind every property, leveraging the framework’s features like behaviors, valueconverters,… on a property basis. If you have a big options object, you would need to prep that object somewhere if you plan to manipulate it at runtime, which IMO makes it worse from a MVVM point of view.
You make a good point about maintainability though, that’s why we generate that part of our code based on flatpicker’s typings. If that weren’t possible, I would certainly consider just using a big object.
2 Likes
Great news that you are releasing that as an open-source project, the only thing that pops in my mind is that you provide some documentation and working samples. For the Choices part, we have a wrapper for Toknizer here that if you like you could take a look.
2 Likes
We will provide some better docs in the coming weeks thanks for the link!
2 Likes