metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Ardell <shane.m.ard...@gmail.com>
Subject Re: [DISCUSS] Switching to a better alternative of Pikaday.js
Date Mon, 15 Oct 2018 11:00:21 GMT
>
> 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 <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
> >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message