Re: [DISCUSS] Switching to a better alternative of Pikaday.js

2018-10-17 Thread Tamás Fodor
Organizing the codebase as a monorepo could be a good idea to address it. There's a popular and very powerful tool called Lerna to maintain a monorepo: "Splitting up large codebases into separate independently versioned packages is extremely useful for code

Re: [DISCUSS] Switching to a better alternative of Pikaday.js

2018-10-16 Thread Michael Miklavcic
I'm still +1 to this approach. Thanks guys! To Tibor's other point - the management UI is currently a completely separate service, as I understand it. If there is infrastructure you think is shareable while still allowing them to be independently deployed, then I think it would be desirable to

Re: [DISCUSS] Switching to a better alternative of Pikaday.js

2018-10-16 Thread Tibor Meller
Thanks, Tamas! The plan you described seems a good approach to me. Let's wait another day before we create Jira tickets from these steps to make sure no one else has other concerns. One more question: how much of these changes could be applicable to the Management UI? It would be great plus to

Re: [DISCUSS] Switching to a better alternative of Pikaday.js

2018-10-15 Thread Michael Miklavcic
I like point #3 from Tibor - you can pick and choose how you compose the date/time pickers. It would be nice to not have times required as a dropdown at some point or another, or at the very least something we can customize differently to our liking :) Per the comments from Tamas, Shane, and

Re: [DISCUSS] Switching to a better alternative of Pikaday.js

2018-10-15 Thread Shane Ardell
We are definitely on the same page. On Mon, Oct 15, 2018 at 2:06 PM Tibor Meller wrote: > @Shane It seems like we're agreed on this. :D > > On Mon, Oct 15, 2018 at 1:18 PM Tibor Meller > wrote: > > > Hi Guys, > > > > I think we could consider moving to ng bootstrap. It solves most of our > >

Re: [DISCUSS] Switching to a better alternative of Pikaday.js

2018-10-15 Thread Tibor Meller
@Shane It seems like we're agreed on this. :D On Mon, Oct 15, 2018 at 1:18 PM Tibor Meller wrote: > Hi Guys, > > I think we could consider moving to ng bootstrap. It solves most of our > problems and makes our code base cleaner easier to maintain. > > Here are some benefits I see: > 1. we could

Re: [DISCUSS] Switching to a better alternative of Pikaday.js

2018-10-15 Thread Tibor Meller
Hi Guys, I think we could consider moving to ng bootstrap. It solves most of our problems and makes our code base cleaner easier to maintain. Here are some benefits I see: 1. we could eliminate jQuery from the code base Currently, we're using bootstrap but an implementation based on jQuery.

Re: [DISCUSS] Switching to a better alternative of Pikaday.js

2018-10-15 Thread Shane Ardell
> > I'm not satisfied with the alternative individual solutions out there on > npm. I'd rather pick a component library like the angular port of Bootstrap > or the angular material library > . Both of them have a date picker

Re: [DISCUSS] Switching to a better alternative of Pikaday.js

2018-10-10 Thread Nick Allen
> Before making a decision on what's next, I'd to ask you a question. Is it > really a priority and is it really worth the effort to touch our currently used date picker component to get ~15% reduction in the bundle size by removing moment? As an aside, I think there is a greater benefit here

[DISCUSS] Switching to a better alternative of Pikaday.js

2018-10-10 Thread Tamás Fodor
I'd like to open a discussion about switching to a new date picker library in the Metron Alerts UI regarding to the following: https://lists.apache.org/thread.html/2e4fafa4256ce14ebcd4433420974e24962884204418ade51f0e3bfb@%3Cdev.metron.apache.org%3E