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

[Tamás Fodor <ft...@gmail.com>]

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

https://github.com/apache/metron/pull/1219#discussion_r223733562

A week ago, I opened a PR about removing moment.js from the code base to
decrease the size of the production javascript bundle. I could achieve 15%
loss in the final bundle size which is admittedly not a game changer but
still. Not to mention if we want to heavily rely on date manipulator
functions in the future it's better to get rid of it at this early stage.
Go here <https://github.com/apache/metron/pull/1219> to read more about the
background and the results. I tried to provide as many details as I could.

So far, so good. But then I stumbled upon an obstacle, Pikaday
<https://github.com/dbushell/Pikaday>.

Before going further, let me thank Tibor Meller, Michael Miklavcic and
Nicholas Allen for taking their time to go through my proposal to deal with
the aforementioned issue. At the end, we agreed on basically not going with
my temporary solution that intended to solve the related problems of
Pikaday and we'd rather like to find and change for a better alternative.

To be fair, Pikaday is a pretty good date picker module, its only problem
is the moment dependency if it's installed via npm. But other than that, it
functions perfectly. Zero dependencies, small, etc. Long story short, it's
good for us unless we want to get rid of moment.js.

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?

I'm asking it because if we want to do so, considering that it's a huge
topic, the following questions might come up:

*A: What component do we want to use instead of Pikaday?*

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
<https://ng-bootstrap.github.io/#/home> or the angular material library
<https://material.angular.io/>. Both of them have a date picker component
and many other components to rely on and reuse throughout the Metron app.

*B: What component library do we want to use?*

Introducing a new component library requires a lot of research and there
are many things we have to agreed on. Since it's a long term plan because
it would be great to use it consistently instead of picking a new one a few
months later just because we chose wrongly.

*C: What about the jQuery version of Bootstrap?*

So basically we already have a component library and we still use it but
we're also planning to replace it with another or the angular port at least
to get the most out of the angular rendering engine. Since it uses jquery,
it's much less performant than a port written in Angular.
And I think it's a bad idea to introduce a new one and use multiple
component libraries within one project.
We can also pick the date picker component from the jQuery Bootstrap but,
again, it's not as efficient as the angular port so it seems to be
beneficial to replace it with something else.

What do you think, guys?

Thanks,
Tamas

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

[Tamás Fodor <ft...@gmail.com>]

Organizing the codebase as a monorepo could be a good idea to address it.

There's a popular and very powerful tool called Lerna
<https://github.com/lerna/lerna> to maintain a monorepo:

"Splitting up large codebases into separate independently versioned
packages is extremely useful for code sharing. However, making changes
across many repositories is messy and difficult to track, and testing
across repositories gets complicated really fast.
To solve these (and many other) problems, some projects will organize their
codebases into multi-package repositories (sometimes called monorepos).
Projects like Babel, React, Angular, Ember, Meteor, Jest, and many others
develop all of their packages within a single repository.
Lerna is a tool that optimizes the workflow around managing multi-package
repositories with git and npm.
Lerna can also reduce the time and space requirements for numerous copies
of packages in development and build environments - normally a downside of
dividing a project into many separate NPM package."

To me, it seems to be a good approach to deal with what we have in the
metron-interface folder. It forces you to write independent and focused
packages regarding the single responsibility responsible. You can easily
share them across the alerts and the management UI. I highly recommend you
to go through the docs and think about it.

Btw, shouldn't we register an organization on npm to publish our packages?
@hortonworks is already taken. Does it belong to us? Do you know who's got
permission to publish packages under it? Can we also have the rights to
publish?

Cheers,
Tamas

On Tue, Oct 16, 2018 at 6:50 PM Michael Miklavcic <
michael.miklavcic@gmail.com> wrote:

> 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 make improvements there also. My only
> caution would be that there are instances where early architectural
> duplication seems wasteful, but is really just a short-term illusion
> because of code maturity. ie, there are instances where you absolutely
> don't want to tie architectural components together even if it seems like
> you're duplicating code. I don't believe this fits that concern, but I
> thought it was worth mentioning. To that end, I wouldn't have your progress
> on the alerts UI improvements be hampered by the management UI. I think we
> can take the lessons learned in the Alerts UI and apply them to the
> management UI when it makes sense to.
>
> Best,
> Mike
>
>
> On Tue, Oct 16, 2018 at 2:21 AM Tibor Meller <ti...@gmail.com>
> wrote:
>
> > 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 see those two UI getting closer to each other
> > with the underlying technologies instead of shifting away.
> >
> > On Tue, Oct 16, 2018 at 9:37 AM Tamás Fodor <ft...@gmail.com>
> wrote:
> >
> > > I'm agreeing with moving forward with Ng Bootstrap. In order to do
> that,
> > I
> > > think it would be a good start to refactor those components which use
> the
> > > obsolete jquery based vesrion of bootstrap. Shane has already started
> it
> > by
> > > refactoring the Modal dialog in the management UI (We also have this
> > > component in the alerts UI). Once we've succeeded that, we can remove
> > > (hopefully) jQuery form the dependency list.
> > > As the second step, we should migrate to Ng bootstrap. I'm assuming
> that
> > if
> > > the jquery based Boostrap is replaced with Ng bootstrap, we're still
> good
> > > since we're using only classes from the bootstrap CSS which is shared
> > > across jQuery bootstrap and Ng bootstrap.
> > > If everything is good and nothing is broken we can start working on the
> > new
> > > date/time picker component based on Ng bootstrap and then we can get
> rid
> > of
> > > Pikaday.
> > > Once Pikaday is completely eliminated from the system, we can be sure
> > that
> > > the PR about eliminating moment.js is ready to go.
> > >
> > > Cheers,
> > > Tamas
> > >
> > > On Mon, Oct 15, 2018 at 8:36 PM Michael Miklavcic <
> > > michael.miklavcic@gmail.com> wrote:
> > >
> > > > 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 Tibor, is there any reason we
> > > > wouldn't want to move forward with the Angular port of Bootstrap, NG
> > > > Bootstrap? Per your arguments for it, this sounds like the right path
> > > > forward to me. I'm +1 on this approach provided someone doesn't come
> > back
> > > > with a "well, there's only this problem..."
> > > >
> > > > Best,
> > > > Mike
> > > >
> > > > On Mon, Oct 15, 2018 at 7:39 AM Shane Ardell <
> shane.m.ardell@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > We are definitely on the same page.
> > > > >
> > > > > On Mon, Oct 15, 2018 at 2:06 PM Tibor Meller <
> tibor.meller@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > @Shane It seems like we're agreed on this. :D
> > > > > >
> > > > > > On Mon, Oct 15, 2018 at 1:18 PM Tibor Meller <
> > tibor.meller@gmail.com
> > > >
> > > > > > 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 eliminate jQuery from the code base
> > > > > > > Currently, we're using bootstrap but an implementation based on
> > > > jQuery.
> > > > > > > Angular and jQuery doesn't build to live together.
> > > > > > > 2. NgBootstrap made to being used with Angular
> > > > > > > It uses Angular instead of hacking the rendering/dom
> manipulation
> > > > with
> > > > > > > jQuery.
> > > > > > > 3. It contains a date and a time picker.
> > > > > > > It's easy to combine to a datetime picker.
> > > > > > > 4. No dependencies.
> > > > > > > By changing currently used bootstrap to NgBootstrap we could
> > clear
> > > > > > jquery,
> > > > > > > moment, pickaday, pickaday-time libraries from our
> dependencies.
> > > > > > >
> > > > > > > Another huge advantage of NgBootstrap is that we don't have to
> > > > rewrite
> > > > > > > anything we don't want to. Our UI already uses Bootstrap.
> > > > > > >
> > > > > > > What do you guys think?
> > > > > > >
> > > > > > > On Wed, Oct 10, 2018 at 4:19 PM Nick Allen <nick@nickallen.org
> >
> > > > wrote:
> > > > > > >
> > > > > > >> > 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 too.  We
> > need
> > > > to
> > > > > > make
> > > > > > >> a conscious effort to identify libraries that we are using
> that
> > > are
> > > > > > >> deprecated, lack community support, and are unlikely to be
> > > > maintained
> > > > > > and
> > > > > > >> updated for security vulnerabilities.  We need to actively
> > > identify
> > > > > and
> > > > > > >> replace those.
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <
> > > ftamas.mail@gmail.com>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > 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
> > > > > > >> >
> > > > > > >> >
> > > https://github.com/apache/metron/pull/1219#discussion_r223733562
> > > > > > >> >
> > > > > > >> > A week ago, I opened a PR about removing moment.js from the
> > code
> > > > > base
> > > > > > to
> > > > > > >> > decrease the size of the production javascript bundle. I
> could
> > > > > achieve
> > > > > > >> 15%
> > > > > > >> > loss in the final bundle size which is admittedly not a game
> > > > changer
> > > > > > but
> > > > > > >> > still. Not to mention if we want to heavily rely on date
> > > > manipulator
> > > > > > >> > functions in the future it's better to get rid of it at this
> > > early
> > > > > > >> stage.
> > > > > > >> > Go here <https://github.com/apache/metron/pull/1219> to
> read
> > > more
> > > > > > about
> > > > > > >> > the
> > > > > > >> > background and the results. I tried to provide as many
> details
> > > as
> > > > I
> > > > > > >> could.
> > > > > > >> >
> > > > > > >> > So far, so good. But then I stumbled upon an obstacle,
> Pikaday
> > > > > > >> > <https://github.com/dbushell/Pikaday>.
> > > > > > >> >
> > > > > > >> > Before going further, let me thank Tibor Meller, Michael
> > > Miklavcic
> > > > > and
> > > > > > >> > Nicholas Allen for taking their time to go through my
> proposal
> > > to
> > > > > deal
> > > > > > >> with
> > > > > > >> > the aforementioned issue. At the end, we agreed on basically
> > not
> > > > > going
> > > > > > >> with
> > > > > > >> > my temporary solution that intended to solve the related
> > > problems
> > > > of
> > > > > > >> > Pikaday and we'd rather like to find and change for a better
> > > > > > >> alternative.
> > > > > > >> >
> > > > > > >> > To be fair, Pikaday is a pretty good date picker module, its
> > > only
> > > > > > >> problem
> > > > > > >> > is the moment dependency if it's installed via npm. But
> other
> > > than
> > > > > > >> that, it
> > > > > > >> > functions perfectly. Zero dependencies, small, etc. Long
> story
> > > > > short,
> > > > > > >> it's
> > > > > > >> > good for us unless we want to get rid of moment.js.
> > > > > > >> >
> > > > > > >> > 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?
> > > > > > >> >
> > > > > > >> > I'm asking it because if we want to do so, considering that
> > > it's a
> > > > > > huge
> > > > > > >> > topic, the following questions might come up:
> > > > > > >> >
> > > > > > >> > *A: What component do we want to use instead of Pikaday?*
> > > > > > >> >
> > > > > > >> > 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
> > > > > > >> > <https://ng-bootstrap.github.io/#/home> or the angular
> > material
> > > > > > library
> > > > > > >> > <https://material.angular.io/>. Both of them have a date
> > picker
> > > > > > >> component
> > > > > > >> > and many other components to rely on and reuse throughout
> the
> > > > Metron
> > > > > > >> app.
> > > > > > >> >
> > > > > > >> > *B: What component library do we want to use?*
> > > > > > >> >
> > > > > > >> > Introducing a new component library requires a lot of
> research
> > > and
> > > > > > there
> > > > > > >> > are many things we have to agreed on. Since it's a long term
> > > plan
> > > > > > >> because
> > > > > > >> > it would be great to use it consistently instead of picking
> a
> > > new
> > > > > one
> > > > > > a
> > > > > > >> few
> > > > > > >> > months later just because we chose wrongly.
> > > > > > >> >
> > > > > > >> > *C: What about the jQuery version of Bootstrap?*
> > > > > > >> >
> > > > > > >> > So basically we already have a component library and we
> still
> > > use
> > > > it
> > > > > > but
> > > > > > >> > we're also planning to replace it with another or the
> angular
> > > port
> > > > > at
> > > > > > >> least
> > > > > > >> > to get the most out of the angular rendering engine. Since
> it
> > > uses
> > > > > > >> jquery,
> > > > > > >> > it's much less performant than a port written in Angular.
> > > > > > >> > And I think it's a bad idea to introduce a new one and use
> > > > multiple
> > > > > > >> > component libraries within one project.
> > > > > > >> > We can also pick the date picker component from the jQuery
> > > > Bootstrap
> > > > > > >> but,
> > > > > > >> > again, it's not as efficient as the angular port so it seems
> > to
> > > be
> > > > > > >> > beneficial to replace it with something else.
> > > > > > >> >
> > > > > > >> > What do you think, guys?
> > > > > > >> >
> > > > > > >> > Thanks,
> > > > > > >> > Tamas
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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

[Michael Miklavcic <mi...@gmail.com>]

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 make improvements there also. My only
caution would be that there are instances where early architectural
duplication seems wasteful, but is really just a short-term illusion
because of code maturity. ie, there are instances where you absolutely
don't want to tie architectural components together even if it seems like
you're duplicating code. I don't believe this fits that concern, but I
thought it was worth mentioning. To that end, I wouldn't have your progress
on the alerts UI improvements be hampered by the management UI. I think we
can take the lessons learned in the Alerts UI and apply them to the
management UI when it makes sense to.

Best,
Mike


On Tue, Oct 16, 2018 at 2:21 AM Tibor Meller <ti...@gmail.com> wrote:

> 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 see those two UI getting closer to each other
> with the underlying technologies instead of shifting away.
>
> On Tue, Oct 16, 2018 at 9:37 AM Tamás Fodor <ft...@gmail.com> wrote:
>
> > I'm agreeing with moving forward with Ng Bootstrap. In order to do that,
> I
> > think it would be a good start to refactor those components which use the
> > obsolete jquery based vesrion of bootstrap. Shane has already started it
> by
> > refactoring the Modal dialog in the management UI (We also have this
> > component in the alerts UI). Once we've succeeded that, we can remove
> > (hopefully) jQuery form the dependency list.
> > As the second step, we should migrate to Ng bootstrap. I'm assuming that
> if
> > the jquery based Boostrap is replaced with Ng bootstrap, we're still good
> > since we're using only classes from the bootstrap CSS which is shared
> > across jQuery bootstrap and Ng bootstrap.
> > If everything is good and nothing is broken we can start working on the
> new
> > date/time picker component based on Ng bootstrap and then we can get rid
> of
> > Pikaday.
> > Once Pikaday is completely eliminated from the system, we can be sure
> that
> > the PR about eliminating moment.js is ready to go.
> >
> > Cheers,
> > Tamas
> >
> > On Mon, Oct 15, 2018 at 8:36 PM Michael Miklavcic <
> > michael.miklavcic@gmail.com> wrote:
> >
> > > 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 Tibor, is there any reason we
> > > wouldn't want to move forward with the Angular port of Bootstrap, NG
> > > Bootstrap? Per your arguments for it, this sounds like the right path
> > > forward to me. I'm +1 on this approach provided someone doesn't come
> back
> > > with a "well, there's only this problem..."
> > >
> > > Best,
> > > Mike
> > >
> > > On Mon, Oct 15, 2018 at 7:39 AM Shane Ardell <shane.m.ardell@gmail.com
> >
> > > wrote:
> > >
> > > > We are definitely on the same page.
> > > >
> > > > On Mon, Oct 15, 2018 at 2:06 PM Tibor Meller <tibor.meller@gmail.com
> >
> > > > wrote:
> > > >
> > > > > @Shane It seems like we're agreed on this. :D
> > > > >
> > > > > On Mon, Oct 15, 2018 at 1:18 PM Tibor Meller <
> tibor.meller@gmail.com
> > >
> > > > > 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 eliminate jQuery from the code base
> > > > > > Currently, we're using bootstrap but an implementation based on
> > > jQuery.
> > > > > > Angular and jQuery doesn't build to live together.
> > > > > > 2. NgBootstrap made to being used with Angular
> > > > > > It uses Angular instead of hacking the rendering/dom manipulation
> > > with
> > > > > > jQuery.
> > > > > > 3. It contains a date and a time picker.
> > > > > > It's easy to combine to a datetime picker.
> > > > > > 4. No dependencies.
> > > > > > By changing currently used bootstrap to NgBootstrap we could
> clear
> > > > > jquery,
> > > > > > moment, pickaday, pickaday-time libraries from our dependencies.
> > > > > >
> > > > > > Another huge advantage of NgBootstrap is that we don't have to
> > > rewrite
> > > > > > anything we don't want to. Our UI already uses Bootstrap.
> > > > > >
> > > > > > What do you guys think?
> > > > > >
> > > > > > On Wed, Oct 10, 2018 at 4:19 PM Nick Allen <ni...@nickallen.org>
> > > wrote:
> > > > > >
> > > > > >> > 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 too.  We
> need
> > > to
> > > > > make
> > > > > >> a conscious effort to identify libraries that we are using that
> > are
> > > > > >> deprecated, lack community support, and are unlikely to be
> > > maintained
> > > > > and
> > > > > >> updated for security vulnerabilities.  We need to actively
> > identify
> > > > and
> > > > > >> replace those.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <
> > ftamas.mail@gmail.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > 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
> > > > > >> >
> > > > > >> >
> > https://github.com/apache/metron/pull/1219#discussion_r223733562
> > > > > >> >
> > > > > >> > A week ago, I opened a PR about removing moment.js from the
> code
> > > > base
> > > > > to
> > > > > >> > decrease the size of the production javascript bundle. I could
> > > > achieve
> > > > > >> 15%
> > > > > >> > loss in the final bundle size which is admittedly not a game
> > > changer
> > > > > but
> > > > > >> > still. Not to mention if we want to heavily rely on date
> > > manipulator
> > > > > >> > functions in the future it's better to get rid of it at this
> > early
> > > > > >> stage.
> > > > > >> > Go here <https://github.com/apache/metron/pull/1219> to read
> > more
> > > > > about
> > > > > >> > the
> > > > > >> > background and the results. I tried to provide as many details
> > as
> > > I
> > > > > >> could.
> > > > > >> >
> > > > > >> > So far, so good. But then I stumbled upon an obstacle, Pikaday
> > > > > >> > <https://github.com/dbushell/Pikaday>.
> > > > > >> >
> > > > > >> > Before going further, let me thank Tibor Meller, Michael
> > Miklavcic
> > > > and
> > > > > >> > Nicholas Allen for taking their time to go through my proposal
> > to
> > > > deal
> > > > > >> with
> > > > > >> > the aforementioned issue. At the end, we agreed on basically
> not
> > > > going
> > > > > >> with
> > > > > >> > my temporary solution that intended to solve the related
> > problems
> > > of
> > > > > >> > Pikaday and we'd rather like to find and change for a better
> > > > > >> alternative.
> > > > > >> >
> > > > > >> > To be fair, Pikaday is a pretty good date picker module, its
> > only
> > > > > >> problem
> > > > > >> > is the moment dependency if it's installed via npm. But other
> > than
> > > > > >> that, it
> > > > > >> > functions perfectly. Zero dependencies, small, etc. Long story
> > > > short,
> > > > > >> it's
> > > > > >> > good for us unless we want to get rid of moment.js.
> > > > > >> >
> > > > > >> > 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?
> > > > > >> >
> > > > > >> > I'm asking it because if we want to do so, considering that
> > it's a
> > > > > huge
> > > > > >> > topic, the following questions might come up:
> > > > > >> >
> > > > > >> > *A: What component do we want to use instead of Pikaday?*
> > > > > >> >
> > > > > >> > 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
> > > > > >> > <https://ng-bootstrap.github.io/#/home> or the angular
> material
> > > > > library
> > > > > >> > <https://material.angular.io/>. Both of them have a date
> picker
> > > > > >> component
> > > > > >> > and many other components to rely on and reuse throughout the
> > > Metron
> > > > > >> app.
> > > > > >> >
> > > > > >> > *B: What component library do we want to use?*
> > > > > >> >
> > > > > >> > Introducing a new component library requires a lot of research
> > and
> > > > > there
> > > > > >> > are many things we have to agreed on. Since it's a long term
> > plan
> > > > > >> because
> > > > > >> > it would be great to use it consistently instead of picking a
> > new
> > > > one
> > > > > a
> > > > > >> few
> > > > > >> > months later just because we chose wrongly.
> > > > > >> >
> > > > > >> > *C: What about the jQuery version of Bootstrap?*
> > > > > >> >
> > > > > >> > So basically we already have a component library and we still
> > use
> > > it
> > > > > but
> > > > > >> > we're also planning to replace it with another or the angular
> > port
> > > > at
> > > > > >> least
> > > > > >> > to get the most out of the angular rendering engine. Since it
> > uses
> > > > > >> jquery,
> > > > > >> > it's much less performant than a port written in Angular.
> > > > > >> > And I think it's a bad idea to introduce a new one and use
> > > multiple
> > > > > >> > component libraries within one project.
> > > > > >> > We can also pick the date picker component from the jQuery
> > > Bootstrap
> > > > > >> but,
> > > > > >> > again, it's not as efficient as the angular port so it seems
> to
> > be
> > > > > >> > beneficial to replace it with something else.
> > > > > >> >
> > > > > >> > What do you think, guys?
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Tamas
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

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

[Tibor Meller <ti...@gmail.com>]

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 see those two UI getting closer to each other
with the underlying technologies instead of shifting away.

On Tue, Oct 16, 2018 at 9:37 AM Tamás Fodor <ft...@gmail.com> wrote:

> I'm agreeing with moving forward with Ng Bootstrap. In order to do that, I
> think it would be a good start to refactor those components which use the
> obsolete jquery based vesrion of bootstrap. Shane has already started it by
> refactoring the Modal dialog in the management UI (We also have this
> component in the alerts UI). Once we've succeeded that, we can remove
> (hopefully) jQuery form the dependency list.
> As the second step, we should migrate to Ng bootstrap. I'm assuming that if
> the jquery based Boostrap is replaced with Ng bootstrap, we're still good
> since we're using only classes from the bootstrap CSS which is shared
> across jQuery bootstrap and Ng bootstrap.
> If everything is good and nothing is broken we can start working on the new
> date/time picker component based on Ng bootstrap and then we can get rid of
> Pikaday.
> Once Pikaday is completely eliminated from the system, we can be sure that
> the PR about eliminating moment.js is ready to go.
>
> Cheers,
> Tamas
>
> On Mon, Oct 15, 2018 at 8:36 PM Michael Miklavcic <
> michael.miklavcic@gmail.com> wrote:
>
> > 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 Tibor, is there any reason we
> > wouldn't want to move forward with the Angular port of Bootstrap, NG
> > Bootstrap? Per your arguments for it, this sounds like the right path
> > forward to me. I'm +1 on this approach provided someone doesn't come back
> > with a "well, there's only this problem..."
> >
> > Best,
> > Mike
> >
> > On Mon, Oct 15, 2018 at 7:39 AM Shane Ardell <sh...@gmail.com>
> > wrote:
> >
> > > We are definitely on the same page.
> > >
> > > On Mon, Oct 15, 2018 at 2:06 PM Tibor Meller <ti...@gmail.com>
> > > wrote:
> > >
> > > > @Shane It seems like we're agreed on this. :D
> > > >
> > > > On Mon, Oct 15, 2018 at 1:18 PM Tibor Meller <tibor.meller@gmail.com
> >
> > > > 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 eliminate jQuery from the code base
> > > > > Currently, we're using bootstrap but an implementation based on
> > jQuery.
> > > > > Angular and jQuery doesn't build to live together.
> > > > > 2. NgBootstrap made to being used with Angular
> > > > > It uses Angular instead of hacking the rendering/dom manipulation
> > with
> > > > > jQuery.
> > > > > 3. It contains a date and a time picker.
> > > > > It's easy to combine to a datetime picker.
> > > > > 4. No dependencies.
> > > > > By changing currently used bootstrap to NgBootstrap we could clear
> > > > jquery,
> > > > > moment, pickaday, pickaday-time libraries from our dependencies.
> > > > >
> > > > > Another huge advantage of NgBootstrap is that we don't have to
> > rewrite
> > > > > anything we don't want to. Our UI already uses Bootstrap.
> > > > >
> > > > > What do you guys think?
> > > > >
> > > > > On Wed, Oct 10, 2018 at 4:19 PM Nick Allen <ni...@nickallen.org>
> > wrote:
> > > > >
> > > > >> > 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 too.  We need
> > to
> > > > make
> > > > >> a conscious effort to identify libraries that we are using that
> are
> > > > >> deprecated, lack community support, and are unlikely to be
> > maintained
> > > > and
> > > > >> updated for security vulnerabilities.  We need to actively
> identify
> > > and
> > > > >> replace those.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <
> ftamas.mail@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > 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
> > > > >> >
> > > > >> >
> https://github.com/apache/metron/pull/1219#discussion_r223733562
> > > > >> >
> > > > >> > A week ago, I opened a PR about removing moment.js from the code
> > > base
> > > > to
> > > > >> > decrease the size of the production javascript bundle. I could
> > > achieve
> > > > >> 15%
> > > > >> > loss in the final bundle size which is admittedly not a game
> > changer
> > > > but
> > > > >> > still. Not to mention if we want to heavily rely on date
> > manipulator
> > > > >> > functions in the future it's better to get rid of it at this
> early
> > > > >> stage.
> > > > >> > Go here <https://github.com/apache/metron/pull/1219> to read
> more
> > > > about
> > > > >> > the
> > > > >> > background and the results. I tried to provide as many details
> as
> > I
> > > > >> could.
> > > > >> >
> > > > >> > So far, so good. But then I stumbled upon an obstacle, Pikaday
> > > > >> > <https://github.com/dbushell/Pikaday>.
> > > > >> >
> > > > >> > Before going further, let me thank Tibor Meller, Michael
> Miklavcic
> > > and
> > > > >> > Nicholas Allen for taking their time to go through my proposal
> to
> > > deal
> > > > >> with
> > > > >> > the aforementioned issue. At the end, we agreed on basically not
> > > going
> > > > >> with
> > > > >> > my temporary solution that intended to solve the related
> problems
> > of
> > > > >> > Pikaday and we'd rather like to find and change for a better
> > > > >> alternative.
> > > > >> >
> > > > >> > To be fair, Pikaday is a pretty good date picker module, its
> only
> > > > >> problem
> > > > >> > is the moment dependency if it's installed via npm. But other
> than
> > > > >> that, it
> > > > >> > functions perfectly. Zero dependencies, small, etc. Long story
> > > short,
> > > > >> it's
> > > > >> > good for us unless we want to get rid of moment.js.
> > > > >> >
> > > > >> > 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?
> > > > >> >
> > > > >> > I'm asking it because if we want to do so, considering that
> it's a
> > > > huge
> > > > >> > topic, the following questions might come up:
> > > > >> >
> > > > >> > *A: What component do we want to use instead of Pikaday?*
> > > > >> >
> > > > >> > 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
> > > > >> > <https://ng-bootstrap.github.io/#/home> or the angular material
> > > > library
> > > > >> > <https://material.angular.io/>. Both of them have a date picker
> > > > >> component
> > > > >> > and many other components to rely on and reuse throughout the
> > Metron
> > > > >> app.
> > > > >> >
> > > > >> > *B: What component library do we want to use?*
> > > > >> >
> > > > >> > Introducing a new component library requires a lot of research
> and
> > > > there
> > > > >> > are many things we have to agreed on. Since it's a long term
> plan
> > > > >> because
> > > > >> > it would be great to use it consistently instead of picking a
> new
> > > one
> > > > a
> > > > >> few
> > > > >> > months later just because we chose wrongly.
> > > > >> >
> > > > >> > *C: What about the jQuery version of Bootstrap?*
> > > > >> >
> > > > >> > So basically we already have a component library and we still
> use
> > it
> > > > but
> > > > >> > we're also planning to replace it with another or the angular
> port
> > > at
> > > > >> least
> > > > >> > to get the most out of the angular rendering engine. Since it
> uses
> > > > >> jquery,
> > > > >> > it's much less performant than a port written in Angular.
> > > > >> > And I think it's a bad idea to introduce a new one and use
> > multiple
> > > > >> > component libraries within one project.
> > > > >> > We can also pick the date picker component from the jQuery
> > Bootstrap
> > > > >> but,
> > > > >> > again, it's not as efficient as the angular port so it seems to
> be
> > > > >> > beneficial to replace it with something else.
> > > > >> >
> > > > >> > What do you think, guys?
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Tamas
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

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

[Tamás Fodor <ft...@gmail.com>]

I'm agreeing with moving forward with Ng Bootstrap. In order to do that, I
think it would be a good start to refactor those components which use the
obsolete jquery based vesrion of bootstrap. Shane has already started it by
refactoring the Modal dialog in the management UI (We also have this
component in the alerts UI). Once we've succeeded that, we can remove
(hopefully) jQuery form the dependency list.
As the second step, we should migrate to Ng bootstrap. I'm assuming that if
the jquery based Boostrap is replaced with Ng bootstrap, we're still good
since we're using only classes from the bootstrap CSS which is shared
across jQuery bootstrap and Ng bootstrap.
If everything is good and nothing is broken we can start working on the new
date/time picker component based on Ng bootstrap and then we can get rid of
Pikaday.
Once Pikaday is completely eliminated from the system, we can be sure that
the PR about eliminating moment.js is ready to go.

Cheers,
Tamas

On Mon, Oct 15, 2018 at 8:36 PM Michael Miklavcic <
michael.miklavcic@gmail.com> wrote:

> 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 Tibor, is there any reason we
> wouldn't want to move forward with the Angular port of Bootstrap, NG
> Bootstrap? Per your arguments for it, this sounds like the right path
> forward to me. I'm +1 on this approach provided someone doesn't come back
> with a "well, there's only this problem..."
>
> Best,
> Mike
>
> On Mon, Oct 15, 2018 at 7:39 AM Shane Ardell <sh...@gmail.com>
> wrote:
>
> > We are definitely on the same page.
> >
> > On Mon, Oct 15, 2018 at 2:06 PM Tibor Meller <ti...@gmail.com>
> > wrote:
> >
> > > @Shane It seems like we're agreed on this. :D
> > >
> > > On Mon, Oct 15, 2018 at 1:18 PM Tibor Meller <ti...@gmail.com>
> > > 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 eliminate jQuery from the code base
> > > > Currently, we're using bootstrap but an implementation based on
> jQuery.
> > > > Angular and jQuery doesn't build to live together.
> > > > 2. NgBootstrap made to being used with Angular
> > > > It uses Angular instead of hacking the rendering/dom manipulation
> with
> > > > jQuery.
> > > > 3. It contains a date and a time picker.
> > > > It's easy to combine to a datetime picker.
> > > > 4. No dependencies.
> > > > By changing currently used bootstrap to NgBootstrap we could clear
> > > jquery,
> > > > moment, pickaday, pickaday-time libraries from our dependencies.
> > > >
> > > > Another huge advantage of NgBootstrap is that we don't have to
> rewrite
> > > > anything we don't want to. Our UI already uses Bootstrap.
> > > >
> > > > What do you guys think?
> > > >
> > > > On Wed, Oct 10, 2018 at 4:19 PM Nick Allen <ni...@nickallen.org>
> wrote:
> > > >
> > > >> > 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 too.  We need
> to
> > > make
> > > >> a conscious effort to identify libraries that we are using that are
> > > >> deprecated, lack community support, and are unlikely to be
> maintained
> > > and
> > > >> updated for security vulnerabilities.  We need to actively identify
> > and
> > > >> replace those.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <ft...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > 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
> > > >> >
> > > >> > https://github.com/apache/metron/pull/1219#discussion_r223733562
> > > >> >
> > > >> > A week ago, I opened a PR about removing moment.js from the code
> > base
> > > to
> > > >> > decrease the size of the production javascript bundle. I could
> > achieve
> > > >> 15%
> > > >> > loss in the final bundle size which is admittedly not a game
> changer
> > > but
> > > >> > still. Not to mention if we want to heavily rely on date
> manipulator
> > > >> > functions in the future it's better to get rid of it at this early
> > > >> stage.
> > > >> > Go here <https://github.com/apache/metron/pull/1219> to read more
> > > about
> > > >> > the
> > > >> > background and the results. I tried to provide as many details as
> I
> > > >> could.
> > > >> >
> > > >> > So far, so good. But then I stumbled upon an obstacle, Pikaday
> > > >> > <https://github.com/dbushell/Pikaday>.
> > > >> >
> > > >> > Before going further, let me thank Tibor Meller, Michael Miklavcic
> > and
> > > >> > Nicholas Allen for taking their time to go through my proposal to
> > deal
> > > >> with
> > > >> > the aforementioned issue. At the end, we agreed on basically not
> > going
> > > >> with
> > > >> > my temporary solution that intended to solve the related problems
> of
> > > >> > Pikaday and we'd rather like to find and change for a better
> > > >> alternative.
> > > >> >
> > > >> > To be fair, Pikaday is a pretty good date picker module, its only
> > > >> problem
> > > >> > is the moment dependency if it's installed via npm. But other than
> > > >> that, it
> > > >> > functions perfectly. Zero dependencies, small, etc. Long story
> > short,
> > > >> it's
> > > >> > good for us unless we want to get rid of moment.js.
> > > >> >
> > > >> > 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?
> > > >> >
> > > >> > I'm asking it because if we want to do so, considering that it's a
> > > huge
> > > >> > topic, the following questions might come up:
> > > >> >
> > > >> > *A: What component do we want to use instead of Pikaday?*
> > > >> >
> > > >> > 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
> > > >> > <https://ng-bootstrap.github.io/#/home> or the angular material
> > > library
> > > >> > <https://material.angular.io/>. Both of them have a date picker
> > > >> component
> > > >> > and many other components to rely on and reuse throughout the
> Metron
> > > >> app.
> > > >> >
> > > >> > *B: What component library do we want to use?*
> > > >> >
> > > >> > Introducing a new component library requires a lot of research and
> > > there
> > > >> > are many things we have to agreed on. Since it's a long term plan
> > > >> because
> > > >> > it would be great to use it consistently instead of picking a new
> > one
> > > a
> > > >> few
> > > >> > months later just because we chose wrongly.
> > > >> >
> > > >> > *C: What about the jQuery version of Bootstrap?*
> > > >> >
> > > >> > So basically we already have a component library and we still use
> it
> > > but
> > > >> > we're also planning to replace it with another or the angular port
> > at
> > > >> least
> > > >> > to get the most out of the angular rendering engine. Since it uses
> > > >> jquery,
> > > >> > it's much less performant than a port written in Angular.
> > > >> > And I think it's a bad idea to introduce a new one and use
> multiple
> > > >> > component libraries within one project.
> > > >> > We can also pick the date picker component from the jQuery
> Bootstrap
> > > >> but,
> > > >> > again, it's not as efficient as the angular port so it seems to be
> > > >> > beneficial to replace it with something else.
> > > >> >
> > > >> > What do you think, guys?
> > > >> >
> > > >> > Thanks,
> > > >> > Tamas
> > > >> >
> > > >>
> > > >
> > >
> >
>

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

[Michael Miklavcic <mi...@gmail.com>]

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 Tibor, is there any reason we
wouldn't want to move forward with the Angular port of Bootstrap, NG
Bootstrap? Per your arguments for it, this sounds like the right path
forward to me. I'm +1 on this approach provided someone doesn't come back
with a "well, there's only this problem..."

Best,
Mike

On Mon, Oct 15, 2018 at 7:39 AM Shane Ardell <sh...@gmail.com>
wrote:

> We are definitely on the same page.
>
> On Mon, Oct 15, 2018 at 2:06 PM Tibor Meller <ti...@gmail.com>
> wrote:
>
> > @Shane It seems like we're agreed on this. :D
> >
> > On Mon, Oct 15, 2018 at 1:18 PM Tibor Meller <ti...@gmail.com>
> > 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 eliminate jQuery from the code base
> > > Currently, we're using bootstrap but an implementation based on jQuery.
> > > Angular and jQuery doesn't build to live together.
> > > 2. NgBootstrap made to being used with Angular
> > > It uses Angular instead of hacking the rendering/dom manipulation with
> > > jQuery.
> > > 3. It contains a date and a time picker.
> > > It's easy to combine to a datetime picker.
> > > 4. No dependencies.
> > > By changing currently used bootstrap to NgBootstrap we could clear
> > jquery,
> > > moment, pickaday, pickaday-time libraries from our dependencies.
> > >
> > > Another huge advantage of NgBootstrap is that we don't have to rewrite
> > > anything we don't want to. Our UI already uses Bootstrap.
> > >
> > > What do you guys think?
> > >
> > > On Wed, Oct 10, 2018 at 4:19 PM Nick Allen <ni...@nickallen.org> wrote:
> > >
> > >> > 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 too.  We need to
> > make
> > >> a conscious effort to identify libraries that we are using that are
> > >> deprecated, lack community support, and are unlikely to be maintained
> > and
> > >> updated for security vulnerabilities.  We need to actively identify
> and
> > >> replace those.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <ft...@gmail.com>
> > >> wrote:
> > >>
> > >> > 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
> > >> >
> > >> > https://github.com/apache/metron/pull/1219#discussion_r223733562
> > >> >
> > >> > A week ago, I opened a PR about removing moment.js from the code
> base
> > to
> > >> > decrease the size of the production javascript bundle. I could
> achieve
> > >> 15%
> > >> > loss in the final bundle size which is admittedly not a game changer
> > but
> > >> > still. Not to mention if we want to heavily rely on date manipulator
> > >> > functions in the future it's better to get rid of it at this early
> > >> stage.
> > >> > Go here <https://github.com/apache/metron/pull/1219> to read more
> > about
> > >> > the
> > >> > background and the results. I tried to provide as many details as I
> > >> could.
> > >> >
> > >> > So far, so good. But then I stumbled upon an obstacle, Pikaday
> > >> > <https://github.com/dbushell/Pikaday>.
> > >> >
> > >> > Before going further, let me thank Tibor Meller, Michael Miklavcic
> and
> > >> > Nicholas Allen for taking their time to go through my proposal to
> deal
> > >> with
> > >> > the aforementioned issue. At the end, we agreed on basically not
> going
> > >> with
> > >> > my temporary solution that intended to solve the related problems of
> > >> > Pikaday and we'd rather like to find and change for a better
> > >> alternative.
> > >> >
> > >> > To be fair, Pikaday is a pretty good date picker module, its only
> > >> problem
> > >> > is the moment dependency if it's installed via npm. But other than
> > >> that, it
> > >> > functions perfectly. Zero dependencies, small, etc. Long story
> short,
> > >> it's
> > >> > good for us unless we want to get rid of moment.js.
> > >> >
> > >> > 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?
> > >> >
> > >> > I'm asking it because if we want to do so, considering that it's a
> > huge
> > >> > topic, the following questions might come up:
> > >> >
> > >> > *A: What component do we want to use instead of Pikaday?*
> > >> >
> > >> > 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
> > >> > <https://ng-bootstrap.github.io/#/home> or the angular material
> > library
> > >> > <https://material.angular.io/>. Both of them have a date picker
> > >> component
> > >> > and many other components to rely on and reuse throughout the Metron
> > >> app.
> > >> >
> > >> > *B: What component library do we want to use?*
> > >> >
> > >> > Introducing a new component library requires a lot of research and
> > there
> > >> > are many things we have to agreed on. Since it's a long term plan
> > >> because
> > >> > it would be great to use it consistently instead of picking a new
> one
> > a
> > >> few
> > >> > months later just because we chose wrongly.
> > >> >
> > >> > *C: What about the jQuery version of Bootstrap?*
> > >> >
> > >> > So basically we already have a component library and we still use it
> > but
> > >> > we're also planning to replace it with another or the angular port
> at
> > >> least
> > >> > to get the most out of the angular rendering engine. Since it uses
> > >> jquery,
> > >> > it's much less performant than a port written in Angular.
> > >> > And I think it's a bad idea to introduce a new one and use multiple
> > >> > component libraries within one project.
> > >> > We can also pick the date picker component from the jQuery Bootstrap
> > >> but,
> > >> > again, it's not as efficient as the angular port so it seems to be
> > >> > beneficial to replace it with something else.
> > >> >
> > >> > What do you think, guys?
> > >> >
> > >> > Thanks,
> > >> > Tamas
> > >> >
> > >>
> > >
> >
>

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

[Shane Ardell <sh...@gmail.com>]

We are definitely on the same page.

On Mon, Oct 15, 2018 at 2:06 PM Tibor Meller <ti...@gmail.com> wrote:

> @Shane It seems like we're agreed on this. :D
>
> On Mon, Oct 15, 2018 at 1:18 PM Tibor Meller <ti...@gmail.com>
> 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 eliminate jQuery from the code base
> > Currently, we're using bootstrap but an implementation based on jQuery.
> > Angular and jQuery doesn't build to live together.
> > 2. NgBootstrap made to being used with Angular
> > It uses Angular instead of hacking the rendering/dom manipulation with
> > jQuery.
> > 3. It contains a date and a time picker.
> > It's easy to combine to a datetime picker.
> > 4. No dependencies.
> > By changing currently used bootstrap to NgBootstrap we could clear
> jquery,
> > moment, pickaday, pickaday-time libraries from our dependencies.
> >
> > Another huge advantage of NgBootstrap is that we don't have to rewrite
> > anything we don't want to. Our UI already uses Bootstrap.
> >
> > What do you guys think?
> >
> > On Wed, Oct 10, 2018 at 4:19 PM Nick Allen <ni...@nickallen.org> wrote:
> >
> >> > 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 too.  We need to
> make
> >> a conscious effort to identify libraries that we are using that are
> >> deprecated, lack community support, and are unlikely to be maintained
> and
> >> updated for security vulnerabilities.  We need to actively identify and
> >> replace those.
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <ft...@gmail.com>
> >> wrote:
> >>
> >> > 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
> >> >
> >> > https://github.com/apache/metron/pull/1219#discussion_r223733562
> >> >
> >> > A week ago, I opened a PR about removing moment.js from the code base
> to
> >> > decrease the size of the production javascript bundle. I could achieve
> >> 15%
> >> > loss in the final bundle size which is admittedly not a game changer
> but
> >> > still. Not to mention if we want to heavily rely on date manipulator
> >> > functions in the future it's better to get rid of it at this early
> >> stage.
> >> > Go here <https://github.com/apache/metron/pull/1219> to read more
> about
> >> > the
> >> > background and the results. I tried to provide as many details as I
> >> could.
> >> >
> >> > So far, so good. But then I stumbled upon an obstacle, Pikaday
> >> > <https://github.com/dbushell/Pikaday>.
> >> >
> >> > Before going further, let me thank Tibor Meller, Michael Miklavcic and
> >> > Nicholas Allen for taking their time to go through my proposal to deal
> >> with
> >> > the aforementioned issue. At the end, we agreed on basically not going
> >> with
> >> > my temporary solution that intended to solve the related problems of
> >> > Pikaday and we'd rather like to find and change for a better
> >> alternative.
> >> >
> >> > To be fair, Pikaday is a pretty good date picker module, its only
> >> problem
> >> > is the moment dependency if it's installed via npm. But other than
> >> that, it
> >> > functions perfectly. Zero dependencies, small, etc. Long story short,
> >> it's
> >> > good for us unless we want to get rid of moment.js.
> >> >
> >> > 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?
> >> >
> >> > I'm asking it because if we want to do so, considering that it's a
> huge
> >> > topic, the following questions might come up:
> >> >
> >> > *A: What component do we want to use instead of Pikaday?*
> >> >
> >> > 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
> >> > <https://ng-bootstrap.github.io/#/home> or the angular material
> library
> >> > <https://material.angular.io/>. Both of them have a date picker
> >> component
> >> > and many other components to rely on and reuse throughout the Metron
> >> app.
> >> >
> >> > *B: What component library do we want to use?*
> >> >
> >> > Introducing a new component library requires a lot of research and
> there
> >> > are many things we have to agreed on. Since it's a long term plan
> >> because
> >> > it would be great to use it consistently instead of picking a new one
> a
> >> few
> >> > months later just because we chose wrongly.
> >> >
> >> > *C: What about the jQuery version of Bootstrap?*
> >> >
> >> > So basically we already have a component library and we still use it
> but
> >> > we're also planning to replace it with another or the angular port at
> >> least
> >> > to get the most out of the angular rendering engine. Since it uses
> >> jquery,
> >> > it's much less performant than a port written in Angular.
> >> > And I think it's a bad idea to introduce a new one and use multiple
> >> > component libraries within one project.
> >> > We can also pick the date picker component from the jQuery Bootstrap
> >> but,
> >> > again, it's not as efficient as the angular port so it seems to be
> >> > beneficial to replace it with something else.
> >> >
> >> > What do you think, guys?
> >> >
> >> > Thanks,
> >> > Tamas
> >> >
> >>
> >
>

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

[Tibor Meller <ti...@gmail.com>]

@Shane It seems like we're agreed on this. :D

On Mon, Oct 15, 2018 at 1:18 PM Tibor Meller <ti...@gmail.com> 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 eliminate jQuery from the code base
> Currently, we're using bootstrap but an implementation based on jQuery.
> Angular and jQuery doesn't build to live together.
> 2. NgBootstrap made to being used with Angular
> It uses Angular instead of hacking the rendering/dom manipulation with
> jQuery.
> 3. It contains a date and a time picker.
> It's easy to combine to a datetime picker.
> 4. No dependencies.
> By changing currently used bootstrap to NgBootstrap we could clear jquery,
> moment, pickaday, pickaday-time libraries from our dependencies.
>
> Another huge advantage of NgBootstrap is that we don't have to rewrite
> anything we don't want to. Our UI already uses Bootstrap.
>
> What do you guys think?
>
> On Wed, Oct 10, 2018 at 4:19 PM Nick Allen <ni...@nickallen.org> wrote:
>
>> > 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 too.  We need to make
>> a conscious effort to identify libraries that we are using that are
>> deprecated, lack community support, and are unlikely to be maintained and
>> updated for security vulnerabilities.  We need to actively identify and
>> replace those.
>>
>>
>>
>>
>>
>> On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <ft...@gmail.com>
>> wrote:
>>
>> > 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
>> >
>> > https://github.com/apache/metron/pull/1219#discussion_r223733562
>> >
>> > A week ago, I opened a PR about removing moment.js from the code base to
>> > decrease the size of the production javascript bundle. I could achieve
>> 15%
>> > loss in the final bundle size which is admittedly not a game changer but
>> > still. Not to mention if we want to heavily rely on date manipulator
>> > functions in the future it's better to get rid of it at this early
>> stage.
>> > Go here <https://github.com/apache/metron/pull/1219> to read more about
>> > the
>> > background and the results. I tried to provide as many details as I
>> could.
>> >
>> > So far, so good. But then I stumbled upon an obstacle, Pikaday
>> > <https://github.com/dbushell/Pikaday>.
>> >
>> > Before going further, let me thank Tibor Meller, Michael Miklavcic and
>> > Nicholas Allen for taking their time to go through my proposal to deal
>> with
>> > the aforementioned issue. At the end, we agreed on basically not going
>> with
>> > my temporary solution that intended to solve the related problems of
>> > Pikaday and we'd rather like to find and change for a better
>> alternative.
>> >
>> > To be fair, Pikaday is a pretty good date picker module, its only
>> problem
>> > is the moment dependency if it's installed via npm. But other than
>> that, it
>> > functions perfectly. Zero dependencies, small, etc. Long story short,
>> it's
>> > good for us unless we want to get rid of moment.js.
>> >
>> > 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?
>> >
>> > I'm asking it because if we want to do so, considering that it's a huge
>> > topic, the following questions might come up:
>> >
>> > *A: What component do we want to use instead of Pikaday?*
>> >
>> > 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
>> > <https://ng-bootstrap.github.io/#/home> or the angular material library
>> > <https://material.angular.io/>. Both of them have a date picker
>> component
>> > and many other components to rely on and reuse throughout the Metron
>> app.
>> >
>> > *B: What component library do we want to use?*
>> >
>> > Introducing a new component library requires a lot of research and there
>> > are many things we have to agreed on. Since it's a long term plan
>> because
>> > it would be great to use it consistently instead of picking a new one a
>> few
>> > months later just because we chose wrongly.
>> >
>> > *C: What about the jQuery version of Bootstrap?*
>> >
>> > So basically we already have a component library and we still use it but
>> > we're also planning to replace it with another or the angular port at
>> least
>> > to get the most out of the angular rendering engine. Since it uses
>> jquery,
>> > it's much less performant than a port written in Angular.
>> > And I think it's a bad idea to introduce a new one and use multiple
>> > component libraries within one project.
>> > We can also pick the date picker component from the jQuery Bootstrap
>> but,
>> > again, it's not as efficient as the angular port so it seems to be
>> > beneficial to replace it with something else.
>> >
>> > What do you think, guys?
>> >
>> > Thanks,
>> > Tamas
>> >
>>
>

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

[Tibor Meller <ti...@gmail.com>]

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.
Angular and jQuery doesn't build to live together.
2. NgBootstrap made to being used with Angular
It uses Angular instead of hacking the rendering/dom manipulation with
jQuery.
3. It contains a date and a time picker.
It's easy to combine to a datetime picker.
4. No dependencies.
By changing currently used bootstrap to NgBootstrap we could clear jquery,
moment, pickaday, pickaday-time libraries from our dependencies.

Another huge advantage of NgBootstrap is that we don't have to rewrite
anything we don't want to. Our UI already uses Bootstrap.

What do you guys think?

On Wed, Oct 10, 2018 at 4:19 PM Nick Allen <ni...@nickallen.org> wrote:

> > 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 too.  We need to make
> a conscious effort to identify libraries that we are using that are
> deprecated, lack community support, and are unlikely to be maintained and
> updated for security vulnerabilities.  We need to actively identify and
> replace those.
>
>
>
>
>
> On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <ft...@gmail.com> wrote:
>
> > 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
> >
> > https://github.com/apache/metron/pull/1219#discussion_r223733562
> >
> > A week ago, I opened a PR about removing moment.js from the code base to
> > decrease the size of the production javascript bundle. I could achieve
> 15%
> > loss in the final bundle size which is admittedly not a game changer but
> > still. Not to mention if we want to heavily rely on date manipulator
> > functions in the future it's better to get rid of it at this early stage.
> > Go here <https://github.com/apache/metron/pull/1219> to read more about
> > the
> > background and the results. I tried to provide as many details as I
> could.
> >
> > So far, so good. But then I stumbled upon an obstacle, Pikaday
> > <https://github.com/dbushell/Pikaday>.
> >
> > Before going further, let me thank Tibor Meller, Michael Miklavcic and
> > Nicholas Allen for taking their time to go through my proposal to deal
> with
> > the aforementioned issue. At the end, we agreed on basically not going
> with
> > my temporary solution that intended to solve the related problems of
> > Pikaday and we'd rather like to find and change for a better alternative.
> >
> > To be fair, Pikaday is a pretty good date picker module, its only problem
> > is the moment dependency if it's installed via npm. But other than that,
> it
> > functions perfectly. Zero dependencies, small, etc. Long story short,
> it's
> > good for us unless we want to get rid of moment.js.
> >
> > 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?
> >
> > I'm asking it because if we want to do so, considering that it's a huge
> > topic, the following questions might come up:
> >
> > *A: What component do we want to use instead of Pikaday?*
> >
> > 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
> > <https://ng-bootstrap.github.io/#/home> or the angular material library
> > <https://material.angular.io/>. Both of them have a date picker
> component
> > and many other components to rely on and reuse throughout the Metron app.
> >
> > *B: What component library do we want to use?*
> >
> > Introducing a new component library requires a lot of research and there
> > are many things we have to agreed on. Since it's a long term plan because
> > it would be great to use it consistently instead of picking a new one a
> few
> > months later just because we chose wrongly.
> >
> > *C: What about the jQuery version of Bootstrap?*
> >
> > So basically we already have a component library and we still use it but
> > we're also planning to replace it with another or the angular port at
> least
> > to get the most out of the angular rendering engine. Since it uses
> jquery,
> > it's much less performant than a port written in Angular.
> > And I think it's a bad idea to introduce a new one and use multiple
> > component libraries within one project.
> > We can also pick the date picker component from the jQuery Bootstrap but,
> > again, it's not as efficient as the angular port so it seems to be
> > beneficial to replace it with something else.
> >
> > What do you think, guys?
> >
> > Thanks,
> > Tamas
> >
>

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

[Shane Ardell <sh...@gmail.com>]

>
> 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
> <https://ng-bootstrap.github.io/#/home> or the angular material library
> <https://material.angular.io/>. Both of them have a date picker component
> and many other components to rely on and reuse throughout the Metron app.


I’m really glad you brought this up. We currently include the entire
jQuery-based version of Bootstrap in our project, yet we are only really
taking advantage of component styling. The few places where we are using
Bootstrap component's for their javascript behavior, we aren't using them
in the "Angular way". For example, we currently do direct DOM manipulations
with jQuery inside the dialog box class instead of using Angular’s built-in
tooling
<https://github.com/apache/metron/blob/master/metron-interface/metron-alerts/src/app/shared/metron-dialog-box.ts>.
In my opinion, we are unnecessarily increasing our bundle size with a
dependency we don't really need, which is also susceptible to security
vulnerabilities in the future.

If we switch to using Ng Bootstrap, there are a few advantages:
1. As mentioned, we could remove moment.js as a dependency by using Ng
Bootstrap's datepicker instead of Pickaday.
2. We could remove jQuery as a dependency.
3. We import only the components we need vs importing the entire compiled
Bootstrap library.
4. We get to take advantage of Angular's rendering engine when using
components from said library.

I don't mean to hijack this discussion thread, but I felt it was worth
pointing out the other advantages and reasons for switching to a library
like Ng Bootstrap.


On Wed, Oct 10, 2018 at 4:19 PM Nick Allen <ni...@nickallen.org> wrote:
>
> > 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 too.  We need to make
> a conscious effort to identify libraries that we are using that are
> deprecated, lack community support, and are unlikely to be maintained and
> updated for security vulnerabilities.  We need to actively identify and
> replace those.
>
>
>
>
>
> On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <ft...@gmail.com> wrote:
>
> > 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
> >
> > https://github.com/apache/metron/pull/1219#discussion_r223733562
> >
> > A week ago, I opened a PR about removing moment.js from the code base to
> > decrease the size of the production javascript bundle. I could achieve
15%
> > loss in the final bundle size which is admittedly not a game changer but
> > still. Not to mention if we want to heavily rely on date manipulator
> > functions in the future it's better to get rid of it at this early
stage.
> > Go here <https://github.com/apache/metron/pull/1219> to read more about
> > the
> > background and the results. I tried to provide as many details as I
could.
> >
> > So far, so good. But then I stumbled upon an obstacle, Pikaday
> > <https://github.com/dbushell/Pikaday>.
> >
> > Before going further, let me thank Tibor Meller, Michael Miklavcic and
> > Nicholas Allen for taking their time to go through my proposal to deal
with
> > the aforementioned issue. At the end, we agreed on basically not going
with
> > my temporary solution that intended to solve the related problems of
> > Pikaday and we'd rather like to find and change for a better
alternative.
> >
> > To be fair, Pikaday is a pretty good date picker module, its only
problem
> > is the moment dependency if it's installed via npm. But other than
that, it
> > functions perfectly. Zero dependencies, small, etc. Long story short,
it's
> > good for us unless we want to get rid of moment.js.
> >
> > 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?
> >
> > I'm asking it because if we want to do so, considering that it's a huge
> > topic, the following questions might come up:
> >
> > *A: What component do we want to use instead of Pikaday?*
> >
> > 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
> > <https://ng-bootstrap.github.io/#/home> or the angular material library
> > <https://material.angular.io/>. Both of them have a date picker
component
> > and many other components to rely on and reuse throughout the Metron
app.
> >
> > *B: What component library do we want to use?*
> >
> > Introducing a new component library requires a lot of research and there
> > are many things we have to agreed on. Since it's a long term plan
because
> > it would be great to use it consistently instead of picking a new one a
few
> > months later just because we chose wrongly.
> >
> > *C: What about the jQuery version of Bootstrap?*
> >
> > So basically we already have a component library and we still use it but
> > we're also planning to replace it with another or the angular port at
least
> > to get the most out of the angular rendering engine. Since it uses
jquery,
> > it's much less performant than a port written in Angular.
> > And I think it's a bad idea to introduce a new one and use multiple
> > component libraries within one project.
> > We can also pick the date picker component from the jQuery Bootstrap
but,
> > again, it's not as efficient as the angular port so it seems to be
> > beneficial to replace it with something else.
> >
> > What do you think, guys?
> >
> > Thanks,
> > Tamas
> >

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

[Nick Allen <ni...@nickallen.org>]

> 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 too.  We need to make
a conscious effort to identify libraries that we are using that are
deprecated, lack community support, and are unlikely to be maintained and
updated for security vulnerabilities.  We need to actively identify and
replace those.





On Wed, Oct 10, 2018 at 9:33 AM Tamás Fodor <ft...@gmail.com> wrote:

> 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
>
> https://github.com/apache/metron/pull/1219#discussion_r223733562
>
> A week ago, I opened a PR about removing moment.js from the code base to
> decrease the size of the production javascript bundle. I could achieve 15%
> loss in the final bundle size which is admittedly not a game changer but
> still. Not to mention if we want to heavily rely on date manipulator
> functions in the future it's better to get rid of it at this early stage.
> Go here <https://github.com/apache/metron/pull/1219> to read more about
> the
> background and the results. I tried to provide as many details as I could.
>
> So far, so good. But then I stumbled upon an obstacle, Pikaday
> <https://github.com/dbushell/Pikaday>.
>
> Before going further, let me thank Tibor Meller, Michael Miklavcic and
> Nicholas Allen for taking their time to go through my proposal to deal with
> the aforementioned issue. At the end, we agreed on basically not going with
> my temporary solution that intended to solve the related problems of
> Pikaday and we'd rather like to find and change for a better alternative.
>
> To be fair, Pikaday is a pretty good date picker module, its only problem
> is the moment dependency if it's installed via npm. But other than that, it
> functions perfectly. Zero dependencies, small, etc. Long story short, it's
> good for us unless we want to get rid of moment.js.
>
> 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?
>
> I'm asking it because if we want to do so, considering that it's a huge
> topic, the following questions might come up:
>
> *A: What component do we want to use instead of Pikaday?*
>
> 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
> <https://ng-bootstrap.github.io/#/home> or the angular material library
> <https://material.angular.io/>. Both of them have a date picker component
> and many other components to rely on and reuse throughout the Metron app.
>
> *B: What component library do we want to use?*
>
> Introducing a new component library requires a lot of research and there
> are many things we have to agreed on. Since it's a long term plan because
> it would be great to use it consistently instead of picking a new one a few
> months later just because we chose wrongly.
>
> *C: What about the jQuery version of Bootstrap?*
>
> So basically we already have a component library and we still use it but
> we're also planning to replace it with another or the angular port at least
> to get the most out of the angular rendering engine. Since it uses jquery,
> it's much less performant than a port written in Angular.
> And I think it's a bad idea to introduce a new one and use multiple
> component libraries within one project.
> We can also pick the date picker component from the jQuery Bootstrap but,
> again, it's not as efficient as the angular port so it seems to be
> beneficial to replace it with something else.
>
> What do you think, guys?
>
> Thanks,
> Tamas
>