metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tibor Meller <tibor.mel...@gmail.com>
Subject Re: [DISCUSS] Switching to a better alternative of Pikaday.js
Date Mon, 15 Oct 2018 12:05:50 GMT
@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
>> >
>>
>

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