metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamás Fodor <>
Subject [DISCUSS] Switching to a better alternative of Pikaday.js
Date Wed, 10 Oct 2018 13:33:03 GMT
I'd like to open a discussion about switching to a new date picker library
in the Metron Alerts UI regarding to the following:

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 <> 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

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
<> or the angular material library
<>. 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?


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